Subject: [Iot-directorate] Iotdir telechat review of draft-ietf-roll-useofrplinfo-40

From: Mališa Vučinić via Datatracker <[email-masked]>
Date: Wed, 29 Jul 2020 06:22:40 -0700

Reviewer: Mališa Vučinić
Review result: Ready with Issues

As part of the IoT-Directorate review process, I went through
draft-ietf-roll-useofrplinfo-40. In general, I believe the document is ready to
proceed once a couple of issues that I outline below are resolved.

I have concerns whether the use of the normative language is appropriate in the
use cases section. I believe all such cases are covered either in the sections
updating RFC 6553, RFC 6550 and RFC 8138 or in these respective RFCs. Please
consider using lowercase keywords in Section 6.

As a minor note, there also appears to be an inconsistent use of the IP6-IP6
acronym. Please use a single acronym throughout the doc, currently a mix of
IPv6-in-IPv6 and IP6-IP6 is present.

My detailed comments are given below.

Section 1:

> Since some of the uses cases here described, use IPv6-in-IPv6 encapsulation. 
It MUST take in consideration, when encapsulation is applied, the RFC6040
[RFC6040], which defines how the explicit congestion notification (ECN) field
of the IP header should be constructed on entry to and exit from any
IPV6-in-IPV6 tunnel. - Please clarify the sentence. Consider whether it is
appropriate to have a normative MUST here.

Section 4.2:
> The non-storing mode case does not require the type change from 0x63 to 0x23,
as the root can always create the right packet.  The type change does not
adversely affect the non-storing case. - It is not clear what RPI option type
should non-storing networks use. A pointer to the discussion in Section 4.3
would be useful.

Section 4.4:

> A node that is decompressing this header MUST decompress using the RPI Option
Type that is currently active: that is, a choice between 0x23 (new) and 0x63
(old). The node will know which to use based upon the presence of the flag in
the DODAG Configuration option defined in Section 4.3. E.g.  If the network is
in 0x23 mode (by DIO option), then it should be decompressed to 0x23. - If my
understanding is correct, this means that in order to decompress data plane
packets, a node first needs to remember the option type mode the network is
operating in, advertised in DIOs. Consequently, decompression is not possible
before at least one DIO is received.

Section 6:

> The RPI MUST be present in every single RPL data packet.
- How is the normative text here appropriate at this point? Is this not
redundant with RFC6553?

>  This document assumes that the LLN is using the no-drop RPI Option Type
(0x23). - This statement appears twice in the document and is as such
redundant. please remove one appearance.

Section 8:

> The root always have to encapuslate on the way down
- It is not clear how come does root need to always encapsulate on the way
down. In the basic case of root to RAL communication, IPv6-in-IPv6 is marked as
“No”. Please clarify.

Section 8.1.3:

> When the RPI is added, the RUL, which does not understand the RPI, will
ignore it (per [RFC8200]); thus, encapsulation is not necessary. - Figure 22
states that for root to RUL communication IPv6-in-IPv6 encapsulation is
mandatory which is not consistent with this text.

Section 8.2.1:

- A sentence stating how does RAL recognize that the packet is destined for the
Internet would be useful.

Section 8.2.3:

> As RPL headers are added in the RUL packet, the first 6LR (6LR_1) will add an
RPI inside a new IPv6-in-IPv6 header. - this statement makes it sound as if RUL
originates a packet with RPL headers. Please rephrase.

Nits:
> The ROLL WG analysized how [RFC2460] rules apply to storing and non-storing
use of RPL. - s/analysized/analyzed

> that transports that abstract information in an IPv6 Hob-by-Hop Header.
- s/hob/hop

> consumed Routing Header and to ignore a HbH header as prescribed by
- define HbH, assuming Hop-by-Hop

> The root does not removes the RPI1
- s/removes/remove

> The 6LR_ia (ia=1) (Node E)
- s/6LR_ia (ia=1)/6LR_1

> The root always have to encapuslate on the way down
- s/have to encapuslate/has to encapsulate

>  If the originating node does not not
- s/does not not/does not

> and add it's own
- s/it’s/its

> The migration procedure it is triggered when the DIO is sent with the flag
indicating the new RPI Option Type. - s/it is/is

> Namely, it remains at 0x63 until it is sure that the network is capable of
0x23, then it abruptly change to 0x23. - s/change/changes

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 30 Jul 2020 09:07:31 +0000

Hello Mališa

Many thanks for your review!

I'm not the editor but I'd like to refine some points here

> [RFC6040], which defines how the explicit congestion notification (ECN) field of
> the IP header should be constructed on entry to and exit from any

That's a good point, but then all the best practice of encaps also applies, not sure we need/want to list them all. 
I'm afraid that if we start listing some we miss others and get in an endless discussion at IESG, e.g., fragmentation.

The reverse angle could be the MTU discussion. 
If we use RFC 8138 then the IP in IP does not really steal from the 6LoWPAN MTU of 1280. 
If not it does. So on paper the IP in IP encapsulator should fragment at the IP layer. This might happen in particular in non-storing mode with a routing header that causes a larger encapsulation.
But as it goes, even though the MTU is 1280, the fragmentation allows more (2048 with RFC 4944, no explicit limit with https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-21).

So it could be good to add text that says:
- best practice IPv6 encapsulation applies
	- mention RFC6040
- there are exception
	- no IP layer MTU discovery (because MTU is 1280)
	- though MTU is 1280, no IP layer fragmentation when the encapsulated packet is over that (because fragmentation copes with it above 1280)
	- The recomposition buffer SHOULD be large enough. We could RECOMMEND 2048 bytes.

> should non-storing networks use. A pointer to the discussion in Section 4.3

Note that adding/removing an RPI on the way (e.g., at the root) always involves en/decapsulations (ask 6MAN!). 
I'm not clear what difference you make there?

The problem is for packets from the LLN node to the internet. This is the same for storing and non-storing.
0x23 allows us to not remove The RPI thus to not encapsulate at the LLN node. Maybe that can be clarified.

We deprecate 0x63 globally and want it replaced by 0x23 in all cases. Maybe that can be clarified too. 

> before at least one DIO is received.
 
True. At that point the node does not even know it is in a RPL network. 
Note that the decompression generally happens at the destination of the outer header which removes the RPI if it is a router and ignores it if it is the final destination. So it does not really matter.
But just in case we can mention that the default is 0x23.

> - How is the normative text here appropriate at this point? Is this not

Agreed to lowercase it, and as you point out all the uppercase which echo an existing RFC

> down. In the basic case of root to RAL communication, IPv6-in-IPv6 is marked
> as “No”. Please clarify.

Need to clarify that this is for routed traffic not self-generated traffic

> Internet would be useful.

Note that that it does not need to. With this spec, the RAL may do the same thing whether the destination is a RAL, a RUL, or the Internet.
But yes I agree; we could say that if the RAL knows what the RPL domain is, it may encapsulate to the root when the destination is not in that domain.

Many thanks again!

Take care

Pascal