[Roll] AddRE: AD Review of draft-ietf-roll-unaware-leaves-18 (cont)

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Alvaro

As usual I made a commit for a thread; please find the diffs here
https://github.com/roll-wg/roll-unaware-leaves/commit/fdd3fc38319ada9fdd6cb044741593553b1baad5

I'm concerned that maybe the last words of your review were cut again. 

> > I committed the result in the IETF datatracker as draft 22 as a
> > reference since we made major changes already.
> 
> I am including 2 parts below. First a reply to this message (specifically to the -
> 21 comments), and then some comments based on -22.  In some cases I put
> comments on -22 simply because it seemed "cleaner" (so not all the comments
> are new, but a continuation of the discussion).
> 
> This is a quick list of the major items I want to resolve (MUST) before starting
> the IETF LC -- I'm putting it here for my own reference, please put any
> comments inline below and not up here.
> 
> (1) DCO-ACK Status update and registry.

We're progressing on that one; I remove the declaration of the status from the DCO document.

> (2) Mention of Update details in the Introduction.

Done

> (3) Suggested RPL Instance (§9.2.2).

I believe we're one there too, unsure though

> (4) Multicast Operation (§10).
> 

Indicated that it is for MOP 3 only.



> === Part 1: Reply ===
> 
> > > === Part 3: remaining comments (based on -18) ===
> ...
> > But we're also merging the statis with the DCO-ACK Status In that we
> > deprecate
> > https://www.iana.org/assignments/rpl/rpl.xhtml#rpl-dco-ack-status
> 
> That is new!!  I don't even see DCO-ACK mentioned in the document at all.
> 
> Does this mean that §12.5 should also be changed to include the DCO-ACK
> message in it?

Not sure I understand. §12.5 Has the only DCO status, status 1. 
Since DCO is in the RFC Editor Queue, could we change it to remove the new registry before it is even created?


> 
> 
> > So we should update the NPDAO draft and remove that entry shouldn't we?
> > Note that NPDAO is already in missref because of this draft
> > https://www.rfc-editor.org/cluster_info.php?cid=C310
> 
> Yes.
> 
> Also, the specification of the DAO-ACK needs to be changed to at least make it
> clear that the "DCO-ACK Status" field refers to the "RPL Status".
> 
> About deprecating the registry...  We should ask IANA what to do: they already
> created the registry, but the efficient-npdao hasn't been published as an
> RFC.  I don't know if we just delete §6.2 or if we have to formally deprecate the
> registry (possible in this document).
> 
> Please ack to this to make sure we're in sync before asking IANA.
> 

We agree, I created a separate thread to complete that piece with Rahul, who is editor for the NPDAO draft


> 
> 
> ...
> > > 630 To achieve this, Section 13.2 reduces the range of the EARO
> > > Status
> > > 631 values to 0-63 to ensure that they fit within a RPL Status as
> > > shown
> > > 632 in Figure 3.
> ...
> > > [major] What about the ARO? The Status values are shared between the
> > > EARO and the ARO.
> >
> > The IANA update applies to the registry that was created by RFC 6775
> > and updated by RFC 8505.
> > The text actually points at RFC 6775 as the reference for the registry
> > so we are impacting both ARO and EARO.
> 
> Yes.  The point was that we should mention the ARO here as well:
> s/EARO Status/ARO/EARO Status
> 

Understood, done!


> 
> 
> > 12.2. Resizing the ARO Status values
> ...
> > > [major] Changing the range of values is not as easy as updating the
> > > registry...the behavior of the EARO and ARO have to be updated. This
> > > means that this document should Update both rfc6775 and rfc8505
> > > where it relates to the redefined Status field.
> >
> > Isn't this transitive? I mean the field defined in RFC 6775 is updated
> > by RFC 8505.
> 
> No, the updates in rfc8505 are just the ones specified there.
> 
> 
> It would then de ideal if the Update to cut the size of the Status also said that
> the rfc6775/rfc8505 nodes MUST ignore the first two bits.  Note that by
> cutting the size of the Status we're really leaving two bits unused/undefined.
> 

Yes, you're right. I'd say the bits are now "reserved".
"

8.  Enhancements to RFC 6775 and RFC8505

   This document updates [RFC6775] and [RFC8505] to reduce the range of
   the ND status codes down to 64 values.  The two most significant
   (leftmost) bits if the original ND status field are now reserved,
   they MUST be set to zero by the sender and ignored by the receiver.

"


