<div dir="ltr"><div>That's pretty much what I just implemented for Serval's new link state router. <br>Each node only repeats links that are used in their routing table, one link per possible destination. You also need a "no active link" message to force a deletion so that other nodes can quickly choose an alternative and start telling you about it. <br>
</div>I threw together a dodgy, overly simplistic simulator last year to explore how it should work. But only got around to implementing it properly in the last month or so.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Fri, May 24, 2013 at 5:35 PM, Teco Boot <span dir="ltr"><<a href="mailto:teco@inf-net.nl" target="_blank">teco@inf-net.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My concerns are scalability. Major improvements on what we have now would be smart flooding (flooding MPRs) and topology reduction. A single TC summary for each router would help a lot. Links are identified by 2 peering router IP addresses. Could be the summary addresses or link-locals. use those that have higher compression ratio?<br>

<br>
Other optimization: links with next-hops that are not in own routing table can be removed from TC. Don't tell anyone else what you don't use yourself. Only tell the better routes: next-hops that are *in* the routing table.<br>

<br>
I'll run your code first and respond later.<br>
<br>
T.<br>
<br>
<br>
<br>
<br>
Op 24 mei 2013, om 07:43 heeft Henning Rogge <<a href="mailto:henning.rogge@fkie.fraunhofer.de">henning.rogge@fkie.fraunhofer.de</a>> het volgende geschreven:<br>
<div class="HOEnZb"><div class="h5"><br>
> On 05/23/2013 10:30 PM, Teco Boot wrote:<br>
>><br>
>> Op 23 mei 2013, om 20:51 heeft Henning Rogge <<a href="mailto:hrogge@googlemail.com">hrogge@googlemail.com</a>> het volgende geschreven:<br>
>><br>
>>> I would like to<br>
>>> get to the point where interface addresses can be "linklocal only" and<br>
>>> you need only a single "routable" address on the localhost interface<br>
>>> for the whole node.<br>
>> Great!<br>
>><br>
>> Next: auto configuration and source address based routing (BRDP or similar).<br>
><br>
> I plan to add a filter-callback between the dijkstra and the setting of the kernel routes that allows plugins to prevent the core from setting routes that match the filter.<br>
><br>
> This way a SmartGateway or BRDP plugin could take over the handling of the gateway routes completely without any code-change in the core.<br>
><br>
> Do you think that will be sufficient to implement BRDP support?<br>
><br>
> Henning Rogge<br>
><br>
> --<br>
> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für<br>
> Kommunikation, Informationsverarbeitung und Ergonomie FKIE<br>
> Kommunikationssysteme (KOM)<br>
> Fraunhofer Straße 20, 53343 Wachtberg, Germany<br>
> Telefon <a href="tel:%2B49%20228%209435-961" value="+492289435961">+49 228 9435-961</a>,   Fax <a href="tel:%2B49%20228%209435%20685" value="+492289435685">+49 228 9435 685</a><br>
> mailto:<a href="mailto:henning.rogge@fkie.fraunhofer.de">henning.rogge@fkie.fraunhofer.de</a> <a href="http://www.fkie.fraunhofer.de" target="_blank">http://www.fkie.fraunhofer.de</a><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> --<br>
> Olsr-dev mailing list<br>
> <a href="mailto:Olsr-dev@lists.olsr.org">Olsr-dev@lists.olsr.org</a><br>
> <a href="https://lists.olsr.org/mailman/listinfo/olsr-dev" target="_blank">https://lists.olsr.org/mailman/listinfo/olsr-dev</a><br>
<br>
<br>
--<br>
Olsr-dev mailing list<br>
<a href="mailto:Olsr-dev@lists.olsr.org">Olsr-dev@lists.olsr.org</a><br>
<a href="https://lists.olsr.org/mailman/listinfo/olsr-dev" target="_blank">https://lists.olsr.org/mailman/listinfo/olsr-dev</a><br>
</div></div></blockquote></div><br></div>