[Roll] FW: Published draft-ietf-roll-unaware-leaves-17.txt

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

Hello Rahul:

Excellent comments! Many thanks 😊

> As per our discussion and your summary for the published -17 draft, we should be mandating the use of Updated Target Option. However, I don't see any clear text suggesting so in the draft. Am I missing something? The draft mentions the use of Updated Target Option only in response to the "P" flag. There are sections (for e.g., Section 10.2.2) which still refer to RPL Target Option and not the updated one. There is text (section 6) which still suggests that keep-alive EDAR/EDAC can be sent from 6LR.

The MUST I was discussing was to ensure that we do not need to define the anonymous flow (the EDAR from Root to 6LBR without a ROVR).
So the updated DAO is a MUST when the ‘P’ flag is set. Else the EDAR is from the 6LR so it is not anonymous anyway.

For the general case it is better to use the updated target option because it brings the capability to do more zerotrust protection; but you also mentioned at some point that there’s a cost in memory for the DAO state, in particular in storing mode, that all nodes may not be able to pay. So I made it a SHOULD page 14:
“

   The modified format is illustrated in Figure 4.  It is backward
   compatible with the Target Option in [RFC6550<https://tools.ietf.org/html/rfc6550>] and SHOULD be used as
   a replacement in new implementations even for Storing Mode operations
   in preparation for upcoming security mechanisms based in the ROVR.

“
Does that match your expectation?


1. Section 1: "either as a collection tree or with routing back." -> I don't understand what "routing back" means here.

That’s the DAO thingy.

Collection Tree is a generic name for a tree structure built for AMR-type operations, like our MOP 0. See in the art the CTP https://en.wikipedia.org/wiki/Collection_Tree_Protocol from which our MOP 0 takes inspiration.

The other MOPs enable routing back to the device, e.g., for AMI-type operations, and for the sake of history it is inspired by https://tools.ietf.org/html/draft-thubert-roll-fundamentals .

What about
“
   [RFC6550] provides unicast and multicast routing services to RPL-
   Aware nodes (RANs), either as a collection tree for outwards traffic
   only, or with routing back to the devices as well.


“

> 2. Section 10.2.2
>   a. Refers to RPL Target Option and not the Updated Target Option

Yes…
“
   If the "R" flag is set in the NS(EARO), the 6LR MUST inject the Host
   route in RPL, unless this is barred for other reasons, such as the
   saturation of the RPL parent.  The 6LR MUST use a RPL Non-Storing
   Mode signaling and the updated Target Option (see Section 9).

“

 >     b. ROVR field addition to the Updated Target Option must be specified in this section

Clearly missing, I’ll add it as well
“
   The DAO message advertising the Registered Address MUST be
   constructed as follows:

   1.  The Registered Address is signaled as Target Prefix in the
       updated Target Option in the DAO message; the Prefix Length is
       set to 128.  The ROVR field is copied unchanged from the EARO.

“
>      c. As per 8505 TID is optional. However the draft assumes that TID is always copied from the EARO to the Path Sequence of DAO

Also correct, I need to MUST it,  in 7.1.
“
7.1.  Support of 6LoWPAN ND

   In order to obtain routing services from a 6LR, a RUL MUST implement
   [RFC8505] and set the "R" and "T" flags in the EARO.

“
In 10.2.1
“
2.  Once it has formed an address, the 6LN (re)registers its address
       periodically, within the Lifetime of the previous Address
       Registration, as prescribed by [RFC6775], to refresh the NCE
       before the lifetime indicated in the EARO expires.  It MUST set
       the "T" flag and the TID is incremented each time and wraps in a
       lollipop fashion (see section 5.2.1 of [RFC8505] which is fully
       compatible with section 7.2 of [RFC6550]).

“

> 3. Section 9. Should we mention that the Option Length MUST be >= 18 if the "F" flag is set?

Does that really help? He definition in RFC 6550 is still exactly correct…

> Nits:

Applied

I posted 18 so you can see the diffs;  please let me know if that works for you.

Also: I’ll need you to update the shepherd report indicating that you carried a sequence of reviews and that the new version concludes that series.

Take care,

Pascal

From: Roll <[e-mail]<mailto:[e-mail]>> On Behalf Of Rahul Jadhav
Sent: vendredi 12 juin 2020 10:47
To: Routing Over Low power and Lossy networks <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Roll] Published draft-ietf-roll-unaware-leaves-17.txt