> > > 845 10.2.1. Perspective of the RUL Acting as 6LN
> ...
> > > 871 4. Following section 5.1 of [RFC8505], a 6LN acting as a RUL
> > > sets
> > > 872 the "R" flag in the EARO of at least one registration, whereas
> > > 873 acting as a RAN it never does. If the "R" flag is not echoed in
> > > 874 the NA, the RUL SHOULD attempt to use another 6LR. The RUL
> > > 875 SHOULD send the registration(s) with the "R" flag set and ensure
> > > 876 that one succeeds before it sends the registrations with the
> > > flag
> > > 877 reset. In case of a conflict with the preceeding rule on
> > > 878 lifetime, the rule on lifetime has precedence.
> > >
> ...
> > > [major] "SHOULD send the registration(s) with the "R" flag set and
> > > ensure that one succeeds before it sends the registrations with the
> > > flag reset."
> > >
> > > This text is in conflict with §5.1/rfc8505: "MUST set the R flag to
> > > indicate that it is not a router and that it will not handle its own
> > > reachability". There isn't a provision for a RUL to not set the R
> > > flag.
> >
> > I did not write that text in that meaning. Maybe that's my English.
> > The text is meant to say that it MUST set the R flag if it wishes to
> > indicate that it is not a router and blah.
> 
> Hmm...looking at the whole paragraph, I can see how it could be interpreted
> that way.  In either case, I assume that the intent here is the same: set the R
> flag if it is not a router, etc...and the RUL is not RPL-aware.
> 
> Given that this bullet already starts with "Following section 5.1 of [RFC8505], a
> 6LN acting as a RUL sets the R Flag...", then we don't need to say it again:
> 
> OLD>
>    4.  Following section 5.1 of [RFC8505], a 6LN acting as a RUL sets
>        the R Flag in the EARO of its registration(s) for which it
>        requires routing services.  If the R Flag is not echoed in the
>        NA, the RUL SHOULD attempt to use another 6LR.  The RUL SHOULD
>        send the registration(s) with the R Flag set and ensure that one
>        succeeds before it sends the registrations with the flag reset.
>        In case of a conflict with the preceding rule on lifetime, the
>        rule on lifetime has precedence.
> 
> NEW>
>    4.  Following section 5.1 of [RFC8505], a 6LN acting as a RUL sets
>        the R Flag in the EARO of its registration(s) for which it
>        requires routing services.  If the R Flag is not echoed in the
>        NA, the RUL SHOULD attempt to use another 6LR.  The RUL SHOULD
>        ensure that one registration succeeds before resetting the R Flag.
>        In case of a conflict with the preceding rule on lifetime, the
>        rule on lifetime has precedence.
> 
> 

Applied, thanks!


> ...
> > >
> > > rfc6550 has no information about "pending" DAOs, or how fast the
> > > DAO-ACK is to be sent. In fact, there is no firm requirement for the
> > > DAO-ACK to exist, just hope that it does:
> > >
> > > - §6.4/rfc6550: "The DAO message may optionally, upon explicit
> > > request or error, be acknowledged by its destination with a
> > > Destination Advertisement Acknowledgement (DAO-ACK) message back to
> > > the sender of the DAO."
> > >
> > > This sentence suggests that the DAO-ACK is optional, even if
> > > requested, and §9.3/rfc6550 supports that:
> > >
> > > " 3. A node MAY set the 'K' flag in a unicast DAO message to solicit
> > > a unicast DAO-ACK in response in order to confirm the attempt.
> > >
> > > 4. A node receiving a unicast DAO message with the 'K' flag set
> > > SHOULD respond with a DAO-ACK. A node receiving a DAO message
> > > without the 'K' flag set MAY respond with a DAO-ACK, especially to
> > > report an error condition.
> > > "
> > >
> > > Note that "SHOULD respond with a DAO-ACK" leaves the door open to
> > > not doing it. Unfortunately rfc6550 didn't explicitly mention what
> > > may be the reasons to not send a DAO-ACK (or not using MUST instead).
> > >
> > > In summary, there doesn't seem to be a guarantee that a DAO-ACK will
> > > be received...which means that the 6LN may be left waiting for a
> > > response to the registration (the same issues appears to be present
> > > for a re-registration).
> >
> > This is bad, and the practice is that implementations always respond
> > to the K. This is how we know that the route works in non-storing
> > mode. Happy to add that SHOULD->MUST to the list of thing this spec
> > updates if you think it is worthwhile.
> 
> I do...for whenever the time for rfc6550bis comes...no hurry, of course.
> 
> 

Ack

I created a RPLv2 repo in github and added this todo in the readme
https://github.com/roll-wg/RPLv2/blob/main/README.md



