[[ nits ]]

[ section 4.1 ]

* "sets its IPv6 address" could perhaps be something like
  "sets a selected IPv6 source address"

[ section 4.3 ]

* "r" is not depicted in Figure 3?  Probably "X"?  Or update Figure to
  match the field description.

Thank you for the work on this document. I have some minor comments/questions below.

Francesca

1. -----

Section 2.

FP: Thank you for this very extensive (and useful) terminology section. I would suggest to add a sentence to say that the reader is expected to be familiar with RFC 6550 terminology. Alternatively, it might be good to add terms defined there and used in this document, such as DODAG and DODAGID, into this section as well. It also might improve readability to add references to documents when appropriate (for example, DIO could reference RFC 6550).

2. -----

   to OrigNode.  Intermediate routers join the Paired DODAGs based on
   the Rank as calculated from the DIO message.  Henceforth in this

FP: Please add a reference to where Rank is first defined, and/or add it to the terminology.

3. -----

   Target Prefix / Address
      (variable-length field) An IPv6 destination address or prefix.
      The Prefix Length field contains the number of valid leading bits
      in the prefix.  The length of the field is the least number of
      octets that can contain all of the bits of the Prefix, in other
      words Floor((7+(Prefix Length))/8) octets.  The remaining bits in

FP: "Floor((7+(Prefix Length))/8)" I am not sure where the "7+" comes from. Noting that the Prefix Length is 7-bit long, I am tempted to say that the number of octets calculated here also includes Prefix Length, however that is not clear from the sentence above ("The length of the field" - I assume the field refers to the Target Prefix / Address only). I think some clarification is necessary.

Thanks for the discussion and updates, I'm clearing my discuss. I trust we'll separately come to a conclusion on the remaining topic Alvaro and I have been discussing in email.

---previous DISCUSS for posterity:

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.

---previous comments:

(Note, added point 19.5.)

I support Éric's DISCUSS.

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.


19.5 Section 6.3.2:

(Adding one I missed earlier.)

   When a RREQ-DIO arrives at a TargNode with the S bit set to 0, the
   TargNode MUST build a DODAG in the RREP-Instance rooted at itself in
   order to discover the downstream route from the OrigNode to the
   TargNode.  The RREP-DIO message MUST be re-transmitted via link-local
   multicast until the OrigNode is reached or MaxRank is exceeded.  The

As in comment 12, the use of the term "re-transmitted" is a little weird here. Do you mean TargNode sends the RREP-DIO again and again, as the text seems to say? (And as with some of my other comments, it's not obvious to me what interface(s) the link-local multicast takes place on.)


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.

Section 2, paragraph 1, comment:
> 2.  Terminology

Is there some logic as to which terms are capitalized and which are not? (Also
in the text.)

-------------------------------------------------------------------------------
All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. There is no need to let me
know what you did with these suggestions.

Section 4.1, paragraph 10, nit:
>    X
>       Reserved.

Any recommendation what this should be set to on send?

Section 4.2, paragraph 9, nit:
>    X
>       Reserved.

Any recommendation what this should be set to on send?

Section 4.2, paragraph 13, nit:
>    Rsv
>       MUST be initialized to zero and ignored upon reception.

I guess these bits are reserved? Could you not just mark them X?

Section 4.3, paragraph 6, nit:
>                Figure 3: ART Option format for AODV-RPL MOP

X is missing from the description of the fields.

Section 1, paragraph 4, nit:
-    functionality to support routes with birectional asymmetric links.
+    functionality to support routes with bidirectional asymmetric links.
+                                           ++

Section 5, paragraph 7, nit:
-    of cells used in 6tisch), a priori knowledge (e.g. link quality
+    of cells used in 6tisch), a priori knowledge (e.g., link quality
+                                                      +

Section 5, paragraph 7, nit:
-    for evaluating link state (see([RFC7548], [RFC7276], [co-ioam]) MAY
-                                  ^
+    for evaluating link state (see [RFC7548], [RFC7276], [co-ioam]) MAY
+                                  ^

Section 6.2.1, paragraph 4, nit:
-       the downward (i.e. towards the TargNode) direction of the link
+       the downward (i.e., towards the TargNode) direction of the link
+                         +

Section 6.3.1, paragraph 2, nit:
-    symmetric route along which both directions satisfy the Objective
-                    ------------
+    symmetric route both of whose directions satisfy the Objective
+                        +++++++++

Section 6.3.1, paragraph 2, nit:
-    routes (i.e.  S=0).  Selection between a qualified symmetric route
-                ^
+    routes (i.e., S=0).  Selection between a qualified symmetric route
+                ^

I concur with Roman's DISCUSS, especially around the use of SHOULD.  I'd go further and ask why that's not a MUST, or in the alternative, suggest that you provide some guidance around why an implementer might legitimately decide against doing what the SHOULD says.

I also support John's DISCUSS.

The document shepherd writeup is more than two years old.

In Section 2, although "AODV-RPL Instance" is defined, it is present nowhere in the document.  Also "ART Option" doesn't seem to be ordered correctly.

In Section 9, I suggest being clear that what you're actually updating are the named sub-registries of the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry.

Thank you for addressing my DISCUSS and COMMENT feedback.

Firstly, thank you for writing this - I'm really not a ROLL person, but I found it interesting...

I support John and Rob's DISCUSSes, but I'll let them carry the heavy load :-)

I have a few nits:
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.'
I could find no 'r'  in Figure 3  - did you mean 'X'? 


Section 6.2.1, Step 1:
'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.'
I was unable to parse this. More worryingly, I was also not able to figure out what it should say...

Section 6.3.1:
'default to 1/4 of the time duration determined by the L bit.' - s/L bit/L value'.
This says that the default of 1/4 of the time duration, but I didn't see where /why the default would change. Also, isn't 'time' in 'time duration' unnecessary? Duration implies time.


Appendix A:
'The combination of Received Signal Strength Indication(downstream)  (RSSI) and Expected Number of Transmissions(upstream)" (ETX) ' -- this is a random closing quote without an opening one.

***Thank you for having addressed all my points raised during the IESG ballot of 2021-04-21 with the revised I-D*** (BTW, never hesitate to nudge an AD in the absence of action, I only reacted when processing my pending DISCUSS today :-( ... )

Thank you for the work put into this document. I seems that all cases have been thought of :-) Good job! and having a shorter path between two RPL nodes can be beneficial of course.

Special thanks to Peter Van der Stock for the IoT directorate review:
https://datatracker.ietf.org/doc/review-ietf-roll-aodv-rpl-10-iotdir-telechat-van-der-stok-2021-04-15/

Minor regret on the age of the document shepherd's write-up dated 2 years ago and about the -06 version. Little is said about the WG consensus. But, I am trusting the responsible AD on the consensus.

I hope that this helps to improve the document,

Regards,

-éric

== PREVIOUS DISCUSS (for archive) ==

A very trivial to fix but I do want to have a justification of using "point-to-point" (typically used over the two sides of a single link) vs. "peer-to-peer" (typically used over multiple links). Is it intentional by the ROLL WG ? Did I fail to understand the purpose of this document ? (quite possible of course!). I am afraid that many people will interpret the "point-to-point" like me.

== PREVIOUS COMMENTS (for archive) ==

-- Section 4.3 --
Figure 3 has a 'X' while the text has a 'r' ;)

Any reason why using "Floor((7+(Prefix Length))/8) octets" rather than the simple "Ceil(Prefix Length/8)" ?

-- Section 6.1 --
"Each node maintains a sequence number" does it impact constrained nodes ?