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

[Ines Robles <[e-mail]>]

Thank you Alvaro for the review,

The tickets #194, #195, #196, #197, #198  were created to address the
issues [1].

Related to ticket #195 (Document Status), we are going to discuss it into
the ML.

Best regards,

Ines.

[1] https://trac.ietf.org/trac/roll/report/2


On Thu, Aug 1, 2019 at 5:54 PM Alvaro Retana <[e-mail]> wrote:

> 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.
>
>
>