[Roll] AD Review of draft-ietf-roll-aodv-rpl-07

[Alvaro Retana <[e-mail]>]

Dear authors:

I just finished reading this document.  I am excited about the new
functionality, but I have several significant issues/questions about the
document, and a lot of comments (in-line below).

(1) What is AODV-RPL?

Reading the document, my impression of AODV-RPL varies between an
enhancement to RPL for Reactive Route Discovery (*maybe* in addition to the
usual proactive routing), to ships-in-the-night reactive-only protocol that
uses some of the RPL concepts (but not exactly sure which ones).  The
different MOP indicates that it is different from "base" RPL (rfc6550), but
it is not clear what the assumptions are...and which parts are "inherited"
from the "base" and which ones are not used.

Another way to ask the same question is: What is the relationship of
AODV-RPL to RPL?  What mechanisms are not applicable with the new MOP?  Is
it expected that an instance of RPL will also be running in the network?

Please be clear early in the document.  To quote Charlie: "AODV-RPL is a
variation on RPL" [1].  What remains, what changes, etc..


(2) Document Status (for the Chairs/Shepherd)

I didn't find a specific discussion in the archive about the status of this
document.  Did one take place?  At this point I am mostly curious given the
similarities with rfc6997 (Experimental) and the fact that "Future Work" is
discussed -- not typical in a Standards Track document.  IOW, why is this
document intended to be a Proposed Standard and not Experimental?


(3) Replacing rfc6997??

This document uses some of the features from rfc6997 (see some comments
about that in-line), which is fine.  The Introduction falls just short of
saying that this work replaces rfc6997.  Should it be considered a
replacement?  I ask mostly in the context of rfc7733 (RPL in Home and
Building) which mandates (MUST) the use of rfc6997.  Should rfc7733 be
Updated?  [I'm just asking the question for it to be considered...I am not
sure of deployments which conform to rfc7733 or rfc6997...or the impact
this would have.]


(4) Link checks

The operation of AODV-RPL depend on link checks (§6.2.1/§6.4) to determine
symmetry and whether it can "fulfill the requirements".  But these checks
are not explained or defined anywhere (are they?) beyond an *example* in
the Appendix.  I think defining the checks is a critical part of the
specification of the mechanism...specially for a Standards Track protocol.



Please take a look at the comments below.  I will wait for the major points
to be addressed before starting the IETF Last Call.

Thanks!!

Alvaro.

[1] https://mailarchive.ietf.org/arch/msg/roll/PoQQBOmWZ2XFRWVK13Q5Z4W9x-s


[Line numbers from idnits.]

...
14     Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks (LLNs)

[minor] This is not the clearest title I've ever seen.   Suggestion:
Reactive Route Discovery using RPL (AODV-RPL)    ...or something like that.

15                      draft-ietf-roll-aodv-rpl-07

17 Abstract

19   Route discovery for symmetric and asymmetric Point-to-Point (P2P)
20   traffic flows is a desirable feature in Low power and Lossy Networks
21   (LLNs).  For that purpose, this document specifies a reactive P2P
22   route discovery mechanism for both hop-by-hop routing and source
23   routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL
24   protocol.  Paired Instances are used to construct directional paths,
25   in case some of the links between source and target node are
26   asymmetric.

[minor] s/(AODV) based RPL protocol/(AODV) based RPL protocol (AODV-RPL)


...
100 1.  Introduction

[general comment] Avoid mentioning the "negative" of other proposals and
focus on why this work is needed.  IOW, the justification should not be
"because others can't do it".

[nit] Some of the paragraphs throughout the document are very long and
could be split to better convey the ideas.

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

[nit] s/RPL[RFC6550]/RPL [RFC6550]

[minor] s/Routing Protocol for LLNs (Low-Power and Lossy Networks)/Routing
Protocol for Low-Power and Lossy Networks    That's the name of the
protocol.

[nit] s/is a IPv6/is an IPv6

[minor] "Such P2P traffic is thereby likely to traverse longer routes and
may suffer severe congestion near the DAG root (for more information see
[RFC6997], [RFC6998])."  I see that those other RFCs also make the
statement that congestion is possible, and even longer routes...but I don't
see more information there.  Did I miss it?  If not, then I don't see the
value of those references at this point.

114   To discover better paths for P2P traffic flows in RPL, P2P-RPL
115   [RFC6997] specifies a temporary DODAG where the source acts as a
116   temporary root.  The source initiates DIOs encapsulating the P2P
117   Route Discovery option (P2P-RDO) with an address vector for both hop-
118   by-hop mode (H=1) and source routing mode (H=0).  Subsequently, each
119   intermediate router adds its IP address and multicasts the P2P mode
120   DIOs, until the message reaches the Target Node, which then sends the
121   "Discovery Reply" object.  P2P-RPL is efficient for source routing,
122   but much less efficient for hop-by-hop routing due to the extra
123   address vector overhead.  However, for symmetric links, when the P2P
124   mode DIO message is being multicast from the source hop-by-hop,
125   receiving nodes can infer a next hop towards the source.  When the
126   Target Node subsequently replies to the source along the established
127   forward route, receiving nodes determine the next hop towards the
128   Target Node.  For hop-by-hop routes (H=1) over symmetric links, this
129   would allow efficient use of routing tables for P2P-RDO messages
130   instead of the "Address Vector".

[minor] Expand DIO on first use.

