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

[Alvaro Retana <[e-mail]>]

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)