[Olsr-dev] Patch Orgy Syncup / Sorting out old TCs [long!]

[Hannes Gredler]

On Sat, Dec 29, 2007 at 12:32:20PM +0100, Sven-Ola T?cke wrote:
| To come to a conclusio: I disagree with that proposal. 
| 
| Where I agree is the fact, that sorting out older TCs will help a lot. Because 
| only fresh topo info is fed into the calculation. My "personal" test link is 
| a bad one - which is good for testing. It has 2 alternative pathes, ETX 
| around 8 for both, one beeing 5 hops with 30kbyte/s the second with 9 hops 
| around 100kbyte/s. If old TCs are sorted out, both pathes are more usable and 
| are much (!) more in sync if I sort out old TC's.
| 
| Your sender-side change will require us to upgrade all nodes. Otherwise (as 
| stated) we end up with un-upgraded nodes occasionally not having routes for a 
| long period. I am not against using some force to help upgrading. But I want 
| a good reason to communicate that. 

why is that ? - the unupgraded nodes just floods through (even outaged) messages.
the new nodes will simply act as a flooding barrier. could you give an example 
that mandates a full upgrade ?

| The main reason, not to agree, is the fact that you need connectivity to the 
| complete mesh in order to spread the "I'm starting now" info. That is not 
| always true. For example: We have two major clouds here in Berlin with only a 
| handful of (bad) links in between. If weather conditions are good, we can see 
| the other cloud and use the links. If weather condtions are bad, both clouds 
| do not see each other. If the clouds reconnect, you need a "200 nodes are new 
| in here" kind of info to spread...

that is a valid statement - olsr due to its lack of resyncing its LSDBs is
a sensible protocol for the "disconnected islands reunion problem".
the above sounds to me like a strong case for periodic resynchronisation (CSN).
looks like then all of our issues are gone. with CSN a restarting neighbor
can immediatly sense its older-incarnation seqno plus has the ability
to heal desynced islands.

/hannes