Re: [manet] RFC7181 (OLSRv2) trouble with ANSN and router restart

["Rogge, Henning" <[e-mail]>]

The problem is easy to solve on the "sender" side, but if we manage I would like to solve it on the receiver side (of TCs).


This way we could prevent an incompatible change to the protocol.


Could the problem be solved if we track (per prefix) when we got the last TC containing it? This way, even when a transmitter only sends "incomplete TCs", we would eventually remove all database entries that have never been repeated despite being part of the (currently unchanging) ANSN.


Henning


________________________________
Von: Justin Dean <[e-mail]>
Gesendet: Donnerstag, 22. Juli 2021 17:32
An: Rogge, Henning
Cc: [e-mail]
Betreff: Re: [manet] RFC7181 (OLSRv2) trouble with ANSN and router restart

Interesting issue.  I think the solution you proposed for new ANSN < old ANSN and new MSN > old MSN works and wouldn't be hard to provide some ERRATA on how to deal with this.  I would suggest that when this state occurs all existing entries with that ANSN be removed as if they were old and all the entries in the message with the lower ANSN be added and the ANSN number be reset to the lower value.

As for the lower case it will happen less often but can still happen.  One way we could solve it is to have a router periodically update it's ANSN upon restart (even when the state has not changed) and slowly stop updating it over time.  Any update rate should suffice but an actual specification need not be created as any progression of the ANSN near the restart time should suffice.  With more updates providing more/quicker resolution at the cost of efficiencies throughout the network.  We would still need the first solution.

A completely different approach would be to use a lollipop numbering system with restarts occuring say anything greater than 65500 and progressing regardless of neighbor state for some small number then jumping to 0 and looping the number system at 65500 instead of 65535.  Any ANSN with a value on the "stick" would reset the ANSN if the currently stored ANSN was on the "pop"  otherwise normal operation.  This is a bit more complicated and IMO unnecessary for fixing this but just wanted to put it out there.

Justin Dean

On Thu, Jul 22, 2021 at 3:12 AM Rogge, Henning <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

I think I have potentially identified an issue with OLSRv2 that can lead to a stable desynchronization of the OLSRv2 TC database after a router restart.

The trouble happens because the ANSN (Advertised Neighbor Set Number) can (and should) become stable when the locally reachable neighbors and their metrics don't restart anymore.

The sequence that leads to the issue is:

1) router A restarts
2) router A (randomly?) selects a new Message Sequence Number which is HIGHER (in terms of cyclical comparison) than the last one it used
3) router A selects a new ANSN which is LOWER (or the same) than the last one it used
4) router B sees the new message sequence number/ANSN in TCs from router A
   => router B does not allow the old TC data to timeout (message sequence number is higher!)
   => router B does NOT overwrite the old TC data (ANSN is lower)

this situation will continue as long as the ANSN or router A (which can be stable for an arbitrary time) stays below the ANSN used by the router before its restart

There are two parts to this problem, one of them easy to fix.

a) the ANSN after the restart is lower than the ANSN before. We could just demand that a router does NOT increase the validity time of the TC entry in this case... or that it overwrites the TC entry (the combination of "new message seqno" and "old ANSN" should only happen after a restart)
b) the ANSN after the restart is the SAME as before... this is tricky, I have no idea how to resolve this at the receiver without comparing the TC data with the database, which is not reliable when we deal with incomplete TCs.

What do you think?

Henning Rogge
_______________________________________________
manet mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/manet