[manet] Re: review of draft-dearlove-manet-olsrv2-responsive -03

On 11 Apr 2026, at 15:58, Donald Eastlake <[email protected]> wrote:

Thanks for these comments. These are first responses without checking some wording details.

> Overall, this seems like a very good short draft specifying a reasonable compatible improvement to OLSRv2. I did notice a few minor things, as listed below, although I'm not the familiar with OLSR so I could be wrong in some cases:
> 
> Minor Suggestions:
> 
> Could there be a problem if multiple routers join in quick succession, perhaps due to the healing of a network split, causing a storm of responsive TCs? Should there be any rate limiting guidance?

There already is rate limiting guidance in the form of a minimum TC interval. This is not intended to override that. It would make sense to emphasise that point.

> Section 6: IANA prefers that a statement that no IANA actions are required be retained in the document. Suggest removing the parenthetical in the section.

This shows IANA practice has changed Ince I lat wrote an RFC. Thanks.

> Appendix A.3, 1st paragraph: suggest "can recognize" -> "has foreknowledge of”.

Will need to read to see what I think. I don’t think we’ve ever used the word foreknowledge before.

> You might also mention scheduled maintenance or scheduled replacement of a router.

My first thought on seeing this was that, yes, we could add a side comment that a new router might be an old router that ha restarted.

But that got me thinking. Unfortunately - and it’s not something that can be easily backwardly compatibly changed - OLSRv2 doesn’t have special handling for routers with a down time that start back up. Worse is if they also lose all knowledge of their previously ANSN. But that’s well beyond the scope of this draft. But we can consider the intermediate case of a router that went offline, but came back knowing its old ANSN. It will start with a new ANSN and all is well.

Now consider that in this context. Suppose we get a TC message with an already recognised originator address, but a new ANSN. Probable reason, its neighbourhood changed, we don’t need to do anything. But it might be the case above. Probably isn’t, but it might be.

What should we do? We could say if thi happen - indicating a changed remote router tuple, not a new one - we may sent a TC message. That’s a sort of double may. We may (the subject of this draft) send a TC message if we get a new remote router tuple. We may send a TC message if it changes. The latter is only an option if the former is done, but we could do the first but not the second.

Before I think about making any changes along those lines - plus of course the points above and any further comments - does anyone else have any thoughts on this issue? It’s technically necessary (in the pure responsive case) or there’s a case for it (just accelerating convergence otherwise) if restarting routers with the same originator address is a case to be handled.

> Typos:
> 
> Appendix A, title: has a stray double quote at the end which should be deleted.
> Appendix A, 1st paragraph: "as while is expected" -> "as while it is expected"
> Appendix A.2, last sentence: "remore" -> "remote"
> Appendix A.3,  6th paragraph, last sentence "meighbor" -> "neighbor"
> 
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  [email protected] <mailto:[email protected]>

_______________________________________________
manet mailing list -- [email protected]
To unsubscribe send an email to [email protected]