Re: [Roll] I-D Action: draft-ietf-roll-useofrplinfo-33.txt

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

Hello Alvaro

Per RFC 8200, an IPv6 host the has no specific code for rfc 6550 should still process a packet with RPL artifacts since the RH is consumed and a host ignores the HbH headers.

I suggest we define supporting RPLv1 by implementing all or a portion of RFC 6550. A RUL has zero support of it.

Does that work?

Pascal

> Le 19 déc. 2019 à 21:44, Alvaro Retana <[e-mail]> a écrit :
> 
> Dear authors:
> 
> I reviewed this latest version, focusing on the changes since -31.  I
> have a couple of comments (see in-line below) which I think should be
> easy to solve -- hopefully all we need is a clarification.
> 
> I did notice that you didn't address the RFC Editor's questions sent
> by Lynn on Sep/3.  Let me know if you don't have her message and I can
> forward it to you.  As a reminder, the RFC Editor had finished editing
> the document then we pulled it from their queue, so it seems fair to
> address their questions in the document (and send them a reply when we
> hand it back).
> 
> Thanks!
> 
> Alvaro.
> 
> [Line numbers from idnits.]
> 
> 186    2.  Terminology and Requirements Language
> ...
> 197       RPL Leaf: An IPv6 host that is attached to a RPL router and obtains
> 198       connectivity through a RPL Destination Oriented Directed Acyclic
> 199       Graph (DODAG).  As an IPv6 node, a RPL Leaf is expected to ignore a
> 200       consumed Routing Header and as an IPv6 host, it is expected to ignore
> 201       a Hop-by-Hop header.  It results that a RPL Leaf can correctly
> 202       receive a packet with RPL artifacts.  On the other hand, a RPL Leaf
> 203       is not expected to generate RPL artifacts or to support IP-in-IP
> 204       encapsulation.  For simplification, this document uses the standalone
> 205       term leaf to mean a RPL leaf.
> ...
> 212       RPL-aware-node (RAN): A device which implements RPL.  Please note
> 213       that the device can be found inside the LLN or outside LLN.
> 
> 215       RPL-Aware-Leaf(RAL): A RPL-aware-node that is also a RPL Leaf.
> 
> 217       RPL-unaware-node: A device which does not implement RPL, thus the
> 218       device is not-RPL-aware.  Please note that the device can be found
> 219       inside the LLN.
> 
> 221       RPL-Unaware-Leaf(RUL): A RPL-unaware-node that is also a RPL Leaf.
> 
> I think there is a conflict in the new/updated definitions: what does
> it mean to "implement RPL"?
> 
> A "RPL Leaf can correctly receive a packet with RPL artifacts", which
> I assume it means that it implements RPL, at least enough to
> understand the artifacts even if it doesn't generate them.   OTOH, a
> RPL-unaware-node "does not implement RPL".  But then a RUL is "a
> RPL-unaware-node that is also a RPL Leaf".  This last definition
> sounds contradictory to me because the RPL Lead has to implement
> enough of RPL to understand, but being unaware....
> 
> 
> ...
> 303    4.1.  Updates to RFC6550: Advertising External Routes with Non-Storing
> 304          Mode Signaling.
> ...
> 347       A node that is reachable over an external route is not expected to
> 348       support [RFC8138].  Whether a decapsulation took place or not and
> 349       even when the 6LR is delivering the packet to a RUL, the 6LR that
> 350       injected an external route MUST uncompress the packet before
> 351       forwarding over that external route.
> 
> If the packet is not decapsulated, how can it be uncompressed?
> 
> 
> 
> ...
> 672    6.  Use cases
> ...
> 800          - In the uses cases, we assume that the RAL supports IP-in-IP
> 801          encapsulation.
> 
> 803          - In the uses cases, we dont assume that the RUL supports IP-in-IP
> 804          encapsulation.
> 
> Please reword these two assumptions to avoid the use of "we".
> 
> 
> 
>> On December 13, 2019 at 11:02:18 AM, [e-mail]
>> ([e-mail](mailto:[e-mail])) wrote:
>> 
>> 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 : Using RPI Option Type, Routing Header for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data Plane
>> Authors : Maria Ines Robles
>> Michael C. Richardson
>> Pascal Thubert
>> Filename : draft-ietf-roll-useofrplinfo-33.txt
>> Pages : 56
>> Date : 2019-12-13(http://airmail.calendar/2019-12-13%2012:00:00%20EST)