[minor] The description above of P2P-RPL seems to include too much
(unnecessary for this document) detail.  It also seems to propose
enhancements (in the last couple of sentences).  Consider simplifying to
something like this:

   To discover better paths for P2P traffic flows in RPL, P2P-RPL
   [RFC6997] specifies a temporary DODAG where the source acts as a
   temporary root.  P2P-RPL is efficient for source routing,
   but can be much less efficient for hop-by-hop routing due to the
   extra address vector overhead.


132   RPL and P2P-RPL both specify the use of a single DODAG in networks of
133   symmetric links, where the two directions of a link MUST both satisfy
134   the constraints of the objective function.  This disallows the use of
135   asymmetric links which are qualified in one direction.  But,
136   application-specific routing requirements as defined in IETF ROLL
137   Working Group [RFC5548], [RFC5673], [RFC5826] and [RFC5867] may be
138   satisfied by routing paths using bidirectional asymmetric links.  For
139   this purpose, [I-D.thubert-roll-asymlink] described bidirectional
140   asymmetric links for RPL [RFC6550] with Paired DODAGs, for which the
141   DAG root (DODAGID) is common for two Instances.  This can satisfy
142   application-specific routing requirements for bidirectional
143   asymmetric links in core RPL [RFC6550].  Using P2P-RPL twice with
144   Paired DODAGs, on the other hand, requires two roots: one for the
145   source and another for the target node due to temporary DODAG
146   formation.  For networks composed of bidirectional asymmetric links
147   (see Section 5), AODV-RPL specifies P2P route discovery, utilizing
148   RPL with a new MoP.  AODV-RPL makes use of two multicast messages to
149   discover possibly asymmetric routes.  This provides higher route
150   diversity and can find suitable routes that might otherwise go
151   undetected by RPL.  AODV-RPL eliminates the need for address vector
152   overhead in hop-by-hop mode.  This significantly reduces the control
153   packet size, which is important for Constrained LLN networks.  Both
154   discovered routes (upward and downward) meet the application specific
155   metrics and constraints that are defined in the Objective Function
156   for each Instance [RFC6552].  On the other hand, the point-to-point
157   nature of routes discovered by AODV-RPL can reduce interference near
158   the root nodes and also provide routes with fewer hops, likely
159   improving performance in the network.

[major] "RPL and P2P-RPL both specify the use of a single DODAG in networks
of symmetric links, where the two directions of a link MUST both satisfy
the constraints of the objective function."  s/MUST/must   Because you are
referring to RPL/P2P-RPL, the MUST is not Normative.

[minor] s/as defined in IETF ROLL Working Group [RFC5548]/as defined in
[RFC5548]

[minor] s/application-specific routing requirements...may be satisfied by
routing paths using bidirectional asymmetric links./application-specific
routing requirements may also be satisfied by routing paths using
bidirectional asymmetric links.     I found just one mention of anything
related to asymmetry (in rfc5673)...so I think adding "also" is important.

[minor] "For this purpose, [I-D.thubert-roll-asymlink] described
bidirectional asymmetric links for RPL [RFC6550] with Paired DODAGs, for
which the DAG root (DODAGID) is common for two Instances.  This can satisfy
application-specific routing requirements for bidirectional asymmetric
links in core RPL [RFC6550]."    I think that mention to this draft is
unnecessary and may be confusing to readers: the work seems to have been
abandoned, and if it satisfies the requirements, then why do we need
something else?  ;-)

[minor] I would also take out this sentence: "Using P2P-RPL twice..."

[minor] Expand MoP on first use.  BTW, rfc6550 uses MOP (not MoP), please
be consistent.

[minor] "Both discovered routes (upward and downward) meet the application
specific metrics and constraints that are defined in the Objective Function
for each Instance [RFC6552]."   I didn't find any talk of application
specific metrics in rfc6552.


...
170 2.  Terminology

172   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
173   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
174   "OPTIONAL" in this document are to be interpreted as described in
175   [RFC2119], [RFC8174].  This document uses the following terms:

[major] Please use the rfc8174 template without modifications.


...
264 3.  Overview of AODV-RPL

[minor] It would be very nice if this overview had forward references to
where the behavior is specified.

266   With AODV-RPL, routes from OrigNode to TargNode within the LLN
267   network are established "on-demand".  In other words, the route
268   discovery mechanism in AODV-RPL is invoked reactively when OrigNode
269   has data for delivery to the TargNode but existing routes do not
270   satisfy the application's requirements.  The routes discovered by
271   AODV-RPL are not constrained to traverse a common ancestor.  Unlike
272   RPL [RFC6550] and P2P-RPL [RFC6997], AODV-RPL can enable asymmetric
273   communication paths in networks with bidirectional asymmetric links.
274   For this purpose, AODV-RPL enables discovery of two routes: namely,
275   one from OrigNode to TargNode, and another from TargNode to OrigNode.
276   When possible, AODV-RPL also enables symmetric route discovery along
277   Paired DODAGs (see Section 5).

[major] I get the impression that this document is an extension to RPL, to
be used when the existing routes don't meet specific requirements...at this
point the reactive part would kick in.  Is that a fair characterization?

The document jumps into talking about the extension, but it says nothing
about how the base RPL is used with it...or even if it is.  Please spend a
paragraph explaining that relationship.