> 
> ...
> > > 1059 11. Protocol Operations for Multicast Addresses
> ...
> > > [major] One Multicast Address per DAO? I think I saw a related
> > > discussion on the list recently.
> >
> > The discussion was for multiple VIOs / TIOs. There can always be
> > multiple targets. But then, since this is triggered by a message for
> > one address, I expect that there will be one DAO at a time. Is there a need for
> a change?
> 
> The MLDv2 Report can include multiple addresses.  In any case, I guess the
> behavior is the same: if multiple addresses are in the Report, then the DAO can
> do the same.   I don't think we need a change.
> 

Ack

> 
> ...
> > > 1230 16. New Subregistry for the RPL Non-Rejection Status values
> ...
> > > 1242 +-------+------------------------+-----------+
> > > 1243 | Value | Meaning | Reference |
> > > 1244 +=======+========================+===========+
> > > 1245 | 0 | Unqualified acceptance | RFC 6550 |
> > > 1246 +-------+------------------------+-----------+
> > >
> > > [major] Let's also add this document as a reference for this initial
> > > allocation.
> > >
> >
> > Well it is really define in RFC 6550, just remapped here, but OK.
> 
> [] I meant "add" as in put both. :-)

Done : ) a double ref is a first time for me
> 
> 
> 
> ...
> > This is the deepest and probably the most useful single review I ever
> > has in almost 20 years of IETF!
> 
> :-)
>

: )   : )


> 
> 
> === Part 2: Comments on -22 ===
> 
> 
> ...
> 11	Abstract
> 
> 13	   This specification updates RFC6550, RFC6775, and RFC8505, to
> provide
> 14	   routing services to RPL Unaware Leaves that implement 6LoWPAN
> ND and
> 15	   the extensions therein.
> 
> [major] We usually want to see a short description of what the Update is, in
> both the Abstract and the Introduction.  I like the general statement made
> here, but I need you to add some more details in the Introduction.
> 
> Perhaps add something like this before the summary of the document's
> organization:
> 
>    This document updates rfc6550 by ... (Section x).
> 
>    This document updates rfc6775 by ... (Section y).
> 
>    This document updates rfc8505 by ... (Section z).
> 
> (Maybe a single paragraph can cover changes common to rfc6775/rfc8505.)
> 
> Yes, it's redundant information, but putting a summary upfront should answer
> questions later.

The reader is the customer : ) I made it high level and expect that Rahul agrees with changing the DCO status:

"
*  
     Section 6 presents the changes made to [RFC6550]; a new behavior
      is introduced whereby the 6LR advertises the 6LN's addresses in a
      RPL DAO message based on the ND registration by the 6LN, and the
      RPL root performs the EDAR/EDAC exchange with the 6LBR on behalf
      of the 6LR; modifications are introduced to some RPL options and
      to the RPL Status to facilitate the integration of the protocols.

   *  Section 7 presents the changes made to [EFFICIENT-NPDAO]; the use
      of the DCO message is extended to the Non-Storing MOP to report
      asynchronous issues from the Root to the 6LR.

   *  Section 8 presents the changes made to [RFC6775] and [RFC8505];
      The range of the ND status codes is reduced down to 64 values, and
      the remaining bits in the original status field are now reserved.
"


> 
> 
> 
> ...
> 489	5.1.  Support of 6LoWPAN ND
> ...
> 513	   [RFC8505] introduces error Status values in the NA(EARO) which can
> be
> 514	   received synchronously upon an NS(EARO) or asynchronously.  The
> RUL
> 515	   needs to support both cases and should refrain from using the
> address
> 516	   when the Status Value indicates a rejection (see Section 6.3).
> 
> [nit] s/support both cases and should refrain/support both cases and refrain
> 
> I believe that the rfc8505 text talks about MUST, so just trying to avoid
> confusion.
> 

Done

> 
> 
> ...
> 579	6.1.  Updated RPL Target Option
> ...
> 600	   The updated format is illustrated in Figure 3.  It is backward
> 601	   compatible with the Target Option in [RFC6550].  It SHOULD be used
> as
> 602	   a replacement in new implementations in all MOPs in preparation for
> 603	   upcoming Route Ownership Validation mechanisms based on the
> ROVR,
> 604	   unless the device or the network is so constrained that this is not
> 605	   feasible.
> 
> [major] "SHOULD be used as a replacement in new implementations in all
> MOPs in preparation for upcoming Route Ownership Validation
> mechanisms..."
> 
> Even with the qualification I am uncomfortable normatively recommending
> something for future use without explicitly mentioning what that is.  It just
> sounds speculative.  s/SHOULD/is recommended that the updated format
> 
> 

