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

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

Hello Georgios

Thanks a bunch for your comments, very helpful!

Please see below:

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

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

*/   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
[PT>] Done.

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

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

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



[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:
*/ 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



[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:
*/ 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

[PT>] Done.

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


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


[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