279   In AODV-RPL, routes are discovered by first forming a temporary DAG
280   rooted at the OrigNode.  Paired DODAGs (Instances) are constructed
281   according to the AODV-RPL Mode of Operation (MoP) during route
282   formation between the OrigNode and TargNode.  The RREQ-Instance is
283   formed by route control messages from OrigNode to TargNode whereas
284   the RREP-Instance is formed by route control messages from TargNode
285   to OrigNode.  Intermediate routers join the Paired DODAGs based on
286   the rank as calculated from the DIO message.  Henceforth in this
287   document, the RREQ-DIO message means the AODV-RPL mode DIO message
288   from OrigNode to TargNode, containing the RREQ option (see
289   Section 4.1).  Similarly, the RREP-DIO message means the AODV-RPL
290   mode DIO message from TargNode to OrigNode, containing the RREP
291   option (see Section 4.2).  The route discovered in the RREQ-Instance
292   is used for transmitting data from TargNode to OrigNode, and the
293   route discovered in RREP-Instance is used for transmitting data from
294   OrigNode to TargNode.

[nit] s/rank/Rank/g   To be consistent with how rfc6550 uses the term.

296 4.  AODV-RPL DIO Options

298 4.1.  AODV-RPL DIO RREQ Option

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

[major] What should a receiver do if more than one RREQ options are
received?

303      0                   1                   2                   3
304      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
305     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
306     |     Type      | Option Length |S|H|X| Compr | L |   MaxRank   |
307     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
308     |  Orig SeqNo   |                                               |
309     +-+-+-+-+-+-+-+-+                                               |
310     |                                                               |
311     |                                                               |
312     |           Address Vector (Optional, Variable Length)          |
313     |                                                               |
314     |                                                               |
315     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

317             Figure 1: DIO RREQ option format for AODV-RPL MoP

319   OrigNode supplies the following information in the RREQ option:

321   Type
322      The type assigned to the RREQ option (see Section 9.2).

[major] s/Type/Option Type/g   That is the name in rfc6550.

[minor] Use TBDx so that it matches the IANA Considerations section.  The
same applies to other places where TBDx can be used.

...
348   L

350      2-bit unsigned integer determining the duration that a node is
351      able to belong to the temporary DAG in RREQ-Instance, including
352      the OrigNode and the TargNode.  Once the time is reached, a node
353      MUST leave the DAG and stop sending or receiving any more DIOs for
354      the temporary DODAG.  The definition for the "L" bit is similar to
355      that found in [RFC6997], except that the values are adjusted to
356      enable arbitrarily long route lifetime.

[major] "definition for the "L" bit is similar to that found in [RFC6997],
except that..."   I think that this statement may be confusing to
readers...remove it.

358      *  0x00: No time limit imposed.
359      *  0x01: 16 seconds
360      *  0x02: 64 seconds
361      *  0x03: 256 seconds

363      L is independent from the route lifetime, which is defined in the
364      DODAG configuration option.  The route entries in hop-by-hop
365      routing and states of source routing can still be maintained even
366      after the DAG expires.

[??] I don't understand what the last sentence is trying to say.  It sounds
as if the information learned through the DAG can still be used after the
DAG expires...up until the route lifetime expires...is that it?  Please
clarify.


...
373   Orig SeqNo
374      Sequence Number of OrigNode, defined similarly as in AODV
375      [RFC3561].

[major] "similarly as in AODV"  Similarly, or the same??  Note that this
reference could require rfc3561 to be a Normative Reference.

I found this text in §6.1, which defines this field.  Which one is
correct?  Suggestion: point to §6.1.

   Each node maintains a sequence number, which rolls over like a
   lollipop counter [Perlman83]; refer to section 7.2 of [RFC6550] for
   detailed operation.  When the OrigNode initiates a route discovery
   process, it MUST increase its own sequence number to avoid conflicts
   with previously established routes.  The sequence number is carried
   in the OrigSeqNo field of the RREQ option.


...
382   A node MUST NOT join a RREQ instance if its own rank would equal to
383   or higher than MaxRank.  Targnode can join the RREQ instance at a
384   rank whose integer portion is equal to the MaxRank.  A router MUST
385   discard a received RREQ if the integer part of the advertised rank
386   equals or exceeds the MaxRank limit.  This definition of MaxRank is
387   the same as that found in [RFC6997].

[minor] s/own rank would equal to/own rank would be equal to

[nit] s/Targnode/TargNode

[minor] The second sentence sounds like it contradicts the first one (where
it says that "A node MUST NOT join..."); I think that inverting the order
would help:

   TargNode can join the RREQ instance at a rank whose integer portion is
   equal to the MaxRank.  Other nodes MUST NOT join a RREQ instance if its
   own rank is equal to or higher than MaxRank.


[major] "This definition of MaxRank is the same as that found in
[RFC6997]."  True, for the most part: the context of the definition is
different.  Because the definition are not exactly the same, and MaxRank is
defined in this document, please take the sentence out.  I don't think it
adds anything significant.


389 4.2.  AODV-RPL DIO RREP Option

391   TargNode sets its IPv6 address in the DODAGID field of the RREP-DIO
392   message.  A RREP-DIO message MUST carry exactly one RREP option.
393   TargNode supplies the following information in the RREP option:

[major] What should the receiver do if more than one RREP option is
received?


