Subject: [6tisch] Fwd: New Version Notification for draft-thubert-roll-unaware-leaves-02.txt

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 21 Feb 2018 09:24:34 +0000

Dear all

This is a short draft, but the work is much needed to complete the RPL story on non-RPL-aware leaves. The draft conforms to the long-standing expectations from the 6TiSCH architecture.

Please have a read and provide feedback if possible before cutoff. This will allow me to publish an update, so we can discuss adoption in London.

Regards,

Pascal

Début du message transféré :

Expéditeur: <[email-masked]<mailto:[email-masked]>>
Date: 21 février 2018 à 10:20:03 UTC+1
Destinataire: Pascal Thubert <[email-masked]<mailto:[email-masked]>>
Objet: New Version Notification for draft-thubert-roll-unaware-leaves-02.txt

A new version of I-D, draft-thubert-roll-unaware-leaves-02.txt
has been successfully submitted by Pascal Thubert and posted to the
IETF repository.

Name:        draft-thubert-roll-unaware-leaves
Revision:    02
Title:        Routing for RPL Leaves
Document date:    2018-02-21
Group:        Individual Submission
Pages:        12
URL:            https://www.ietf.org/internet-drafts/draft-thubert-roll-unaware-leaves-02.txt
Status:         https://datatracker.ietf.org/doc/draft-thubert-roll-unaware-leaves/
Htmlized:       https://tools.ietf.org/html/draft-thubert-roll-unaware-leaves-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-thubert-roll-unaware-leaves-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-thubert-roll-unaware-leaves-02

Abstract:
  This specification updates RFC 6550 and RFC 6775 unicast routing
  service in a RPL domain to 6LoWPAN ND nodes that do not participate
  to the routing protocol.

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

The IETF Secretariat

---

From: Michael Richardson <[email-masked]>
Date: Wed, 21 Feb 2018 17:55:55 -0500

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > This is a short draft, but the work is much needed to complete the RPL
    > story on non-RPL-aware leaves. The draft conforms to the long-standing
    > expectations from the 6TiSCH architecture.

1) can you add a reference for "Routing Stretch"?
2) Alternatively, the 6LN may rely on its 6LR to perform routing and
   forwarding on its behalf.  In the context of RPL, such a 6LN is

   -> if you want to give an example of such a node, I think that the window
      smash sensor (alarm system), or the kinetically powered light switch,
      are two good examples.
   {I wish I had links to real products that actually ran RPL.}

section 3:
s/      Upon the renewal of a registration, this specification changes the
        behavior or the 6LR.
 /      Upon the renewal of a 6lowPAN ND registration, this specification changes the
        behavior of the 6LR. /

The rest of that paragraph is ver hard to parse.

section 4:
should:
   This document specifies a new flag in the EARO option, the 'R' flag,
   used by the registering node to indicate that the 6LN that performs
   the registration is a router and that it handles its reachability.

say:
   This document specifies a new flag in the EARO option, the 'R' flag,
   used by a 6LN, when registering, to indicate that this 6LN
   is a router and that it will handles its own reachability.

   (...By sending a DAO)

The rest of the document has some difficult sentences too.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Georgios Z. Papadopoulos" <[email-masked]>
Date: Thu, 22 Feb 2018 16:47:13 +0100

Hello Pascal,

Please find my comments below.

Georgios

Section 1:
*/ RPL also leverages Routing Stretch to reduce further the amount of control
traffic and routing state that is required to operate the protocol.

GP> The concept of Routing Stretch is not clear to me.
*/ RPL can only provide a best effort ratability, 
   connecting most of the LLN nodes, most of the time.  
GP> Rephrase this part of the sentence

*/   When a routing protocol such as RPL is used to maintain reachability
   within a Non-Broadcast Multi-Access (NBMA) subnet, Some nodes may act
   as routers and participate to the routing operations whereas others
   may be plain hosts.  
GP> Typo: subnet, Some —> subnet, some
*/ With this specification, a 6LN may declare itself as a router in the
   6LoWPAN ND exchange in order to declare that it will manage it own
   routing.
GP> The end of the sentence may need a rephrase.

Section 6.3:
   Also as prescribed by [I-D.ietf-6lo-rfc6775-update], the 6LR
   generates a DAR/DAC message upon reception of a valid NS(EARO)
   message for a new registration.  If the exchange succeeds, then the
   6LR installs a Neighbor Cache Entry (NCE).

*/ At this stage, and upon each NS(EARO) received afterwards that
   maintain the NCE in the 6LR; 
GP> I find this sentence as repetition with the previous paragraph.

Section 6.4:
*/ Upon reception of a DAO message that creates or updates an existing
   RPL state, 