Done

> 
> 607	      0                   1                   2                   3
> 608	      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
> 609	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> [nit] The numbers are not aligned: you need an extra space.

Fixed

> 
> 
> ...
> 625	   ROVRsz (ROVR Size):  Indicates the Size of the ROVR.  It MAY be 1, 2,
> 626	      3, or 4, indicating a ROVR size of 64, 128, 192, or 256 bits,
> 627	      respectively.  A value if 0 thus denotes a legacy Target Option.
> 
> [major] s/MAY be 1, 2, 3, or 4/SHOULD be 1, 2, 3, or 4
> 
Done

> 
> [major] What should the receiver do if a different value is used?
> 
Added 
"
ROVRsz (ROVR Size):  Indicates the Size of the ROVR.  It SHOULD be 1,
      2, 3, or 4, indicating a ROVR size of 64, 128, 192, or 256 bits,
      respectively.  If a legacy Target Option is used, then the value
      must remain 0, as specified in [RFC6550]; In case of a value above
      4, the size of the ROVR is undetermined and this node cannot
      validate the ROVR; an implementation SHOULD propagate the whole
      Target Option upwards as received to enable the verification by an
      ancestor that would support the upgraded ROVR.
"
 
> [major] s/A value if 0 thus denotes a legacy Target Option./If a legacy Target
> Option is used, then the value must remain 0, as specified in rfc6500.

Done in the above

> The other way around, saying that 0 = legacy creates possible issues with
> ROVRsz = 0 and the F flag set because it clearly is not a legacy target option.

True, your way is preferable

> 
> 629	   F:  1-bit flag.  Set to indicate that Target Prefix field contains an
> 630	      address of prefix advertiser in full.
> 
> [minor] To be consistent with the text earlier in this section:
> s/contains an address of prefix advertiser in full./contains the complete (128
> bit) IPv6 address of the advertising node.
> 

Done

> 
> 
> ...
> 635	6.2.  New Flag in the RPL DODAG Configuration Option
> 
> [] Is this an Update to rfc6550?
> 
> 637	   The DODAG Configuration Option is defined in Section 6.7.6 of
> 638	   [RFC6550].  Its purpose is extended to distribute configuration
> 639	   information affecting the construction and maintenance of the
> DODAG,
> 640	   as well as operational parameters for RPL on the DODAG, through
> the
> 641	   DODAG.  As shown in Figure 4, the Option was originally designed
> with
> 642	   4 bit positions reserved for future use as Flags.
> 
> [nit] It is not extremely clear, by looking at Figure 4 where the reserved bits
> are.  I had to compare it with the figure in rfc6550 to make sure.

I changed 
<- Flags ->
With 
|4 bits |
In fig 4


> 
> s/As shown in Figure 4, the Option/This Option
> 
> 644	      0                   1                   2                   3
> 645	      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
> 646	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 647	     |   Type = 0x04 |Opt Length = 14| |P| | |A|       ...           |
> 648	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     +
> 649	                                     <- Flags ->
> 
> 651	            Figure 4: DODAG Configuration Option (Partial View)
> 
> 
> ...
> 663	   Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that the
> 664	   definition of the Flags applies to Mode of Operation (MOP) values
> 665	   zero (0) to six (6) only.  For a MOP value of 7, the Root is expected
> 666	   to perform the proxy operation by default.
> 
> [major] "is expected"  Does that mean MUST/SHOULD?
I'm not sure how we'll realize the function but it will have to look the same from the perspective of this implementation.
I suggest:
"
   For a MOP value of 7, the implementation MUST consider that the Root 
   performs the proxy operation.
"
> 
> 
> 668	   The RPL DODAG Configuration Option is typically placed in a DODAG
> 669	   Information Object (DIO) message.  The DIO message propagates
> down
> 670	   the DODAG to form and then maintain its structure.  The DODAG
> 671	   Configuration Option is copied unmodified from parents to children.
> 672	   [RFC6550] states that "Nodes other than the DODAG Root MUST
> NOT
> 673	   modify this information when propagating the DODAG Configuration
> 674	   option".  Therefore, a legacy parent propagates the T Flag as set by
> 675	   the Root, and when the T Flag is set, it is transparently flooded to
> 676	   all the nodes in the DODAG.
> 
> [minor] s/T Flag/'P' bit
> 

'P' Flag maybe? We seem to be calling these things flags, like the 'E' flag in useofrplinfo 
I changed in all occurances

