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

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

> I’m failing to understand the specific problem here. There are restart issues that we never found the bandwidth to formally address, but they are different to this one.

>> 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

> This is unfortunate, and part of the problem, router A will find it hard to get back into the network. The easiest way is simply to wait out expiry times, but that might not be an issue if those have become long (which is a bandwidth saving approach in a stable network - but nothing unfortunately is free).

Yes, waiting for the configured VTIME before you restart the routing is a valid option with a lot of time-cost involved.

>> 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)

> Yes, the old data won’t be overwritten. But nothing affects the timeout. It doesn’t happen, but it isn’t extended. 16.3.3.1 point 1, the TC message will be discarded. So Topology Tuples etc. aren’t modified and will in due course timeout. Maybe that’s too slow, but that’s a different issue.

I think Ronald and me overlooked this detail... I have to check my implementation, but I think I do this correctly.

>> 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.

> This one might be a problem. Unlucky with 2^16 numbers to pick. But not unlucky enough. But we are into the region of how to restart a router, and advice to give it. Using more than one ANSN is one way to solve that. However the composite of MSN and ANSN is a tricky one. I can see (I think) a horribly inefficient way to make it work, but an efficient way - other than just wait out timeouts - needs more thought.

Yes. waiting for the Validity time is often a bad option.

> A restarting router that uses incomplete TCs though is not good behaviour. That would be part of the advice to restarting routers.

Sometimes the router has no choice, e.g. if the list of attached prefixes is just LONG. Long ago I wrote a hack for OLSRv1 that allowed to add the "range" of a partial update... so the receiver could clear every prefix within the range that is not in the TC.

But the most likely way to go for me is to define an OLSRv2 extension so I don't have to send the (mostly static) Attached Networks with every TC. Or finally look into my ideas about RFC 5444 compression.

> (I assume we are considering routers that restart with no memory of their last MSN and ANSN. Those with memory can simply continue.)

Yes, storing all relevant sequence numbers would also help.

> First, I don’t think you have the receiver side issue you note. The information will eventually timeout unless the sender sends incomplete messages with valid MSN and latest ANSN. But that’s something it could do anyway.

> There are heuristics you might add to say “ignore this message as it fails a smell test”. You can’t stop a router doing that, nor should you. There are various heuristics you could try. Some relevant to this situation, others not. One such is that if you see a message where MSN and ANSN show opposite behaviour, that’s a sign that router is misbehaving. If you interpret misbehaving as “probably reset, I should wipe all its data” that’s drastic but possible. But doing so on the basis of one message is a bit much. And I don’t think you’ll ever get a set of rules applicable to all situations. Which is why I used the term heuristics.

> Either in an informational RFC on router reset behaviour, or in a non-normative annex to a standards track RFC, you could include advice on behaviour to look out for that suggests a misbehaving/reset router and that you MAY (no stronger) discard messages or even wipe the database if you see that, probably more than once.

I think an informational document that points out the issue and offer a few suggestions what you could do would be a good way.

> In short, I don’t think this is a soluble, here are rules that always work, problem. But if you find a real problem in a real network you could include code that makes a tradeoff of handling that case while possibly making other cases behave less well. (For example the multiple MSNs/ANSNs I suggest in my last email might trigger some heuristics.) Information might help a network operator. If you are supplying an OLSRv2 implementation and have a heuristic you think is often useful, you could include it as an option. But it would be very easy to think up heuristics that in reality aren’t much use.

I think my confusion was mostly triggered by the fact that the same router coming only again can give me a validity-time long interval of bad network behavior...

Henning Rogge