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

Donald Eastlake <[email protected]> Sun, 12 Apr 2026 21:16:12 -0400
Newsgroups gmane.ietf.manet
Message-ID <CAF4+nEGDjboUpBAbJmwM=Zi5XFipA7Fj-1ETdAbO5M1nEfBuuQ@mail.gmail.com>
Hi,

On Sun, Apr 12, 2026 at 3:43 PM Christopher Dearlove <
[email protected]> wrote:

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

OK.

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

I don't care whether or not "foreknowledge" is used. Might be simpler to
say "can predict".

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

The draft gives battery exhaustion as an example where a router leaving
could be predicted. I was just given another example of a case where router
leaving could be predicted. I wasn't thinking about a router that had left
returning although that would normally be the case for a router taken down
for scheduled maintenance.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email protected]


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

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