> 
> 678	6.3.  Updated RPL Status
> ...
> 726	   When building a DCO or a DAO-ACK message upon an IPv6 ND NA or
> a EDAC
> 727	   message, the RPL Root MUST copy the 6LoWPAN ND Status Code
> unchanged
> 728	   in the RPL Status Value and set the 'A' flag.  The RPL Root MUST set
> 729	   the 'E' flag for all rejection and unknown Status Codes.  The Status
> 730	   Codes in range 1-10 [RFC8505] are all considered rejections.
> 
> [nit] s/in range 1-10/in the 1-10 range

Done

> 
> [major] What should a receiver do if the E flag is not set for Status Codes in
> that range?  It almost feels like this flag is mostly informational; IOW, if it's not
> set, and a node receives 1-10, it is still a rejection.  Maybe we don't have to
> specify anything...

This text deals with the encoding from ND to RPL. 

When encoding from RPL to ND, the E Flag is not used. It's just that if the 'A' flag is set then the value is copied else it is 0.

If a RPL node reads a status, 'E' will tell it's an error , and there's action on that. There are a lot of ND values that RPL does not understand or cares for, all it cares is error or not. 1-10 with a flag set do not exist today, they would be considered as not-an-error and the value ignored.

I do not think we need text but stand ready to be convinced otherwise.

> 
> 
> ...
> 737	7.  Enhancements to draft-ietf-roll-efficient-npdao
> 
> 739	   [EFFICIENT-NPDAO] defines the DCO message for RPL Storing Mode
> only,
> 740	   with a link-local scope.  All nodes in the RPL network are expected
> 741	   to support the specification since the message in processed hop by
> 742	   hop along the path this is being cleaned up.
> 
> [nit] s/message in processed/message is processed
> 

Done

> 
> ...
> 787	9.1.  General Flow
> ...
> 806	           6LN/RUL   <-ND->   6LR   <-RPL->  Root   <-ND->     6LBR
> 807	              |                |              |                   |
> 808	              |   NS(EARO)     |              |                   |
> 809	              |--------------->|                                  |
> 810	              |                |          Extended DAR            |
> 811	              |                |--------------------------------->|
> 812	              |                |                                  |
> 813	              |                |          Extended DAC            |
> 814	              |                |<---------------------------------|
> 
> [minor] Indicating the protocol at the top is nice.  ND is used between the 6LR
> and the 6LBR to start.
> 

Added

> ...
> 832	   ITo achieve this, the Path Sequence and the Path Lifetime in the DAO
> 833	   message are taken from the Transaction ID and the Address
> 834	   Registration lifetime in the NS(EARO) message from the 6LN.
> 
> [nit] s/ITo/To
> 

(Already) Done

> 
> ...
> 923	9.2.1.  Perspective of the 6LN Acting as RUL
> ...
> 942	   3.  As stated in section 5.2 of [RFC8505], the 6LN can register to
> 943	       more than one 6LR at the same time.  In that case, it uses the
> 944	       same EARO for all of the parallel Address Registrations, with the
> 945	       exception of the Registration Lifetime field and the setting of
> 946	       the R flag that may differ.  The 6LN SHOULD send the NS(EARO), if
> 947	       any, that maintain a registration active (i.e., with a non-zero
> 948	       Registration Lifetime) and ensure that one succeeds before it
> 949	       sends an NS(EARO) that terminates another registration, to avoid
> 950	       the churn related to transient route invalidation in the RPL
> 951	       network.
> 
> [minor] s/The 6LN SHOULD send...transient route invalidation in the RPL
> network./To avoid churn related to transient route invalidation, the 6LN
> SHOULD send the NS(EARO) to maintain the registration active (i.e., with a
> non-zero Registration Lifetime).
> 

This misses the point. Say the 6LN wants to send EAROs with lifetime 0 and others with lifetime non zero, to switch paths.
This says to send the non zero first and the reason behind is that the route invalidation doe to the lifetime 0 will stop at the common parent if that common parent already received the non-zero. Else the invalidation may reach the root, only to be reconstructed later over the new path, and packets may be lot.

Still I agree that this lack clarity. Suggestion:

"

   The 6LN may cancel a subset of its registrations, or transfer a
   registration from one or more old 6LR(s) to one or more new 6LR(s). To do
   so, the 6LN sends a series of NS(EARO) messages, all with the same TID,
   with a zero Registration Lifetime to the old 6LR(s) and
   with a non-zero Registration Lifetime to the new 6LR(s). In that process,
   the 6LN SHOULD send the NS(EARO) with a non-zero Registration Lifetime and
   ensure that at least one succeeds before it sends an NS(EARO) that
   terminates another registration. This avoids the churn related to transient
   route invalidation in the RPL network above the common parent of the
   involved 6LRs.