...
441   Shift
442      6-bit unsigned integer.  This field is used to recover the
443      original InstanceID (see Section 6.3.3); 0 indicates that the
444      original InstanceID is used.

[major] s/InstanceID/RPLInstanceID/g

446   Rsv
447      MUST be initialized to zero and ignored upon reception.

[major] Do you expect these bits to be assigned by IANA in the future?


...
456 4.3.  AODV-RPL DIO Target Option

458   The AODV-RPL Target (ART) Option is based on the Target Option in
459   core RPL [RFC6550].  The Flags field is replaced by the Destination
460   Sequence Number of the TargNode and the Prefix Length field is
461   reduced to 7 bits so that the value is limited to be no greater than
462   127.

[minor] What is the name of this option: "AODV-RPL DIO Target Option" or
"AODV-RPL Target Option"?  Please be consistent.

[??] "the Prefix Length field is reduced to 7 bits so that the value is
limited to be no greater than 127."  Why?  Is there an advantage?
Seriously, I'm curious.

464   A RREQ-DIO message MUST carry at least one ART Option.  A RREP-DIO
465   message MUST carry exactly one ART Option.

[major] What should a node do if more than one ART Option is received in a
RREP-DIO message?

467   OrigNode can include multiple TargNode addresses via multiple AODV-
468   RPL Target Options in the RREQ-DIO, for routes that share the same
469   constraints.  This reduces the cost to building only one DODAG.
470   Furthermore, a single Target Option can be used for different
471   TargNode addresses if they share the same prefix; in that case the
472   use of the destination sequence number is not defined in this
473   document.

[major] To be clear, what are the "constraints"?  Where are they
defined/signaled?  Are you talking about the contents of the RREQ Option
(S, H, MaxRank...anything else?)?  If so, please point that out explicitly;
"constraints" are mentioned in different places, but I couldn't find an
explicit definition.

[major] "...in that case the use of the destination sequence number is not
defined in this document."   Then that means that this last feature is not
supported...right?  If that's true, then please don't mention it.


...
511   Target Prefix / Address
512      (variable-length field) An IPv6 destination address or prefix.
513      The Prefix Length field contains the number of valid leading bits
514      in the prefix.  The bits in the Target Prefix / Address field
515      after the prefix length (if any) MUST be set to zero on
516      transmission and MUST be ignored on receipt.

[major] "The bits in the Target Prefix / Address field after the prefix
length (if any)..."   I can see how this "is ok" because the receiver knows
of these trailing bits from the Option Length...*but*, why even allow it?
Why would the Target Prefix / Address not simply have a length = Prefix
Length?

BTW, I know that rfc6550 has the same definition.  That doesn't make it
right.  Every extra bit has a cost...prefixes are elided, and here extra
bits are allowed.


518 5.  Symmetric and Asymmetric Routes

520   In Figure 4 and Figure 5, BR is the Border Router, O is the OrigNode,
521   R is an intermediate router, and T is the TargNode.  If the RREQ-DIO
522   arrives over an interface that is known to be symmetric, and the 'S'
523   bit is set to 1, then it remains as 1, as illustrated in Figure 4.
524   If an intermediate router sends out RREQ-DIO with the 'S' bit set to
525   1, then all the one-hop links on the route from the OrigNode O to
526   this router meet the requirements of route discovery, and the route
527   can be used symmetrically.

[nit] A couple of places use "S bit", "'S' bit" is used above (and in most
of the document)...please be consistent.   Recommendation: S bit or S-bit.
  [BTW, please apply the same style to the other bits.]


...
552   Upon receiving a RREQ-DIO with the 'S' bit set to 1, a node
553   determines whether this one-hop link can be used symmetrically, i.e.,
554   both the two directions meet the requirements of data transmission.
555   If the RREQ-DIO arrives over an interface that is not known to be
556   symmetric, or is known to be asymmetric, the 'S' bit is set to 0.  If
557   the 'S' bit arrives already set to be '0', it is set to be '0' on
558   retransmission (Figure 5).  Therefore, for asymmetric route, there is
559   at least one hop which doesn't fulfill the constraints in the two
560   directions.  Based on the 'S' bit received in RREQ-DIO, the TargNode
561   T determines whether or not the route is symmetric before
562   transmitting the RREP-DIO message upstream towards the OrigNode O.

[nit] s/for asymmetric route/for an asymmetric route

564   The criteria used to determine whether or not each link is symmetric
565   is beyond the scope of the document, and may be implementation-
566   specific.  For instance, intermediate routers MAY use local
567   information (e.g., bit rate, bandwidth, number of cells used in
568   6tisch), a priori knowledge (e.g. link quality according to previous
569   communication) or use averaging techniques as appropriate to the
570   application.

[major] s/MAY/may   This may is not Normative because there is no specific
action (just examples).


...
602 6.1.  Route Request Generation
...
614   Each node maintains a sequence number, which rolls over like a
615   lollipop counter [Perlman83]; refer to section 7.2 of [RFC6550] for
616   detailed operation.  When the OrigNode initiates a route discovery
617   process, it MUST increase its own sequence number to avoid conflicts
618   with previously established routes.  The sequence number is carried
619   in the OrigSeqNo field of the RREQ option.

[minor] s/Each node maintains a sequence number...detailed operation./Each
node maintains a sequence number; the operation is specified in section 7.2
of [RFC6550].

...and take the reference to Perlman83 out.  It is enough for the
specification to be done once; rfc6550 already took care of it.

