MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Ines Robles via Datatracker <noreply@ietf.org>
To: <rtg-dir@ietf.org>
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: 
 <178821425249.331186.3465780257442433607@dt-datatracker-6669c7b496-s9mrn>
Date: Mon, 31 Aug 2026 15:10:52 -0700
Message-ID-Hash: MHSQHFMJLVVLPLDYST7X7UOOMEXK7ING
CC: draft-ietf-manet-olsrv2-responsive.all@ietf.org, manet@ietf.org
Reply-To: Ines Robles <mariainesrobles@googlemail.com>
Subject: =?utf-8?q?=5BRTG-DIR=5Ddraft-ietf-manet-olsrv2-responsive-01_early_Rtgdir_re?=
	=?utf-8?q?view?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/rtg-dir/947GY4R1y0YLRZk3xFJfT2YUD5Q>

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.