"

> 
> ...
> 984	9.2.2.  Perspective of the 6LR Acting as Border Router
> ...
> 1014	   If there is no suggested RPL Instance or else if the 6LR does not
> 1015	   participate to the suggested Instance, it is expected that the
> 1016	   packets coming from the 6LN "can unambiguously be associated to
> at
> 1017	   least one RPL Instance" [RFC6550] by the 6LR.
> 
> [major] Is the intent that this paragraph applies to both the RPL Instance in the
> EARO and in the RPI??  I ask because it says that the 6LR can ignore the
> Instance.  I have an issue with it because the text in rfc6550 says this (from §5:
> RPL Instance):
> 
>    The definition and provisioning of RPL Instances are out of scope for
>    this specification.  Guidelines may be application and implementation
>    specific, and they are expected to be elaborated in future companion
>    specifications.  Those operations are expected to be such that data
>    packets coming from the outside of the RPL network can unambiguously
>    be associated to at least one RPL Instance and be safely routed over
>    any instance that would match the packet.
> 
>    Control and data packets within RPL network are tagged to
>    unambiguously identify of which RPL Instance they are a part.
> 
> This second paragraph is specific in saying that if the RPL Instance is included in
> a control/data packet, then that is the unambiguous identifier.
> 

Yes, but this text covers a packet inside the RPL network. The issue we're dealing with here is for a packet coming from the outside (the RUL is outside). The 6LR typically adds the RPI. 

This text aims at saying that there must be an unspecified magic (e.g., a policy based on 6 tuples) that tells what the instance is.
The policy can be as simple as "put everything in instance 0". But we need one

Added at the end of the sentence
"
, e.g., using a policy that maps the 6-tuple into an Instance.
"


> 
> (1) If we're talking about the Instance in the EARO: This may be a stretch, but I
> can see the argument about ND not being a RPL control packet -- thus not
> covered by rfc6550.  I can of course see the other side too: signaling RPL
> information in a control packet makes the text applicable.  ??
> 
> 
> (2) OTOH, if we're talking about the Instance in the RPI, that is in conflict with
> rfc6550 (§11.2.2.1):
> 
>    If any node cannot forward a packet along the DODAG associated with
>    the RPLInstanceID, then the node SHOULD discard the packet and send
>    an ICMP error message.
> 

 he reason for the above text is to avoid loops by switching packets over topologies.
Here we are the at the border, defining the topology that the packet will follow. There is no risk of loop, and the RUL just "hints" the topology that should be used. I'd like to keep the text very abstract on how the 6LR assigns the RPI, but ultimately that's something the router decides, not the host.



> The text only recommends discarding -- is this case (RPI from a RUL) a valid
> reason to not discard?  If that is the case, then something still needs to be
> done about the RPI...maybe remove or modify it.  I looked at UseofRPLInfo but
> all the cases assume that the RUL doesn't attach the RPI.  Should that
> document cover the RUL sending an RPI?

Nothing prevents a packet coming in a RPL domain to carry an RPI. E.g., that packet escaped another RPL domain, which is now valid. The border router (typically the root) must rewrite it. the question is whether we assume that the RUL placed a meaningful one. I'd say that cannot be assumed in all cases, e.g., if instead of a leaf we have another RPKL network. 
But when it is useful, the 6LR should have a policy to know so it knows how to use it.

At the end of 

   So unless the RUL originates its packets with an RPI, the 6LR needs to tunnel
   them to the Root to add the RPI. As a rule of a thumb and except for the very
   special case above, the packets from and to a RUL are always encapsulated
   using an IP-in-IP tunnel between the Root and the 6LR that serves the RUL
   (see sections 7 and 8 of <xref target='I-D.ietf-roll-useofrplinfo'/> for details).

I added
"
   If the packet from the RUL has an RPI, the 6LR as a RPL border router
   MUST rewrite the RPI to indicate the selected Instance and set the flags,
   but it does not need to encapsulate the packet.
"

Also added

"
                                                         It is up to the 6LR (e.g., by policy) to use the
   RPLInstanceID information provided by the RUL or rewrite it to the selected
   RPLInstanceID for forwarding inside the RPL domain.
"
 Inside

   A RUL is not expected to produce RPL artifacts in the data packets, but it
   may do so. For instance, if the RUL has minimal awareness of the RPL
   Instance then it can build an RPI. A RUL that places an RPI in a data packet
   MUST indicate the RPLInstanceID of the RPL Instance where the
   packet should be forwarded. It is up to the 6LR (e.g., by policy) to use the
   RPLInstanceID information provided by the RUL or rewrite it to the selected
   RPLInstanceID for forwarding inside the RPL domain.
   All the flags and the Rank field are set
   to zero as specified by section 11.2 of [RFC 6550)
