[Roll] Part 1: comment resolutions for AD Review of draft-ietf-roll-aodv-rpl-07

[Charlie Perkins <[e-mail]>]

Hello folks,

Today we have submitted a revised version 8 for our 
draft-ietf-roll-aodv-rpl.  Here is part 1 showing some resolutions for 
comments made by our AD for the improvement of draft-ietf-roll-aodv-rpl-07.

In addition we have done the following:

  * rewrite section 8

  * rewrite RFC 6997 text for AODV-RPL security behaviors

  * provide citations for work in the Appendix

In a few minutes I will also send email with a summary, in a more 
compact format, of the changes that we have made to the draft.

Regards,
Charlie P.



-------- Forwarded Message --------
Subject: 	Fwd: Re: AD Review of draft-ietf-roll-aodv-rpl-07
Date: 	Wed, 29 Apr 2020 12:35:32 -0700
From: 	Charlie Perkins <[e-mail]>
To: 	Alvaro Retana <[e-mail]>
CC: 	S.V.R Anand <[e-mail]>, Remy Liubing 
<[e-mail]>, Satish Anamalamudi <[e-mail]>



Hello Alvaro,

We are preparing a new revision of draft-ietf-roll-aodv-rpl to be 
released in a day or so.  Here are some resolutions for most of your 
comments.  The other points have also been addressed as you will see in 
the new revision.

Regards,
Charlie P.



-------- Forwarded Message --------
Subject: 	Re: AD Review of draft-ietf-roll-aodv-rpl-07
Date: 	Sun, 29 Mar 2020 12:51:52 -0700
From: 	Charlie Perkins <[e-mail]>
To: 	Satish Anamalamudi <[e-mail]>, S.V.R Anand 
<[e-mail]>, Remy Liubing <[e-mail]>


...

Regards,
Charlie P.



On 8/1/2019 7:54 AM, Alvaro Retana 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..

I think the new Introduction goes a long way towards resolving this comment.


>
>
> (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?

In my understanding it is intended to be a Proposed Standard so that 
implementors have a Standard available (i.e., do not have to rely on 
Experimental protocols).


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

My preference would be for AODV-RPL to replace RFC 6997.  We were 
requested to include features from RFC 6997, with the understanding that 
doing so would eliminate the value of implementing RFC 6997.


>
>
> (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.
I think this is all about evaluating the Objective Function for the 
links.  We just have to specify that the router evaluates the Objective 
Function to see if the link satisfies the Function.
.................
>
> ...
> 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
>
> 17Abstract
>
> 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)

How about:

  AODV based RPL Extensions for Supporting Asymmetric P2P Links in Low-
                     Power and Lossy Networks


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


How about replacing the first three paragraphs with the following:

    AODV-RPL specifies P2P route discovery, utilizing RPL [RFC6550] (Routing
    Protocol for Low-Power and Lossy Networks) with a new MOP (Mode Of
    Operation).  Routes are discovered using two multicast messages
    to discover routes that may traverse asymmetric links. This promotes
    higher route diversity, often reducing interference near root nodes.
    More importantly, AODV-RPL can enable applications to run that might
    otherwise fail, in networks containing suitable asymmetric routes but
    no symmetric routes as would be required by RPL or P2P-RPL [RFC6997].
    As an extra benefit, AODV-RPL eliminates the need for address vector
    overhead in hop-by-hop mode, significantly reducing the control
    packet size.


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


If you have particular examples in mind please let us know. I'll take a 
look and see what sticks out.


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


Done, subject to the above.


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

Done.

>
> [nit] s/is a IPv6/is an IPv6
Fixed.

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

Done.  Maybe twice :-)


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

Done, subject to preference for the shorter Introduction introduction.


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

Fixed.


>
> [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..."
Done.
>
> [minor] Expand MoP on first use. BTW, rfc6550 uses MOP (not MoP), 
> please be consistent.
Done.
>
> [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.

I think the citation was intended for "Objective Function", not 
Instance.  And anyway the reference should probably be to RFC 6550.


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

Done.


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

Not really.  AODV-RPL uses some of the base RPL specification but does 
not require an instance of RPL to run.  I put in some additional 
clarifying text about this.  I think it also resolves the next comment.


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

See the last point of discussion.


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

Fixed.  I hope that all instances of "rank" are O.K. to be capitalized.


>
> 2964. AODV-RPL DIO Options
>
> 2984.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?

I specified that it SHOULD be dropped.  I don't think this is too harsh, 
even though other solutions are possible.


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

Fixed.


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

Fixed.


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

Done.


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

How about this:

The route entries in hop-by-hop routing
     and states of source routing can still be maintained
     even after the node no longer maintains DAG connectivity or
     messaging.

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

Fixed, by deleting the reference.  Would it be useful to make a 
reference to AODV's sequence number operation in the Introduction?


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

Fixed.


>
>
> ...
> 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.
>
Done, done, and done.


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

Done.


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

How about:

           A RREP-DIO message MUST carry exactly one RREP option,
     otherwise the message SHOULD be dropped.

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

Done.


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

No, but a future specification could modify the operation. Do we need to 
say that?


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

Hopefully fixed.


>
> [??] "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.

Well, I don't think there are any prefixes longer than 127 bits.


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

How about:

     A RREQ-DIO message MUST carry at least one ART Option.  A RREP-DIO
     message MUST carry exactly one ART Option. Otherwise, the message
     SHOULD be dropped.

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

I changed instances of "fulfill the constraint" to be "satisfy the 
Objective Function".  I think this resolves the issue.


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

Fixed.


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

The only extra bits that are specified are required in order that the 
option has an integer number of octets.  We do allow prefixes that are 
not an integer number of octets and so some bits have to be specified as 
zero.


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

Fixed.


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

Fixed.


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


>
> ...
> 6026.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
>
Done and done.


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

Fixed.


>
>
> 6376.2. Receiving and Forwarding RREQ messages
>
> 6396.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

Done.


>
> [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?

A new RREQ would require a new RPLInstance, I believe.


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

The router must verify that each direction of the link satisfies the 
Objective Function.  The verification method depends on the Objective 
Function and is out of scope for this document.


>
> [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?

Done.


>
> 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"?

Using Objective Function language instead resolves this comment.


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

Done.

===========================================================================

The remainder of the comments will be posted shortly.


Regards,
Charlie P.