[nit] s/OrigSeqNo/Orig SeqNo


...
632   The transmission of RREQ-DIO obeys the Trickle timer.  If the
633   duration specified by the "L" bit has elapsed, the OrigNode MUST
634   leave the DODAG and stop sending RREQ-DIOs in the related
635   RPLInstance.

[minor] "The transmission of RREQ-DIO obeys the Trickle timer."   A
reference would be nice.


637 6.2.  Receiving and Forwarding RREQ messages

639 6.2.1.  General Processing

641   Upon receiving a RREQ-DIO, a router which does not belong to the
642   RREQ-instance goes through the following steps:

[nit] s/RREQ-instance/RREQ-Instance/g

[major] What if you do belong to the instance?  I'm assuming that RREQ can
be sent once the DODAG is built...or would what require a difference
RPLInstance?

644   Step 1:

646      If the 'S' bit in the received RREQ-DIO is set to 1, the router
647      MUST check the two directions of the link by which the RREQ-DIO is
648      received.  In case that the downward (i.e. towards the TargNode)
649      direction of the link can't fulfill the requirements, the link
650      can't be used symmetrically, thus the 'S' bit of the RREQ-DIO to
651      be sent out MUST be set as 0.  If the 'S' bit in the received
652      RREQ-DIO is set to 0, the router only checks into the upward
653      direction (towards the OrigNode) of the link.

[major] "the router MUST check the two directions of the link"  How is the
link checked?

[major] "If the 'S' bit...is set to 0..."  The action for when the S bit is
set to 1 was defined using MUST...should this action also include Normative
Language?

655      If the upward direction of the link can fulfill the requirements
656      indicated in the constraint option, and the router's rank would
657      not exceed the MaxRank limit, the router joins the DODAG of the
658      RREQ-Instance.  The router that transmitted the received RREQ-DIO
659      is selected as the preferred parent.  Later, other RREQ-DIO
660      messages might be received.  How to maintain the parent set,
661      select the preferred parent, and update the router's rank obeys
662      the core RPL and the OFs defined in ROLL WG.  In case that the
663      constraint or the MaxRank limit is not fulfilled, the router MUST
664      discard the received RREQ-DIO and MUST NOT join the DODAG.

[major] What is the "constraint option"?

[minor] "How to maintain the parent set, select the preferred parent, and
update the router's rank obeys the core RPL and the OFs defined in ROLL
WG."  If there's no change, then I think this sentence is not needed.  If
you want to keep it, then please reference specific documents and don't
just point to the WG (in fact, don't point to the WG because the persistent
references are documents).


...
672   Step 3:

674      If the 'H' bit is set to 1, then the router (TargNode or
675      intermediate) MUST build the upward route entry accordingly.  The
676      route entry MUST include at least the following items: Source
677      Address, InstanceID, Destination Address, Next Hop, Lifetime, and
678      Sequence Number.  The Destination Address and the InstanceID can
679      be respectively learned from the DODAGID and the RPLInstanceID of
680      the RREQ-DIO, and the Source Address is copied from the ART
681      Option.  The next hop is the preferred parent.  The lifetime is
682      set according to DODAG configuration and can be extended when the
683      route is actually used.  The sequence number represents the
684      freshness of the route entry, and it is copied from the Orig SeqNo
685      field of the RREQ option.  A route entry with same source and
686      destination address, same InstanceID, but stale sequence number,
687      SHOULD be deleted.

[major] "...MUST build the upward route entry accordingly."  I was going to
ask what does "accordingly" mean, but the next sentence indicates what it
has to include.  Instead of having two sentences trying to specify the same
thing, please collapse them into one.

[minor] This route is to OrigNode, correct?  Please say so.  I know that it
has been mentioned that the RREQ-Instance is used for that -- remind the
reader.

[major] "...the Source Address is copied from the ART Option."   What is
the "Source Address"?  I ask because I assumed that it is the address used
by the local router to send data to the OrigNode, but the only address in
the ART Option is the "Target Prefix".  What am I missing?

[nit] Please be consistent in how names are used.  For example, the
paragraph above uses both "Next Hop" and "next hop" to refer to the same
thing.

[minor] "The lifetime is set according to DODAG configuration and can be
extended when the route is actually used."  I think that this is a little
confusing, because you seem to be talking about route lifetime and not the
L (which I interpreted as lifetime too) value in the RREQ Option, right?
Please be specific.

[nit] s/entry with same source/entry with the same source

[major] "A route entry with same source and destination address, same
InstanceID, but stale sequence number, SHOULD be deleted."  When would it
be ok to not delete the entry?  IOW, why is that not a MUST?

689      If the 'H' bit is set to 0, an intermediate router MUST include
690      the address of the interface receiving the RREQ-DIO into the
691      address vector.

[major] Step 3 (at least the first paragraph) seems to be about building a
route entry.  What is different if the H bit is set to 0?  How is the route
entry built?

[minor] This last paragraph talks about forwarding the RREQ, so perhaps it
fits better in the next step.

693   Step 4:

695      An intermediate router transmits a RREQ-DIO via link-local
696      multicast.  TargNode prepares a RREP-DIO.

[minor] "TargNode prepares a RREP-DIO."  Please add a forward reference to
§6.3.

698 6.2.2.  Additional Processing for Multiple Targets