> 
> 
> 
> ...
> 1141	   The 6LR may at any time send a unicast asynchronous NA(EARO)
> with the
> 1142	   R Flag reset to signal that it stops providing routing services, and/
> 1143	   or with the EARO Status 2 "Neighbor Cache full" to signal that it
> 1144	   removes the NCE.  It may also send a final RA, unicast or multicast,
> 1145	   with a Router Lifetime field of zero, to signal that it stops serving
> 1146	   as Router, as specified in section 6.2.5 of [RFC4861].  This may
> 1147	   happen upon a DCO or a DAO-ACK message indicating the path is
> already
> 1148	   removed; else the 6LR SHOULD remove the Host route to the 6LN
> using a
> 1149	   DAO message with a Path Lifetime of zero.
> 
> [major] There are other places where the 6LR has to remove the route, but this
> is the only one with a SHOULD.  Why?  Is there a reason why removal is not
> required here?  Note that the text says "else...", so if we got to this point I
> would assume the the 6LR is required to remove the route.
> 
> 

The intention for the SHOULD was that the 6LR could leave the route as is and receive some packets for the 6LN, even though it pushed the 6LN away.  But that is flawed since the NCE is removed in the sentence above; made it a MUST.

> ...
> 1216	10.  Protocol Operations for Multicast Addresses
> 
> 1218	   Section 12 of [RFC6550] details the RPL support for multicast flows.
> 1219	   This support is not source-specific and only operates as an extension
> 1220	   to the Storing Mode of Operation for unicast packets.  Note that it
> 1221	   is the RPL model that the multicast packet is passed as a Layer-2
> 1222	   unicast to each of the interested children.  This remains true when
> 1223	   forwarding between the 6LR and the listener 6LN.
> 
> [major] Is this functionality mandatory or optional?  Should the 6LR have an
> option to not "translate" the MLD reports into DAOs?

This is selected by the use of a MOP. So I'd say, they MUST do it if and only if MOP is 3.

Changed the first paragraph to 
"

   Section 12 of [RFC6550] details the RPL support for multicast flows.
   This support is activated by the MOP of 3 "Storing Mode of Operation
   with multicast support" in the DIO messages that form the DODAG.
   This section also applies if and only if the MOP of the RPLInstance
   is 3.

"

> 
> [major] The description here provides the details that §12/rfc6550 didn't; do
> you expect this to be a formal Update to rfc6550, or just an extension for
> nodes supporting this specification?  Either way, at least point at this section
> from §6.
> 
> 

At the end of section 6, I added