Thanks Pascal for the updates,

As per our discussion and your summary for the published -17 draft, we should be mandating the use of Updated Target Option. However, I don't see any clear text suggesting so in the draft. Am I missing something? The draft mentions the use of Updated Target Option only in response to the "P" flag. There are sections (for e.g., Section 10.2.2) which still refer to RPL Target Option and not the updated one. There is text (section 6) which still suggests that keep-alive EDAR/EDAC can be sent from 6LR.

Other comments:
1. Section 1: "either as a collection tree or with routing back." -> I don't understand what "routing back" means here.
2. Section 10.2.2
      a. Refers to RPL Target Option and not the Updated Target Option
      b. ROVR field addition to the Updated Target Option must be specified in this section
      c. As per 8505 TID is optional. However the draft assumes that TID is always copied from the EARO to the Path Sequence of DAO.
3. Section 9. Should we mention that the Option Length MUST be >= 18 if the "F" flag is set?



Nits:
* "Direction-Oriented Directed Acyclic Graphs" ->  It should be Destination-Oriented
* an RAN injects -> a RAN injects
* "even when the DODAG is operated in Storing Mode DODAGs" -> remove DODAGs.
* "such a Ethernet" -> "such as Ethernet"
* "Sollicitation" -> "Solicitation" ... multiple places
* "set to 0 a prescribed by" -> "set to 0 as prescribed by"
* "For the refreshes of the registration, .." -> "For registration refresh, .."
* "if the "I" field" -> "If the "I" field"
* "A RPL Root SHOULD set the "P" flag in the RPL configuration option" -> "A RPL Root SHOULD set the "P" flag in the RPL DODAG Configuration Option"

Best,
Rahul


On Wed, 10 Jun 2020 at 23:53, Pascal Thubert (pthubert) <pthubert=[e-mail]<mailto:[e-mail]>> wrote:
Dear chairs:

This publication attempts to resolve the issues recently raised in the threads with Rahul.

The major changes are that :
- the support of the updated target option is now a MUST; this simplifies considerably the spec and removes the "anonymous" EDAR.
- setting the 'K' flag in the DAO asking for DAO-ACK is now a MUST as well; this avoids weird error paths and ensures that the route is installed.

Minors:
- require padding the prefix to the next byte in the Target Option
- a new bit to place the full address of the advertiser in the prefix in the Target Option

Then, editorials, suppression of duplicate text.

Please let me know how to proceed from there (WGLC? Update Shepherd statement?)

Take care,

Pascal



> -----Original Message-----
> From: Roll <[e-mail]<mailto:[e-mail]>> On Behalf Of [e-mail]<mailto:[e-mail]>
> Sent: mercredi 10 juin 2020 17:43
> To: [e-mail]<mailto:[e-mail]>
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: [Roll] I-D Action: draft-ietf-roll-unaware-leaves-17.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Routing Over Low power and Lossy networks
> WG of the IETF.
>
>         Title           : Routing for RPL Leaves
>         Authors         : Pascal Thubert
>                           Michael C. Richardson
>       Filename        : draft-ietf-roll-unaware-leaves-17.txt
>       Pages           : 32
>       Date            : 2020-06-10
>
> Abstract:
>    This specification extends RFC6550 and RFC8505 to provide routing
>    services to Hosts called RPL Unaware Leaves that implement 6LoWPAN ND
>    but do not participate to RPL.  This specification also enables the
>    RPL Root to proxy the 6LoWPAN keep-alive flows in its DODAG.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-17
> https://datatracker.ietf..org/doc/html/draft-ietf-roll-unaware-leaves-17<https://datatracker.ietf.org/doc/html/draft-ietf-roll-unaware-leaves-17>
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-17
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> Roll mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/roll