700   If the OrigNode tries to reach multiple TargNodes in a single RREQ-
701   instance, one of the TargNodes can be an intermediate router to the
702   others, therefore it SHOULD continue sending RREQ-DIO to reach other
703   targets.  In this case, before rebroadcasting the RREQ-DIO, a
704   TargNode MUST delete the Target Option encapsulating its own address,
705   so that downstream routers with higher ranks do not try to create a
706   route to this TargetNode.

[major] "...one of the TargNodes can be an intermediate router to the
others, therefore it SHOULD continue sending RREQ-DIO to reach other
targets."  When would a TargNode choose not to forward the RREQ?  IOW, why
is that not a MUST?

708   An intermediate router could receive several RREQ-DIOs from routers
709   with lower ranks in the same RREQ-instance but have different lists
710   of Target Options.  When rebroadcasting the RREQ-DIO, the
711   intersection of these lists SHOULD be included.  For example, suppose
712   two RREQ-DIOs are received with the same RPLInstance and OrigNode.
713   Suppose further that the first RREQ has (T1, T2) as the targets, and
714   the second one has (T2, T4) as targets.  Then only T2 needs to be
715   included in the generated RREQ-DIO.  If the intersection is empty, it
716   means that all the targets have been reached, and the router SHOULD
717   NOT send out any RREQ-DIO.  Any RREQ-DIO message with different ART
718   Options coming from a router with higher rank is ignored.

[major] "...the intersection of these lists SHOULD be included."  When
would a node not include the intersection?  IOW, why is this not a MUST?

[major] "If the intersection is empty...the router SHOULD NOT send out any
RREQ-DIO."  When would it be ok to sent the RREQ out?  If there are no
targets, then it seems like you would never want to.  IOW, why is that not
a MUST NOT?

[minor] I'm not sure about the intersection logic above...but maybe I'm
missing something.  The example seems to imply that every RREQ should
include all outstanding targets (?)...so that comparing the first one (T1,
T2) with the second (T2, T4), implies that T1 has been found...is that
correct?  If so, then it looks like T4 is still a valid target, but the
intersection wouldn't include it.  What am I missing?

[minor] Related:  The specification above only applies to the period of
time between receiving the first RREQ and the initial rebroadcast, right?
IOW, if a RREQ is received and rebroadcast....and then a second RREQ is
received (with a different list of targets), then the rebroadcast should
not include just the intersection, right?

720 6.3.  Generating Route Reply (RREP) at TargNode

722 6.3.1.  RREP-DIO for Symmetric route

724   If a RREQ-DIO arrives at TargNode with the 'S' bit set to 1, there is
725   a symmetric route along which both directions can fulfill the
726   requirements.  Other RREQ-DIOs might later provide asymmetric upward
727   routes (i.e.  S=0).  Selection between a qualified symmetric route
728   and an asymmetric route that might have better performance is
729   implementation-specific and out of scope.  If the implementation uses
730   the symmetric route, the TargNode MAY delay transmitting the RREP-DIO
731   for duration RREP_WAIT_TIME to await a better symmetric route.

[major] RREP_WAIT_TIME is not defined anywhere.

[major] "...a better symmetric route."  What makes a route better?

733   For a symmetric route, the RREP-DIO message is unicast to the next
734   hop according to the accumulated address vector (H=0) or the route
735   entry (H=1).  Thus the DODAG in RREP-Instance does not need to be
736   built.  The RPLInstanceID in the RREP-Instance is paired as defined
737   in Section 6.3.3.  In case the 'H' bit is set to 0, the address
738   vector received in the RREQ-DIO MUST be included in the RREP-DIO.
739   TargNode increments its current sequence number and uses the
740   incremented result in the Dest SeqNo in the ART option of the RREQ-
741   DIO.  The address of the OrigNode MUST be encapsulated in the ART
742   Option and included in this RREP-DIO message.

744 6.3.2.  RREP-DIO for Asymmetric Route

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

[minor] The previous section talked about delaying the RREP.  Should that
be considered here too?

752   The settings of the fields in RREP option and ART option are the same
753   as for the symmetric route, except for the 'S' bit.

755 6.3.3.  RPLInstanceID Pairing

[minor] Pairing only applied to symmetric routes, right?  Please say so.

757   Since the RPLInstanceID is assigned locally (i.e., there is no
758   coordination between routers in the assignment of RPLInstanceID), the
759   tuple (OrigNode, TargNode, RPLInstanceID) is needed to uniquely
760   identify a discovered route.  The upper layer applications may have
761   different requirements and they can initiate the route discoveries
762   simultaneously.  Thus between the same pair of OrigNode and TargNode,
763   there can be multiple AODV-RPL instances.  To avoid any mismatch, the
764   RREQ-Instance and the RREP-Instance in the same route discovery MUST
765   be paired somehow, e.g. using the RPLInstanceID.

[minor] "The upper layer applications may have different requirements and
they can initiate the route discoveries simultaneously."  The applications
don't initiate route discovery...  Application requirements are mentioned
several times in this document, but it is not clear to me how those
requirements are reflected in the RREQ.

[major] "..MUST be paired somehow, e.g. using the RPLInstanceID."  There is
no clear Normative action here.  s/MUST/must


...
782 6.4.  Receiving and Forwarding Route Reply

[-] Some of the comments above apply to this section too.