"
   Section 12 of [RFC6550] details the RPL support for multicast flows
   when the RPLInstance is operated in the MOP of 3 ("Storing Mode of
   Operation with multicast support").  This specification extends the
   RPL Root operation to proxy-relay the MLDv2 [RFC3810] operation
   between the RUL and the 6LR, more in Section 10.
"

> 1225	   "Multicast Listener Discovery Version 2 (MLDv2) for IPv6" [RFC3810]
> 1226	   provide an interface for a listener to register to multicast flows.
> 1227	   In the MLD model, the Router is a "querier", and the Host is a
> 1228	   multicast listener that registers to the querier to obtain copies of
> 1229	   the particular flows it is interested in.
> 
> [nit] s/provide an interface/provides an interface
> 

Done

> ...
> 1252	   Upon a DAO with a Target option for a multicast address, the RPL
> Root
> 1253	   checks if it is already registered as a listener for that address,
> 1254	   and if not, it performs its own unsolicited Report for the multicast
> 1255	   address as sescribed in section 5.1 of [RFC3810].  The report is
> 1256	   source independent, so there is no Source Address listed.
> 
> [nit] s/sescribed/described

Done

> 
> [minor] MLDv2 includes source addresses in the Reports, but that can't be
> "translated" into RPL.  What are the downsides?  I'm thinking that a RUL can
> try to subscribe to a specific (S,G), but will get (*,G) instead; if the traffic level is
> too high then it could overwhelm the RUL, and even cause other issues in the
> rest of the LLN: potentially high link utilization, waste of energy, etc..   It may
> be nice to mention it.
> 
> 
> 
> 1258	      6LN/RUL                6LR             Root                   6LBR
> 1259	         |                    |               |                       |
> 1260	         | unsolicited Report |               |                       |
> 1261	         |------------------->|               |                       |
> 1262	         |     <L2 ack>       |               |                       |
> 
> [minor] Please remove the "<L2 ack>".
> 
> 
Done

> ...
> 1321	11.  Security Considerations
> ...
> 1368	   The Opaque field in the EARO enables the RUL to suggest a
> 1369	   RPLInstanceID where its traffic is placed.  This opens to attacks
> 1370	   where a RPL instance would be reserved for critical traffic, e.g.,
> 1371	   with a specific bandwidth reservation, that the additional traffic
> 1372	   generated by a rogue may disrupt.  This may be alleviated by
> 1373	   traditional access control mechanisms where the 6LR shapes the
> 1374	   incoming traffic from the 6LN.
> 
> [minor] "The Opaque field in the EARO enables..."  True, but it is worst than
> that: the RUL can also build an RPI with the RPL Instance in it.
> 
> And there's a combination: put one value in the Opaque field for "normal"
> traffic and use the RPI for other traffic.  This would make management of the
> system even harder when trying to trace where the traffic went: the 6LN
> expects to put the traffic in the RPL Instance indicated by the Opaque field, but
> the RPI says something else.  I imagine this is possible.
> 
> Traffic shaping may help reduce the impact (assuming a certain amount of
> traffic), but there may be actions the rogue node could take with a relatively
> low number of packets.  IOW, I don't think that shaping should be the only
> suggestion; we should include blocking as well.
> 

The changes above indicate that the 6LR is the ultimate decider of the instance to be used.
I added text including your suggestion above. What about;
"
    The Opaque field in the EARO enables the RUL to suggest a RPLInstanceID
    where its traffic is placed. It is also possible for an attacker RUL to
    include an RPI in the packet. This opens to attacks where a RPL instance
    would be reserved for critical traffic, e.g., with a specific bandwidth
    reservation, that the additional traffic generated by a rogue may disrupt.
    The attack may be alleviated by traditional access control and traffic
    shaping mechanisms where the 6LR controls the incoming traffic from the
    6LN. More importantly, the 6LR is the node that injects the traffic in the
    RPL domain, so it has the final word on which RPLInstance is to be used
    for the traffic coming from the RUL, per its own policy. "


> 1382	   [EFFICIENT-NPDAO] introduces the ability for a rogue common
> ancestor
> 1383	   node to invalidate a route on behalf of the target node.  In that
> 1384	   case, the RPL Status in the DCO has the 'A' flag not set, and a
> 1385	   NA(EARO) is returned to the 6LN with the R flag not set.  This
> 1386	   encourages the 6LN to try another 6LR.  If a 6LR exists that does not
> 1387	   use the rogue common ancestor, then the 6LN will eventually
> succeed
> 1388	   gaining reachability over the RPL network in spite of the rogue node.
> 
> [minor] s/In that case/In this case
> 

Done

> 1398	12.2.  Resizing the ARO Status values
> ...
> 1405	   IANA is requested modify the Address Registration Option Status
> 1406	   Values Registry so that the upper bound of the unassigned values is
> 1407	   63.  This document should be added as a reference.  The registration
> 1408	   procedure does not change.
> 
> [nit] s/requested modify/requested to modify
> 

Done

> 
> 1410	12.3.  New DODAG Configuration Option Flag
> 
> 1412	   This specification updates the Registry that was created for
> 1413	   [RFC6550] as the registry for "DODAG Configuration Option Flags"
> and
> 1414	   updated as the registry for "DODAG Configuration Option Flags for
> MOP
> 1415	   0..6" by [USEofRPLinfo], by allocating one new Flag as follows:
> 
> [major] NEW>
>    IANA is requested to assign a flag from the "DODAG Configuration Option
>    Flags for MOP 0..6" [USEofRPLinfo] registry as follows:
> 
> 

Done

> 
> ...
> 1425	12.4.  RPL Target Option Registry
> 
> 1427	   Section 20.15 of [RFC6550] creates a Registry for the 8-bit "RPL
> 1428	   Target Option Flags" field.  IANA is requested to reduce the size of
> 1429	   the field in the Registry to 4 bits.  Section 6.1 also defines a new
> 1430	   entry in the Registry as follows:
> 
> [major] NEW>
> 
>    This document modifies the "RPL Target Option Flags" registry initially
>    created in Section 20.15 of [RFC6550]. The registry now includes only 4-
>    bits (Section 6.1) and should point to this document as an additional
>    reference. The registration procedure doesn't change.
> 
>    Section 6.1 also defines a new entry in the Registry as follows:

Done;

I'm wondering if there again the end of your message was lost?

In any fashion, I'll push the update so far for your review.

Many thanks Alvaro!

Pascal