Subject: [Roll] John Scudder's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS and COMMENT)

From: John Scudder via Datatracker <[email-masked]>
Date: Mon, 19 Apr 2021 13:31:58 -0700

John Scudder has entered the following ballot position for
draft-ietf-roll-aodv-rpl-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

A lot of effort has clearly gone into this work, thank you. I do have one topic
I want to DISCUSS, as it seriously impacted the readability of the document
from my point of view. I don’t anticipate that it will be very difficult to
resolve this DISCUSS as it relates to clarity and not to anything fundamental.

My chief difficulty with the document is placing it in context. No hints are
given to the reader as to what the expected network environment is. I think it
would be almost sufficient to say, for example “the network environment is
assumed to be the same as described in RFC 6550, Section 1” for example, but
without that hint and without a strong background in ROLL, I found myself
struggling. Figures 4 and 5 in particular lead me to believe the expected
environment looks similar to a classic ISP network — a collection of nodes
connected by point-to-point links. If this isn’t correct (and I bet it’s not)
that may have led me into incorrect assumptions, which may be reflected in my
other comments below.

Further, it’s not stated anywhere whether AODV-RPL is intended to stand alone
as its own routing protocol, or to be viewed as an extension of RPL. In the
former case, it seems the document is lacking details that are present in RFC
6550. I’m assuming the latter is the case, but a clear statement to that effect
seems indicated.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1. Section 1:

   Reply.  AODV-RPL currently omits some features compared to AODV -- in
   particular, flagging Route Errors, blacklisting unidirectional links,
   multihoming, and handling unnumbered interfaces.

Your use of language is entirely up to you, but I feel obliged to point out
that there’s been a lot of discussion in the IETF community recently about use
of language that raises sensitive points, and about the term “blacklisting” in
particular. I understand that this is the only place in the document the term
appears, and since it refers to AODV you can’t just use another term, but
placing it in quotation marks might make it clear that it’s referring verbatim
to the language of RFC 3561.

2. Section 1:

  support for storing and non-storing modes.  AODV adds basic messages
  RREQ and RREP as part of RPL DIO (DODAG Information Object) control

Did you mean “AODV-RPL adds”?

3. Section 2:

   Symmetric route
      The upstream and downstream routes traverse the same routers.

Same routers? Or same links? (Or both, if multi-access links are part of the
mix, as I imagine they may be?)

4. Section 4.1:

   OrigNode sets its IPv6 address in the DODAGID field of the RREQ-DIO
   message.  A RREQ-DIO message MUST carry exactly one RREQ option,

Should that say “one of its IPv6 addresses"? Is it even necessary to restate
this? RFC 6550 §6.3.1 already has a clearer requirement:

   DODAGID: 128-bit IPv6 address set by a DODAG root that uniquely
         identifies a DODAG.  The DODAGID MUST be a routable IPv6
         address belonging to the DODAG root.

5. Section S4.1:

  TargNode can join the RREQ instance at a Rank whose integer portion
  is equal to the MaxRank.

Not less than or equal, right? Strict equality to MaxRank is required?

6. Section 4.2:

   TargNode sets its IPv6 address in the DODAGID field of the RREP-DIO
   message.  A RREP-DIO message MUST carry exactly one RREP option,

Same as #4.

7. Section 4.2:

  Address Vector
     Only present when the H bit is set to 0.  For an asymmetric route,
     the Address Vector represents the IPv6 addresses of the route that
     the RREP-DIO has passed.

The first time I read through this, I didn’t understand it at all. On
re-reading, I think you’re using the word “route” in two different ways in the
same sentence, the first time to mean “route” in the sense of an object in the
protocol, the second time in the more casual sense of “a path through the
network”. If that’s right, I suggest rewriting the second instance, as in “…
represents the IPv6 addresses of the path through the network the RREP-DIO has
traversed.”

Also, as in point #4, is it right to say *the* IPv6 addresses? Couldn’t any
given node have various IPv6 addresses? So maybe just lose the definite
article, as in “… represents IPv6 addresses of the path…”?

8. Section 4.3:

  r
     A one-bit reserved field.  This field MUST be initialized to zero
     by the sender and MUST be ignored by the receiver.

The figure doesn’t show an “r” field. I assume the field labeled “X” should be
relabeled as “r”?

9. Section 5:

   Figure 4.  If an intermediate router sends out RREQ-DIO with the S
   bit set to 1, then all the one-hop links on the route from the
   OrigNode O to this router meet the requirements of route discovery,

