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

From: [email-masked]
Date: Fri, 13 Dec 2019 08:02:04 -0800

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

Abstract:
   This document looks at different data flows through LLN (Low-Power
   and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power
   and Lossy Networks) is used to establish routing.  The document
   enumerates the cases where RFC6553 (RPI Option Type), RFC6554
   (Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is
   required in data plane.  This analysis provides the basis on which to
   design efficient compression of these headers.  This document updates
   RFC6553 adding a change to the RPI Option Type.  Additionally, this
   document updates RFC6550 defining a flag in the DIO Configuration
   Option to indicate about this change and updates RFC8138 as well to
   consider the new Option Type when the RPL Option is decompressed.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-33
https://datatracker.ietf.org/doc/html/draft-ietf-roll-useofrplinfo-33

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-33

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 19 Dec 2019 15:44:29 -0500

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, [email-masked]
([email-masked](mailto:[email-masked])) wrote:

> Date : 2019-12-13(http://airmail.calendar/2019-12-13%2012:00:00%20EST)

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 19 Dec 2019 21:14:48 +0000

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 <[email-masked]> a écrit :
> 
> Dear authors:
>

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 23 Dec 2019 07:59:20 -0800

On December 19, 2019 at 4:14:52 PM, Pascal Thubert wrote:

Pascal:

Hi!

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

Yes, of course.  That is also in fact what you wrote in the text.

It is now clear to me -- no further changes needed for that part. :-)

Thanks!

Alvaro.