...
803      If the constraints are not fulfilled, the router MUST NOT join the
804      DODAG; the router MUST discard the RREQ-DIO, and does not execute
805      the remaining steps in this section.

[nit] s/and does not execute/and not execute


...
813   Step 3:

815      If the 'H' bit is set to 1, then the router (OrigNode or
816      intermediate) MUST build a downward route entry.  The route entry
817      SHOULD include at least the following items: OrigNode Address,
818      InstanceID, TargNode Address as destination, Next Hop, Lifetime
819      and Sequence Number.  For a symmetric route, the next hop in the
820      route entry is the router from which the RREP-DIO is received.
821      For an asymmetric route, the next hop is the preferred parent in
822      the DODAG of RREQ-Instance.  The InstanceID in the route entry
823      MUST be the original RPLInstanceID (after subtracting the Shift
824      field value).  The source address is learned from the ART Option,
825      and the destination address is learned from the DODAGID.  The
826      lifetime is set according to DODAG configuration and can be
827      extended when the route is actually used.  The sequence number
828      represents the freshness of the route entry, and is copied from
829      the Dest SeqNo field of the ART option of the RREP-DIO.  A route
830      entry with same source and destination address, same InstanceID,
831      but stale sequence number, SHOULD be deleted.

[major] The description in §6.2.1 says that the "route entry MUST
include...".  Why is SHOULD used in this case?  When is it ok to not
include these items?  Should the same apply to §6.2.1?


...
851 7.  Gratuitous RREP

[minor] This section introduces T and O (instead of TargNode/OrigNode) to
explain the operation.  That is not a bad thing, but I think that having
consistent terminology is a really good thing.


...
872   In case of hop-by-hop routing, R MUST unicast the received RREQ-DIO
873   hop-by-hop to T.  The routers along the route SHOULD build new route
874   entries with the related RPLInstanceID and DODAGID in the downward
875   direction.  Then T MUST unicast the RREP-DIO hop-by-hop to R, and the
876   routers along the route SHOULD build new route entries in the upward
877   direction.  Upon receiving the unicast RREP-DIO, R sends the
878   gratuitous RREP-DIO to the OrigNode as defined in Section 6.3.

[major] I don't understand how the "routers along the route" can do
anything if the messages are unicast...??

880 8.  Operation of Trickle Timer

882   The trickle timer operation to control RREQ-Instance/RREP-Instance
883   multicast is similar to that in P2P-RPL [RFC6997].

[major] "The trickle timer operation...is similar to that in P2P-RPL
[RFC6997]."  Similar, or the same??

Note that if it is the same, then rfc6997 would have to be a Normative
Reference.

885 9.  IANA Considerations

887 9.1.  New Mode of Operation: AODV-RPL

889   IANA is required to assign a new Mode of Operation, named "AODV-RPL"
890   for Point-to-Point(P2P) hop-by-hop routing under the RPL registry.
891   The value of TBD1 is assigned from the "Mode of Operation" space
892   [RFC6550].

[major] NEW>
   IANA is asked to assign a new Mode of Operation, named "AODV-RPL"
   for Point-to-Point(P2P) hop-by-hop routing from the "Mode of Operation"
   Registry [RFC6550].


894              +-------------+---------------+---------------+
895              |    Value    |  Description  |   Reference   |
896              +-------------+---------------+---------------+
897              |   TBD1 (5)  |   AODV-RPL    | This document |
898              +-------------+---------------+---------------+

900                        Figure 6: Mode of Operation

902 9.2.  AODV-RPL Options: RREQ, RREP, and Target

904   Three entries are required for new AODV-RPL options "RREQ", "RREP"
905   and "ART" with values of TBD2 (0x0A), TBD3 (0x0B) and TBD4 (0x0C)
906   from the "RPL Control Message Options" space [RFC6550].

[major] NEW>
   IANA is asked to assign three new AODV-RPL options "RREQ", "RREP" and
   "ART", as described in Figure 7 from the "RPL Control Message Options"
   Registry [RFC6550].

908          +-------------+------------------------+---------------+
909          |    Value    |        Meaning         |   Reference   |
910          +-------------+------------------------+---------------+
911          | TBD2 (0x0A) |      RREQ Option       | This document |
912          +-------------+------------------------+---------------+
913          | TBD3 (0x0B) |      RREP Option       | This document |
914          +-------------+------------------------+---------------+
915          | TBD3 (0x0C) |       ART Option       | This document |
916          +-------------+------------------------+---------------+

918                        Figure 7: AODV-RPL Options

920 10.  Security Considerations

922   The security mechanisms defined in section 10 of [RFC6550] and
923   section 11 of [RFC6997] can also be applied to the control messages
924   defined in this specification.  The RREQ-DIO and RREP-DIO both have a
925   secure variant, which provide integrity and replay protection as well
926   as optional confidentiality and delay protection.

[major] rfc6997/§11 mostly talks about the processing of the new messages
defined there.  How does that apply to this document?

[major] rfc6997 says that section "10 of [RFC6550] describe RPL's security
framework...This security framework can also be used in P2P-RPL after
taking into account the constraints specified in Section 11."  How does
that apply to this document if both "section 10 of [RFC6550] and section 11
of [RFC6997]" are mentioned above?