GP> maybe indicate, from whom potentially the Root receives a DAO message

Section 6.5:
*/ Upon reception of a DAR message with the Owner Unique ID field is set
   to all ones, the 6LBR checks whether and entry exists for the and
   computes whether the TID in the DAR message is fresher than that in
   the entry as prescribed in [I-D.ietf-6lo-rfc6775-update].
GP> typo: and entry —> an entry
*/   If the entry exists but is not fresher, the 6LBR does not update the
   entry, and answers with a Status "Success" in the DAC message.

   If te entry exists and the TID in the DAR message is fresher, the
   6LBR updates the TID in the entry, and if the lifetime of the entry
   is extended by the Registration Lifetime in the DAR message, it also
   updates the lifetime of the entry.  In that case, the 6LBR replies
   with a Status "Success" in the DAC message.

GP> You could replace the “fresher” with recent?

> On Feb 21, 2018, at 10:24, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Dear all
> 
>> Expéditeur: <[email-masked] <mailto:[email-masked]>>
>> Destinataire: Pascal Thubert <[email-masked] <mailto:[email-masked]>>
>> URL:            https://www.ietf.org/internet-drafts/draft-thubert-roll-unaware-leaves-02.txt <https://www.ietf.org/internet-drafts/draft-thubert-roll-unaware-leaves-02.txt>
>> Status:         https://datatracker.ietf.org/doc/draft-thubert-roll-unaware-leaves/ <https://datatracker.ietf.org/doc/draft-thubert-roll-unaware-leaves/>
>> Htmlized:       https://tools.ietf.org/html/draft-thubert-roll-unaware-leaves-02 <https://tools.ietf.org/html/draft-thubert-roll-unaware-leaves-02>
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-thubert-roll-unaware-leaves-02 <https://datatracker.ietf.org/doc/html/draft-thubert-roll-unaware-leaves-02>
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-thubert-roll-unaware-leaves-02 <https://www.ietf.org/rfcdiff?url2=draft-thubert-roll-unaware-leaves-02>
>> 
>> Abstract:
>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>> 
>> The IETF Secretariat
>> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 23 Feb 2018 12:19:16 +0000

Hello Michael

> 1) can you add a reference for "Routing Stretch"?
[PT>] done, pointing on RFC 6687

>    {I wish I had links to real products that actually ran RPL.}

[PT>] done

> The rest of that paragraph is ver hard to parse.
[PT>] reworded as follows:
"
   Upon the renewal of a 6lowPAN ND registration, this specification
   changes the behavior of the 6LR as follows.
   If the 'R' flag is set, the 6LR injects a DAO targeting the Registered
   Address, and refrains from sending a DAR message. 
   the DAR/DAC exchange that refreshes the state in the 6LBR happens instead 
   between the RPL Root and the 6LBR. In that flow, the RPL Root acts as a
   proxy on behalf of the 6LR upon the reception of the DAO propagation
   initiated at the 6LR.
"

>    is a router and that it will handles its own reachability.
[PT>] Moved to the RFC 6775 update draft and updated as follows
"
   This document makes use of the 'R' flag in the EARO option, used by
   a 6LN, when registering, to indicate that this 6LN is a leaf, not aware of
   the RPL operation in the network, and thus does not participate to it.
   The behavior defined in this specification whereby the 6LR that processes the
   registration advertises the Registered Address in DAO messages and bypasses
   the DAR/DAC process for the renewal of a registration, is  only triggered by
   an NS(EARO) that has the 'R' flag set. A RPL leaf SHOULD set the 'R' flag.
   
   If the 'R' flag is not set, then the Registering Node is expected to be a RPL
   router that handles the reachability of the Registered Address by itself.
   This document also specifies a keep-alive EDAR message that the RPL Root may
   use to maintain an existing state in the 6LBR upon receiving DAO messages. 
   The EDAR message may only act as a refresher and can only update the Lifetime
   and the TID of the state in the 6LBR.  A RPL router SHOULD NOT set the 'R' flag.
"

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 23 Feb 2018 13:45:16 +0000

Hello Georgios

Thanks a bunch for your comments, very helpful!

Please see below:

From: Roll [mailto:[email-masked]] On Behalf Of Georgios Z. Papadopoulos
Sent: jeudi 22 février 2018 16:47
To: Routing Over Low power and Lossy networks <[email-masked]>
Cc: [email-masked]
Subject: Re: [Roll] New Version Notification for draft-thubert-roll-unaware-leaves-02.txt

Hello Pascal,

Georgios

Section 1:

