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