Thanks a bunch for your comments, very helpful!
Please see below:
From: Roll [mailto:roll-boun...@ietf.org] On Behalf Of Georgios Z. Papadopoulos
Sent: jeudi 22 février 2018 16:47
To: Routing Over Low power and Lossy networks <r...@ietf.org>
Subject: Re: [Roll] New Version Notification for
Please find my comments below.
*/ 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
*/ 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
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.
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
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.
*/ Upon reception of a DAO message that creates or updates an existing
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
*/ 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?
[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!
6tisch mailing list