GP> The concept of Routing Stretch is not clear to me.
[PT>] I added a pointer to RFC 6687, there’s a lot of information in there. Also adding a sentence.
The text now reads
“
   RPL is a Distance-Vector protocol, which, compared to link-state protocols,
   limits the amount of topological knowledge that needs to be installed and 
   maintained in each node. In order to operate in constrained networks,
   RPL allows a Routing Stretch (see <xref target="RFC6687"/>), whereby routing
   is only performed along a DODAG as opposed to straight along a shortest path
   between 2 peers, whatever that would mean in a given LLN.
   This trades the quality of peer-to-peer (P2P) paths for a vastly reduced
   amount of control traffic and routing state that would be required to
    operate a any-to-any shortest path protocol. “

***************

*/ RPL can only provide a best effort ratability, 
   connecting most of the LLN nodes, most of the time.  
GP> Rephrase this part of the sentence
[PT>] Done. The text now reads
“
   
   RPL is designed to adapt to fuzzy connectivity, whereby the physical topology
   cannot be expected to reach a stable state, with a lazy control that creates
   routes proactively but only fixes them when they are used by actual traffic.
   It results that RPL provides reachability for most of the LLN nodes, most of
   the time, but does not really converge in the classical sense.
"

[PT>] Done.

********************

[PT>] Changed to:

"
   With this specification, a 6LN that operates as a Leaf uses the 'R' flag 
   to declare itself as such and the 6LR that accepts the registration will
   inject routing information on behalf of the 6LN in the RPL domain.
"

********************

Section 6.3:

[PT>] Reworded; the point is that there is the first registration with a DAR DAC exchange and then the others without it

"
   Also as prescribed by <xref target="I-D.ietf-6lo-rfc6775-update"/>,
   the 6LR generates a DAR message upon reception of a valid NS(EARO)
   message for the registration of a new IPv6 Address by a 6LN. If the Duplicate
   Address exchange succeeds, then the 6LR installs a Neighbor Cache Entry (NCE).
   If the 'R' flag was set in the EARO of the NS message, and this 6LR can
   manage the reachability of Registered Address, then the 6LR sets the 'R' flag
   in the ARO of the response NA message.  
   From then on, the 6LN periodically sends a new NS(EARO) to refresh the NCE
   state before the lifetime indicated in the EARO expires, with TID that is
   incremented each time till it wraps in a lollipop fashion. As long as the 'R'
   flag is set and this router can still manage the reachability of Registered
   Address, the 6LR keeps setting the 'R' flag in the ARO of the response NA
   message, but the exchange of Duplicate Address messages is skipped.
  
   Upon a successful NS/NA(EARO) exchange: if the 'R' flag was set in the 
   EARO of the NS message, then the 6LR SHOULD inject the Registered Address in
   RPL by sending a DAO message on behalf of the 6LN; else the 6LR SHOULD
   refrain from injecting the registered address into RPL.    
 "

********************

Section 6.4:

[PT>] Added before:
"
   In RPL Storing Mode of Operation (MOP), the DAO message is propagated from
   child to parent all the way to the Root along the DODAG, populating routing
   state as it goes. In Non-Storing Mode, The DAO message is sent directly to the
   route.
"

********************

Section 6.5:

[PT>] Done.

********************

[PT>] Actually "Fresh" is defined in RPL and repeated in section 4.2.1.  "Comparing TID values" of RFC 6775 update.
I added a pointer to that.

Thanks again for all!

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Fri, 23 Feb 2018 13:55:53 -0500

> and the TID of the state in the 6LBR.  A RPL router SHOULD NOT set the 'R' flag.

Can we also say that a 6LR, upon seeing a ND *without* the EARO option,
should assume it's like the R flag is set?  Or is such a node just
non-operable?  (Clearly, such a node can't move from DODAG to DODAG...)

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 26 Feb 2018 17:09:58 +0000

That's true too Michael, but it is not ours pec, just the normal ND over transit links.
Cheers,
Pascal

> -----Original Message-----
> From: Michael Richardson [mailto:[email-masked]]
> Sent: vendredi 23 février 2018 19:56
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: Routing Over Low power and Lossy networks <[email-masked]>;
> [email-masked]
> Subject: Re: [6tisch] [Roll] Fwd: New Version Notification for draft-thubert-
> roll-unaware-leaves-02.txt
> 
> 
> should assume it's like the R flag is set?  Or is such a node just non-operable?
> (Clearly, such a node can't move from DODAG to DODAG...)
> 
> --

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 26 Feb 2018 18:04:02 +0000

Hello Michael:

I published 03 addressing what I could  :)

Pascal

> From: 6tisch [mailto:[email-masked]] On Behalf Of Michael
> Richardson
> Sent: mercredi 21 février 2018 23:56