On first reading I didn’t understand this. Having read the whole document, I
now get it (I think!). Possibly changing “meet” to “have met” would have been
enough to get me past my initial befuddlement.

10. Section 5:

   The criteria used to determine whether or not each link is symmetric
   is beyond the scope of the document.  For instance, intermediate

Should be “criterion … is beyond", or "criteria … are beyond", depending on
whether you want singular or plural.

11. Section 5:

  routers can use local information (e.g., bit rate, bandwidth, number
  of cells used in 6tisch)

I wouldn’t have minded a reference for 6tisch.

12. Section 5:

   Upon receiving a RREQ-DIO with the S bit set to 1, a node determines
   whether this one-hop link can be used symmetrically, i.e., both the
   two directions meet the requirements of data transmission.  If the
   RREQ-DIO arrives over an interface that is not known to be symmetric,
   or is known to be asymmetric, the S bit is set to 0.  If the S bit
   arrives already set to be '0', it is set to be '0' on retransmission

The term “retransmission” seems misused here. I guess you mean something like
“when the RREQ-DIO is propagated”.

13. Section 5:

  Appendix A describes an example method using the upstream Expected
  Number of Transmissions" (ETX) and downstream Received Signal
  Strength Indicator (RSSI) to estimate whether the link is symmetric
  in terms of link quality is given in using an averaging technique.

This sentence needs a rewrite to make it grammatical. It works up until "is
given in using an averaging technique”.

14. Section 6.2.1:

     If the S bit in the received RREQ-DIO is set to 1, the router MUST
     determine whether each direction of the link (by which the RREQ-
     DIO is received) satisfies the Objective Function.  In case that
     the downward (i.e. towards the TargNode) direction of the link
     does not satisfy the Objective Function, the link can't be used
     symmetrically, thus the S bit of the RREQ-DIO to be sent out MUST
     be set as 0.  If the S bit in the received RREQ-DIO is set to 0,
     the router MUST determine into the upward direction (towards the
     OrigNode) of the link.

The last sentence doesn’t make sense.

15. Section 6.2.1:

     If the router is an intermediate router, then it transmits a RREQ-
     DIO via link-local multicast;

On what interface? Routers generally can have multiple interfaces. Again, this
is a place a clear description of the network environment might have helped.

16. Section 6.2.2:

  If the OrigNode tries to reach multiple TargNodes in a single RREQ-
  Instance, one of the TargNodes can be an intermediate router to the
  others, therefore it MUST continue sending RREQ-DIO to reach other
  targets.  In this case, before rebroadcasting the RREQ-DIO

The use of the term “broadcast” here confuses me. Is this “broadcast” in the RF
sense? Again, this is a place a clear description of the network environment
might have helped.

17. Section 6.2.2:

  send out any RREQ-DIO.  For the purposes of determining the
  intersection with previous incoming RREQ-DIOs, the intermediate
  router maintains a record of the targets that have been requested
  associated with the RREQ-Instance.  Any RREQ-DIO message with
  different ART Options coming from a router with higher Rank is
  ignored.

It’s not clear to me if the last sentence goes with the previous and if so,
how. Does it even relate to multiple targets? Also, different from what? If it
has the same ART Options (same as what?) is it *not* ignored?

18. Section 6.3.1:

  implementation-specific and out of scope.  If the implementation
  selects the symmetric route, and the L bit is not 0, the TargNode MAY
  delay transmitting the RREP-DIO for duration RREP_WAIT_TIME to await
  a symmetric route with a lower Rank.  The value of RREP_WAIT_TIME is
  set by default to 1/4 of the time duration determined by the L bit.

It’s not an L bit though, it’s an L field.

19. Section 6.3.2:

  multicast until the OrigNode is reached or MaxRank is exceeded.  The
  TargNode MAY delay transmitting the RREP-DIO for duration
  RREP_WAIT_TIME to await a route with a lower Rank.  The value of
  RREP_WAIT_TIME is set by default to 1/4 of the time duration
  determined by the L bit.

Again, it’s an L field. Also, what if L is zero? Is RREP_WAIT_TIME set to
infinity, as the text implies?

Please do a global search for “L bit”, as there are additional instances I
haven’t called out.

20. Section 6.4:

  Step 4:

      If the receiver is the OrigNode, it can start transmitting the
      application data to TargNode along the path as provided in RREP-
      Instance, and processing for the RREP-DIO is complete.  Otherwise,
      in case of an asymmetric route, the intermediate router MUST
      include the address of the interface receiving the RREP-DIO into
      the address vector, and then transmit the RREP-DIO via link-local
      multicast.  In case of a symmetric route, the RREP-DIO message is

