[manet] Re: OLSRv2 draft
Christopher Dearlove <[email protected]>
| Newsgroups | gmane.ietf.manet |
|---|---|
| Message-ID | <[email protected]> |
Juliusz As I outlined in a previous post, I think the presentation in this draft is not ideal. This is not a variant of OLSRv2. The normative part presents a recommendation (technically not always a RECOMMENDATION as it has MAY/SHOULD/MUST levels) as to the sending of a specific responsive TC message. However it does motivate it by noting that in a very specific scenario this message is needed. That scenario is one where routers only arrive and depart. As such the case you provide is outside that scenario, and doesn’t consider it. Also note the discussion in the draft about message loss, making this doubly outside the scope of the discussed scenario. So the answer is nothing changes, the new message doesn’t help, but it’s not being suggested. More generally, where messages might have long, but not infinite, intervals, this responsive message (sending a TC message when the presence of a new router is identified) might accelerate convergence. [There is a case not discussed that involves link changes that would trigger the message, which is network joining, where multiple new routers will appear in short order. The responsive TC message to the first of these should reach all of them. But to prevent a cascade of new messages, message minimum interval should be respected, as always.] I think if I were to rewrite the draft - I might, or might wait see what other responses there are - I would restructure as follows. Discuss that there can be scenarios with longer interval times, including backoff case. This can be combined with using responsive messages where changes occur. But one case where responsive messages don’t bridge gap between scheduled messages with a long interval is the remote TC message. While permitted by OLSRv2, there is no recommendation to use them. This draft is that. The extreme case is only arrivals and departures, and can messages be purely responsive? Discuss in Appendix. Normative part as currently. There’s a few details to get right in that reorganisation, but address that if I do this. Christopher > On 27 Jul 2024, at 00:15, Juliusz Chroboczek <[email protected]> wrote: > > Hi Chris, > >> That asymmetry can be broken if an additional form of responsive message >> is sent - a TC message in response to a new tuple in the Advertised >> Remote Router Set. > > What happens if that message is lost? > > Suppose you've got this topology, where the integers are the link metrics: > > > A > | \ 4 > | \ > 1 | C > | / > | / 1 > B > > A is using the route A-B-C, B is using the route B-C. > > Now the link B-C breaks, so B reroutes its traffic through A. It sends > a TC, but the TC is lost, so A is still sending its packets to C. > > In ordinary OLSR, the loop will be broken at the next TC. What happens in > your variant of OLSR? > > -- Juliusz _______________________________________________ manet mailing list -- [email protected] To unsubscribe send an email to [email protected]