[Olsr-dev] Patch Orgy Syncup

[Sven-Ola Tuecke]

One more, to be precise here. The "cost" of a broken tcp/udp link because of
gw change (remember: most inet gw's use NAT) is less than the slight
routing-loop chance. That's what I mean with "0/0 is special".

// Sven-Ola

Sven-Ola Tuecke wrote:

> Hi,
> 
> this "extra Hyst" is a special feat for _me_. Which is Off by default. It
> works, but _only_ for default routes (which create some kind of "sink" in
> the topo graph) only only if used with brains.
> 
> The rest (especially the statement "Link state routing depends on synced
> info on all nodes") is ACKed. One of the immanent probs of olsrd also. Too
> much packet loss keeps the nodes out of sync - partly fixed by flooding
> the neighbourhood with a lot of LQ_TC's (look for "Fisheye" if you need
> ideas)
> 
> // Sven-Ola
> 
> Juliusz Chroboczek wrote:
> 
>>> | > b) Small Hysteresis on HNA4 0/0 to prevent routing flaps especially
>>> | >    when ETX(a) slowly grows and ETX(b) slowly shrinks there is a 5
>>> | >    minute "flaptime" for such a route.
>> 
>>> | Could you describe how that works?  I'm worried it might create
>>> | routing loops.
>> 
>>> i share your concerns - there is one other protocol which uses
>>> kind damping tequnique which is BGP. for exactly the same reason
>>> (routing loops) it is prohibited to damp internal paths ...
>> 
>> It's slightly different.  BGP is a hierarchical protocol, and the
>> prohibition of intra-AS flap damping is due to the requirement for
>> routes to be consistent within the AS.
>> 
>> This doesn't apply to OLSR, which is a flat protocol.  The problem is
>> that OLSR is a link-state protocol, and such protocols absolutely
>> require that topology information and path computation be consistent
>> across the routing domain.  So hysteresis for link costs should be
>> okay (as long as everyone has the same idea of a given link cost), but
>> hysteresis on shortest path computation will break.  But I'm not
>> excluding that Sven-Ola is doing something smart to work around the
>> problem.
>> 
>> (OSPF partly works around the issue by using hierarchical routing, but
>> I doubt that's what Sven-Ola is doing.)
>> 
>>> one of the things what we would like to do for olsr-ng is
>>> to work on that problem too - rather than damping routes
>>> we'd like to to setup a GRE tunnel to the node offering the 0/0
>>> route.
>> 
>>> now "stickyness" to a certain default gw is easy and does not
>>> create routing loops.
>> 
>> Yes, that should work.  Although my personal preference would be to
>> use a protocol that is robust in the face of inconsistent information.
>> 
>> That's getting off-topic for this list -- is there a better place to
>> discuss it (in English)?
>> 
>>                                         Juliusz
>> 
> 
>