As with #15: on what interface(s)?

21. Section 10:

  fake AODV-RPL route discoveries.  In this type of scenario, RPL's
  preinstalled mode of operation, where the key to use for a P2P-RPL
  route discovery is preinstalled, SHOULD be used.

What type of scenario is that?

22. Appendix A:

s/pakcet/packet/

23. General remark:

Although “acknowledgements” isn’t a required section I was a little surprised
not to encounter it, as it’s usually present. Your call of course.

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 20 Apr 2021 07:55:06 -0700

On April 19, 2021 at 4:32:03 PM, John Scudder wrote:

John:

Hi!  Thanks for the review!

I'm just replying to your DISCUSS -- I will let the authors address
the rest of the comments.

...
> given to the reader as to what the expected network environment is. I think
> it would be almost sufficient to say, for example “the network environment is
> struggling.

AODV-RPL is an extension of RPL -- the same types of networks that RPL
targets are appropriate for AODV-RPL.  The one differentiator is the
ability of AODV-RPL to discover p2p routes that may not need to
traverse the root (more below).  IOW, networks that have significant
p2p traffic would benefit the most.

> Figures 4 and 5 in particular lead me to believe the expected environment
> looks similar to a classic ISP network — a collection of nodes connected by
> point-to-point links. If this isn’t correct (and I bet it’s not) that may
> have led me into incorrect assumptions, which may be reflected in my other
> comments below.

Now that I look at the figures again, I can see how they might look
like a segment of a traditional access-distribution-core network. :-)

RPL forms a Destination-Oriented Directed Acyclic Graph (DODAG), which
results in a tree-like structure with a Border Router (BR) at the top.
In general, instead of access-distribution-core, the whole RPL
instance is made up of leaves-transit routers-border router.  In some
cases the leaves are RPL-aware, but not always.

> Further, it’s not stated anywhere whether AODV-RPL is intended to stand
> alone as its own routing protocol, or to be viewed as an extension of RPL.
> In the former case, it seems the document is lacking details that are present
> in RFC 6550. I’m assuming the latter is the case, but a clear statement to
> that effect seems indicated.

AODV-RPL uses a new Mode of Operation (MOP) dedicated to the discovery
of p2p routes.  This means that it runs in a separate instance from
the "base RPL".  Also, it can be used whether or not a "base RPL"
instance is used.  IOW, it is RPL using MOP 5.

Most of what I wrote above, which I hope helps clarify, is in the
Introduction (pasted below).  I think that the text could have been a
little more explicit in tying p2p traffic to AODV-RPL -- everything
else seems to be there.  Yes, there is a strong assumption that the
reader knows RPL.

Do you have specific suggestion on what can be added to the Introduction?

Thanks!

Alvaro.

1.  Introduction

   RPL (Routing Protocol for Low-Power and Lossy Networks) [RFC6550] is
   an IPv6 distance vector routing protocol designed to support multiple
   traffic flows through a root-based Destination-Oriented Directed
   Acyclic Graph (DODAG).  Typically, a router does not have routing
   information for most other routers.  Consequently, for traffic
   between routers within the DODAG (i.e., Point-to-Point (P2P) traffic)
   data packets either have to traverse the root in non-storing mode, or
   traverse a common ancestor in storing mode.  Such P2P traffic is
   thereby likely to traverse longer routes and may suffer severe
   congestion near the root (for more information see [RFC6997],
   [RFC6998]).

   The route discovery process in AODV-RPL is modeled on the analogous
   procedure specified in AODV [RFC3561].  The on-demand nature of AODV
   route discovery is natural for the needs of peer-to-peer routing in
   RPL-based LLNs.  AODV terminology has been adapted for use with AODV-
   RPL messages, namely RREQ for Route Request, and RREP for Route
   Reply.  AODV-RPL currently omits some features compared to AODV -- in
   particular, flagging Route Errors, blacklisting unidirectional links,
   multihoming, and handling unnumbered interfaces.

   AODV-RPL reuses and provides a natural extension to the core RPL
   functionality to support routes with birectional asymmetric links.
   It retains RPL's DODAG formation, RPL Instance and the associated
   Objective Function (defined in [RFC6551]), trickle timers, and
   support for storing and non-storing modes.  AODV adds basic messages
   RREQ and RREP as part of RPL DIO (DODAG Information Object) control
   messages, and does not utilize the Destination Advertisement Object
   (DAO) message of RPL.  AODV-RPL specifies a new MOP (Mode of
   Operation) running in a separate instance dedicated to discover P2P
   routes, which may differ from the point-to-multipoint routes
   discoverable by native RPL.  AODV-RPL can be operated whether or not
   native RPL is running otherwise.

