[RTG-DIR]Re: [manet] draft-ietf-manet-olsrv2-responsive-01 early Rtgdir review

[Christopher Dearlove <[e-mail]>]

Ines

Thank you for this detailed review. While I have not read all of it yet, there are clearly some significant points that, at best, will require changes, and not just editorial matters.

Rather than attempt a hurried response, I will take some time to read and consider. Auming there are no showstopping issues (not yet known) my intent would be to produce a point by point comment and a revised draft together.

However this may take some time, so this is just to note comments received, with thanks, and I will be addressing them.

Of course if any members of the WG or others have any other comments in the meanwhile, also welcome.

Christopher

> On 31 Aug 2026, at 23:10, Ines Robles via Datatracker <[e-mail]> wrote:
> 
> Document: draft-ietf-manet-olsrv2-responsive
> Title: Responsive Use of the Mobile Ad Hoc Network (MANET) Routing Protocol
> OLSRv2 Reviewer: Ines Robles Review result: Not Ready
> 
> This is a early routing review of draft-ietf-manet-olsrv2-responsive-01.
> 
> Reviewer: Ines Robles
> 
> Summary:
> 
> This specification describes an optional Topology Control (TC) message that can
> be sent by an OLSRv2 router. It updates RFC 7181, "The Optimized Link State
> Routing Protocol Version 2 (OLSRv2)". The draft is on the right track. I have
> some comments and questions that would be useful to address before publication.
> 
> Comments/Questions:
> 
> 1- Section 4.2 states: “The arrival of a new router can be recognized by the
> addition of a new tuple to the Advertising Remote Router Set.” It then proposes
> sending additional TC messages in response to this event and concludes: “This
> new form of responsiveness - to a remote event rather than to a local event -
> ensures that the new router learns all the information that it requires even
> without periodic messages.” My question is whether the addition of an
> Advertising Remote Router Tuple necessarily occurs as a consequence of every
> new-router arrival. My understanding is as follows. Consider an established
> topology:
> 
>    A --- B --- C
> 
>    with a new leaf router X joining C:
> 
>    A --- B --- C --- X
> 
> If C's advertised information changes as a result of X's arrival, C may send a
> responsive TC containing topology information about X. A can therefore learn
> about X from C's TC. However, the originator of that TC is C, not X. Since A
> already has an Advertising Remote Router Tuple for C, reception of C's new TC
> appears to update C's existing tuple rather than create a new Advertising
> Remote Router Tuple for X. Thus, it seems possible that C's TC tells A about X,
> but A does not add an Advertising Remote Router Tuple for X.
> 
> 1.1- If X does not itself originate a TC, what causes a new Advertising Remote
> Router Tuple for X to be created at A, and therefore what triggers the
> additional complete TC specified in Section 5?
> 
> 1.2- In particular, is a newly arriving router guaranteed by RFC 7181 to
> originate a TC even if it has no advertised neighbors? Appendix A.3 appears
> relevant here, since it explicitly notes that sending TC messages by routers
> with no advertised neighbors “cannot be assumed.”
> 
> 1.3- Am I missing an OLSRv2 mechanism that guarantees that the necessary
> Advertising Remote Router Tuple insertion occurs in this case?
> 
> 1.4- Conversely, is the addition of a new Advertising Remote Router Tuple
> always an indication that the TC originator has newly arrived in the network?
> For example, could such a tuple also be created for a router that was already
> present, but whose previous tuple expired, or for an existing router that only
> later started originating TC messages? If so, would these cases also trigger
> the additional complete TC messages specified in Section 5?
> 
> 2- What happens if a router leaves and then rejoins, or restarts, using the
> same originator address? For example, suppose router X was previously part of
> the network, disappears, loses its OLSRv2 state, and then rejoins before its
> Advertising Remote Router Tuple has expired at the other routers. In this case,
> X needs to learn the remote topology again, but the other routers may still
> have an Advertising Remote Router Tuple for X. Appendix A.3 appears relevant
> here, since it considers the case where a router may have been lost but is
> still represented in the Advertising Remote Router Set. If X sends a new TC
> after rejoining, is a new Advertising Remote Router Tuple added, as described
> in Section 4.2, or is the existing tuple simply updated? If the existing tuple
> is only updated, what causes the other routers to send the additional complete
> TC messages that X needs, especially in a fully responsive network without
> periodic TC messages?
> 
> 3- Section 4 states: “This section considers the implications of a mostly or
> fully responsive network”. I understand “fully responsive” here to mean that TC
> messages may be sent only in response to events, without periodic transmission
> according to TC_INTERVAL. Is this understanding correct? If so, wouldn't this
> require an additional update to RFC 7181? My understanding is that RFC 7181
> requires complete TC messages to be sent periodically, with TC_INTERVAL
> defining the maximum interval between them. Appendix A, on the other hand,
> seems to describe a fully responsive network as an extreme case that is
> unlikely to be realized in practice. Could you clarify whether fully responsive
> operation without periodic TC messages is actually intended to be supported by
> this specification?
> 
> 4- Section 4.2 states that when a router is first activated: “it sends a HELLO
> message that announces its own identity, but no other significant information.”
> What is meant by “no other significant information”?
> 
> 5- Section 5 states: “When a router adds an Advertising Remote Router Tuple to
> the Advertising Remote Router Set it is REQUIRED that a complete TC message is
> sent if the router has not already sent a TC message in response to the same
> change and no TC messages are currently scheduled, or if the maximum possible
> TC message interval is used as an effective equivalent to that.”
> 
> 5.1- Could you clarify what is meant by “no TC messages are currently
> scheduled”? Does this mean that periodic TC transmission has been disabled?
> 
> 5.2- Also, what is meant by “the maximum possible TC message interval” and by
> using it “as an effective equivalent” to having no TC messages scheduled? My
> understanding is that RFC 7181 defines TC_INTERVAL as the maximum time between
> two successive TC transmissions and states that "TC messages MUST NOT be sent
> purely responsively". How are these two cases intended to fit with those RFC
> 7181 requirements?
> 
> 5.3- In the case where no TC messages are currently scheduled, or where the
> “maximum possible TC message interval” is used as an effective equivalent, how
> is the validity time of previously received topology information expected to be
> handled? In particular, what ensures that topology information does not expire
> before another TC message is sent?
> 
> 6- The Introduction states: “The extreme case of such behavior would be to only
> send such responsive message, with no periodic messages sent at all. While this
> extreme case is unlikely to ever be used, consideration of its behavior
> indicates the need for some additional TC messages in that case [...]”.
> Appendix A.3 states: “However, although in this case periodic HELLO messages
> are required, this does not mean that periodic TC messages are required.”
> 
> 6.1- In the extreme case described in the Introduction, are there no periodic
> messages at all, or are periodic HELLO messages still required?
> 
> 6.2- Does “fully responsive network” therefore mean that TC messages are fully
> responsive, while periodic HELLO messages may still be required?
> 
> 7- If multiple Advertising Remote Router Tuples are added while waiting for
> TC_MIN_INTERVAL, can one complete TC message cover all of these changes, rather
> than sending a separate TC message for each change?
> 
> 7.1- What happens, for example, when a newly arriving router receives TC
> messages from several existing routers and therefore adds several Advertising
> Remote Router Tuples? Should these additions trigger one complete TC message or
> multiple complete TC messages?
> 
> 8- Could an attacker cause repeated additions to the Advertising Remote Router
> Set and therefore trigger a large number of additional TC messages? If so,
> should this be considered in the Security Considerations?
> 
> 9- Should RFC 7183 also be referenced in the Security Considerations? It
> specifies the use of these mechanisms for integrity and replay protection in
> NHDP and OLSRv2.
> 
> 10- Should RFC 5148 be moved to the Normative References, since Section 5 says
> that the TC message “SHOULD be jittered as described in [RFC5148]”?
> 
> 11- It seems that the BCP 14 boilerplate is incomplete. It is missing
> “[RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown
> here.”
> 
> 12- Appendix A.1 says “send more than one copy of each message”. Does “copy”
> mean retransmitting the same message with the same message sequence number, or
> generating a new message with a new message sequence number?
> 
> 13- The Introduction states that routers using and not using this specification
> “can thus fully interoperate in all circumstances.” Does this also apply to a
> mixed network where only some routers implement the additional TC sending
> behavior, especially when periodic TC messages are not sent?
> 
> 14- In the fully responsive case, does the mechanism depend on a router sending
> a responsive TC whenever its locally advertised information changes? My
> understanding is that Section 16.2 of RFC 7181 permits, but does not require, a
> responsive TC to be generated following such a change. If periodic TC messages
> are not being sent, what ensures that this local change is propagated to the
> other routers?
> 
> Thanks for this document,
> 
> Ines.
> 
> 
> _______________________________________________
> manet mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]