[minor] §3 talks about the fact that an RREQ-DIO is a DIO message with the
rREQ Option (and there's similar text for the RREP-DIO).  However, I think
it's confusing to the reader to mention that there are secure variants.  I
think that expanding the description (at the end of §3) of what exactly the
*-DIO messages are (and that the definition includes the secure variants)
would go a long way.

928   AODV-RPL can operate in the three security modes defined in
929   [RFC6550].  AODV-RPL messages SHOULD use a security mode at least as
930   strong as the security mode used in RPL.

[major] "AODV-RPL messages SHOULD use a security mode at least as strong as
the security mode used in RPL."  What does that mean?  As I asked before,
what is the relationship in the network between RPL and AODV-RPL.  I have
been assuming that the Options are simply included as an "add-on" to the
base RPL already running, but this statement seems to imply that they are
completely independent if they can have different security modes.   ??

932   o  Unsecured.  In this mode, RREQ-DIO and RREP-DIO are used without
933      any security fields as defined in section 6.1 of [RFC6550].  The
934      control messages can be protected by other security mechanisms,
935      e.g. link-layer security.  This mode SHOULD NOT be used when RPL
936      is using Preinstalled mode or Authenticated mode (see below).

[major] There is a Normative contradiction: (above) "This mode SHOULD NOT
be used when RPL is using Preinstalled mode or Authenticated mode (see
below)." ...and... (below) "Unsecured messages MUST be dropped."  It seems
to me that maybe s/SHOULD NOT/MUST NOT

[major] Related:  There's no indication on what should be done with
unsecured messages in Authenticated mode.  I'm assuming the same drop
action.

938   o  Preinstalled.  In this mode, AODV-RPL uses secure RREQ-DIO and
939      RREP-DIO messages, and a node wishing to join a secured network
940      will have been pre-configured with a shared key.  A node can use
941      that key to join the AODV-RPL DODAG as a host or a router.
942      Unsecured messages MUST be dropped.  This mode SHOULD NOT be used
943      when RPL is using Authenticated mode.

[major] When is it ok to use this mode with Authenticated mode?  IOW, why
is that not a MUST NOT?

...
961 11.  Future Work

[minor] This section sounds appropriate for an Experimental document and
not one in the Standards Track.

[major] I would expect some of the items below to be specified in a
Standards Track document.  For instance, "the initial state of a link"
seems pretty basic. Put another way, what should be the settings (for the
items mentioned here)?

963   There has been some discussion about how to determine the initial
964   state of a link after an AODV-RPL-based network has begun operation.
965   The current draft operates as if the links are symmetric until
966   additional metric information is collected.  The means for making
967   link metric information is considered out of scope for AODV-RPL.  In
968   the future, RREQ and RREP messages could be equipped with new fields
969   for use in verifying link metrics.  In particular, it is possible to
970   identify unidirectional links; an RREQ received across a
971   unidirectional link has to be dropped, since the destination node
972   cannot make use of the received DODAG to route packets back to the
973   source node that originated the route discovery operation.  This is
974   roughly the same as considering a unidirectional link to present an
975   infinite cost metric that automatically disqualifies it for use in
976   the reverse direction.

[major] "The current draft operates as if the links are symmetric until
additional metric information is collected."  §6 mandates a check to
determine the state symmetry.  How is that (unspecified) check related to
this text?  It seems to be that it is the same thing; is it?

978 12.  Contributors

[minor] In general Contributors are listed list before the Author's Address
at the bottom [rfc7322].


...
1060 Appendix A.  Example: ETX/RSSI Values to select S bit

[minor] Please expand ETX/RSSI on first mention (§5).

1062   We have tested the combination of "RSSI(downstream)" and "ETX
1063   (upstream)" to determine whether the link is symmetric or asymmetric
1064   at the intermediate nodes.  The example of how the ETX and RSSI
1065   values are used in conjuction is explained below:

[style nit] Don't write in the first person ("We have...").

[minor] It would be really nice to provide a reference for these tests.

[minor] Add references for ETX/RSSI.

[nit] s/conjuction/conjunction


...
1083   We tested the operations in this specification by making the
1084   following experiment, using the above parameters.  In our experiment,
1085   a communication link is considered as symmetric if the ETX value of
1086   NodeA->NodeB and NodeB->NodeA (See Figure.8) are, say, within 1:3
1087   ratio.  This ratio should be taken as a notional metric for deciding
1088   link symmetric/asymmetric nature, and precise definition of the ratio
1089   is beyond the scope of the draft.  In general, NodeA can only know
1090   the ETX value in the direction of NodeA -> NodeB but it has no direct
1091   way of knowing the value of ETX from NodeB->NodeA.  Using physical
1092   testbed experiments and realistic wireless channel propagation
1093   models, one can determine a relationship between RSSI and ETX
1094   representable as an expression or a mapping table.  Such a
1095   relationship in turn can be used to estimate ETX value at nodeA for
1096   link NodeB--->NodeA from the received RSSI from NodeB.  Whenever
1097   nodeA determines that the link towards the nodeB is bi-directional
1098   asymmetric then the "S" bit is set to "S=0".  Later on, the link from
1099   NodeA to Destination is asymmetric with "S" bit remains to "0".

[nit] s/Figure.8/Figure 8

[nit] s/within 1:3 ratio/within 1:3 a ratio

[nit] s/, and precise definition of the ratio is beyond the scope of the
draft./.    Not needed, this is just an example.

1101 Appendix B.  Changelog

[nit] Add a note to the RFC Editor to remove this section before
publication.