---

From: John Scudder <[email-masked]>
Date: Tue, 20 Apr 2021 15:09:01 +0000

Hi Alvaro,

I have one partial reply below, but I think we might benefit from a short phone call. I’ll unicast you some times that would work for me.

On Apr 20, 2021, at 10:55 AM, Alvaro Retana <[email-masked]<mailto:[email-masked]>> wrote:
...

This doesn’t really clear up my concern, which I can rephrase this way: I’m pretty sure AODV-RPL, standing alone, isn’t an implementable specification. If it assumes that all the protocol machinery of RFC 6550 is present, then I’m willing to accept on faith that the gaps are filled that way, but this needs to be said. If it doesn’t assume that all of RFC 6550 is present, then I think it should call out by reference what the required parts are.

I haven’t tried to go through the document and say “this isn’t implementable because you left out this, and that, and so on” because so far my guess is it’s assumed that the entire base of RFC 6550 is available, so it wouldn’t be a good use of anyone’s time to produce that kind of review.

—John

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 20 Apr 2021 08:23:25 -0700

ACK. (For the record)

On April 20, 2021 at 11:09:05 AM, John Scudder ([email-masked]) wrote:

Hi Alvaro,

I have one partial reply below, but I think we might benefit from a short
phone call. I’ll unicast you some times that would work for me.

On Apr 20, 2021, at 10:55 AM, Alvaro Retana <[email-masked]> wrote:

...

In the former case, it seems the document is lacking details that are
present

This doesn’t really clear up my concern, which I can rephrase this way: I’m
pretty sure AODV-RPL, standing alone, isn’t an implementable specification.
If it assumes that all the protocol machinery of RFC 6550 is present, then
I’m willing to accept on faith that the gaps are filled that way, but this
needs to be said. If it * doesn’t* assume that all of RFC 6550 is present,
then I think it should call out by reference what the required parts are.

I haven’t tried to go through the document and say “this isn’t
implementable because you left out this, and that, and so on” because so
far my guess is it’s assumed that the entire base of RFC 6550 is available,
so it wouldn’t be a good use of anyone’s time to produce that kind of
review.

—John

---

From: John Scudder <[email-masked]>
Date: Wed, 21 Apr 2021 20:01:53 +0000

Hi Alvaro,

After our call I feel like we’ve made progress but there are still some things I’d like to finish hashing out.

> p2p traffic would benefit the most.

As we discussed on our call, I think the “expected network environment” thing was largely a red herring I was led to by imprecision in the use of “multicast”, see for example my comment #15. I think we can consider the “network environment” point put to rest.

> cases the leaves are RPL-aware, but not always.

A key observation is that the figure depicts a control plane topology, not a physical topology, right?

> instance is used.  IOW, it is RPL using MOP 5.

The use of the term “base RPL”, or “native RPL” as the introduction calls it, is problematic, if I’ve understood you right. It’s a case of “the exception that proves the rule”, i.e. by referencing “native RPL” that implies the AODV-RPL is *not* RPL, which is a contradiction to what you’ve written above and explained to me.

So I think some work on that language is in order.

> Do you have specific suggestion on what can be added to the Introduction?

See below.

>   native RPL is running otherwise.

The final paragraph is the one that led me astray. Is this rewrite on target?

AODV-RPL is a new RPL Mode of Operation (MOP) that extends RFC 6550 to support routes with bidirectional asymmetric links. It makes use of RFC 6550’s DODAG formation, RPL Instance, and the associated Objective Function (defined in [rfc6551]), trickle timers, and support for storing and non-storing modes. AODV-RPL adds basic messages RREQ and RREP as part of the RPL DIO (DODAG Information Object) control messages, and does not utilize the Destination Advertisement Object (DAO). The AODV-RPL MOP runs in a separate instance dedicated to discovering P2P [*] routes, which may differ from the point-to-multipoint routes discoverable by RPL’s other modes of operation. AODV-RPL can be operated whether or not other RPL modes of operation are running otherwise.

[*] Although, I do agree with Éric’s DISCUSS about use of this terminology. I understand from Alvaro that it’s water under the bridge, but some kind of warning to the unwary traveler is in order: ‘hey, be aware we use “p2p" in a way you may find unusual!’

Thanks,

—John