Subject: Re: [Last-Call] Iotdir telechat review of draft-ietf-roll-useofrplinfo-40

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 4 Sep 2020 12:54:50 +0000

Hello Malisa

I rechecked RFC 6553. It is contradicting itself somehow. Section 2 has a lowercase must for the RPI. 
Later RFC 6553 says “  Datagrams sent between RPL routers MUST include a RPL Option or RPL Source Route Header ([RFC6554]) and MAY include both.“ RFC 8138 requires the RPI at all times for compression. Now we MUST the RPI in all cases, it appears simpler to be able to count on it to apply QoS.

Take care,

Pascal

> -----Original Message-----
> From: Roll <[email-masked]> On Behalf Of Pascal Thubert (pthubert)
> Sent: jeudi 30 juillet 2020 11:08
> To: Mališa Vučinić <[email-masked]>; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Roll] Iotdir telechat review of draft-ietf-roll-useofrplinfo-40
> 
> Hello Mališa
> 
> Many thanks for your review!
> 
> I'm not the editor but I'd like to refine some points here
> 
> >
> > 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.
> 
> 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.
> 
> 
> > 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.
> >
> 
> 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.
> 
> 
> > 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.
> 
> 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.
> 
> 
> > 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?
> 
> Agreed to lowercase it, and as you point out all the uppercase which echo an
> existing RFC
> 
> > 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.
> 
> Need to clarify that this is for routed traffic not self-generated traffic
> 
> > Section 8.2.1:
> >
> > - A sentence stating how does RAL recognize that the packet is
> > destined for the 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
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Mališa Vučinić <[email-masked]>
Date: Fri, 4 Sep 2020 14:58:49 +0200

Hello Pascal,

Sounds good, thanks for checking this.

Mališa

> On 4 Sep 2020, at 14:54, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello Malisa
>

---

From: Ines Robles <[email-masked]>
Date: Sun, 6 Sep 2020 01:38:00 +0300

Hi Mališa,

Many many thanks for your review. Please find below comments in-line.

On Wed, Jul 29, 2020 at 4:22 PM Mališa Vučinić via Datatracker <
[email-masked]> wrote:

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

<Ines> In section 3 times the  normative vocabulary is used not specially
oriented to the use cases but to the general behavior. :

-”The DODAG root MUST force it to zero when passing the packet out to the
Internet. The Internet will therefore not see any SenderRank  information”

-”an intermediate router that needs to add an extension header (e.g.  RH3
or RPL Option) MUST still encapsulate the packet in an (additional) outer
IP header”

-“The RPI MUST be present in every single RPL data packet.”: in order to
avoid e.g loops

In section 7 where the use cases are explained, we have not used normative
language, since they are basically examples.

What do you think?

</Ines>

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

<Ines>

 We specify the use of IP6-IP6  in section 2: “Note: Due to lack of space
in some figures (tables) we refer to IPv6-in-IPv6 as IP6-IP6.”

</Ines>

>
> My detailed comments are given below.
>
> Section 1:
>
> 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.
>

<Ines> New text:

Most of the use cases described therein require the use of IPv6-in-IPv6
packet encapsulation.

When encapsulating and decapsulating packets, RFC 6040 [RFC6040] MUST be
applied to map the setting of the explicit congestion notification (ECN)
field between inner and outer headers.

The normative is used in order to highlight support of ECN for any
tunnelling solutions.

What do you think?

</Ines>

>
> 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.
>
> <Ines> done </Ines>

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

 In order to be able to decompress, the node should support RFC8138.

The DODAG configuration Option indicates the setting 0x63 or 0x23.

Note that nodes are not part of the RPL instance indicated in the RPI and
should not generate or forward packets for that instance before they
receive the first DIO.

In the case of reboot, the node (6LN or 6LR) does not remember the RPI
Option Type (i.e., whether or not the flag is set), so the node will not
trigger DIO messages until a DIO message is received indicating the RPI
value to be used. The node will use the value 0x23 if the network supports
this feature.

</Ines>

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

<Ines> the use of the MUST is to enforce the explanation of the use case
when the RPI is present . It tends to add clarification to the reader

As Pascal pointed - RFC 6553 states: “ Datagrams sent between RPL routers
MUST include a RPL Option or RPL Source Route Header ([RFC6554
<https://tools.ietf.org/html/rfc6554>]) and MAY include both.“ RFC 8138
requires it at all times for compression. Now we MUST the RPI in all cases,
it is simpler.

</Ines>

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

<Ines> done </Ines>

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

<Ines>  Corrected, we have deleted “The root always have to encapuslate on
the way down”</Ines>

>
> 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.
>
> <Ines> corrected on the table </Ines>

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

<Ines>  Added: “Having the RAL information about the RPL domain, it may
encapsulate to the root when the destination is not in the RPL domain of
the RAL.”

</Ines>

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

<Ines> As the RUL parent adds  RPL headers in the RUL packet, the first 6LR
(6LR_1) will add an RPI inside a new IPv6-in-IPv6 header.

What do you think?

 </Ines>

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

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

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

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

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

> - s/have to encapuslate/has to encapsulate
>
<Ines>  done </Ines>

>
> >  If the originating node does not not
> - s/does not not/does not
>
<Ines>  done </Ines>

> > and add it's own
> - s/it’s/its
<Ines>  done </Ines>

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

>
> > 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
>
<Ines>  done </Ines>

Changes are displayed in
https://github.com/roll-wg/useofrplinfo/blob/master/draft-ietf-roll-useofrplinfo-41.txt

Thank you very much again for your useful comments,

Ines.

---

From: Mališa Vučinić <[email-masked]>
Date: Tue, 8 Sep 2020 12:02:46 +0200

Hi Ines,

Thanks for making these changes, they are fine by me.

Mališa

> On 6 Sep 2020, at 00:38, Ines Robles <[email-masked]> wrote:
> 
> Hi Mališa,
> 
> On Wed, Jul 29, 2020 at 4:22 PM Mališa Vučinić via Datatracker <[email-masked] <mailto:[email-masked]>> wrote:
> Reviewer: Mališa Vučinić
> draft-ietf-roll-useofrplinfo-40. In general, I believe the document is ready to
> 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
> <Ines> In section 3 times the  normative vocabulary is used not specially oriented to the use cases but to the general behavior. :
> 
> -”The DODAG root MUST force it to zero when passing the packet out to the Internet. The Internet will therefore not see any SenderRank  information”  
> 
> -”an intermediate router that needs to add an extension header (e.g.  RH3 or RPL Option) MUST still encapsulate the packet in an (additional) outer IP header”
> 
> -“The RPI MUST be present in every single RPL data packet.”: in order to avoid e.g loops
> 
> 
> In section 7 where the use cases are explained, we have not used normative language, since they are basically examples. 
> 
> What do you think?
> 
> </Ines>
> 
>  
> 
> As a minor note, there also appears to be an inconsistent use of the IP6-IP6
>  We specify the use of IP6-IP6  in section 2: “Note: Due to lack of space in some figures (tables) we refer to IPv6-in-IPv6 as IP6-IP6.”
> </Ines>
> 
>  
> 
> > Since some of the uses cases here described, use IPv6-in-IPv6 encapsulation. 
> [RFC6040], which defines how the explicit congestion notification (ECN) field
> Most of the use cases described therein require the use of IPv6-in-IPv6 packet encapsulation. 
> When encapsulating and decapsulating packets, RFC 6040 [RFC6040] MUST be applied to map the setting of the explicit congestion notification (ECN) field between inner and outer headers.
> 
> The normative is used in order to highlight support of ECN for any tunnelling solutions.  
> 
> What do you think?
> 
> </Ines>
> 
>  
> 
> Section 4.2:
> > The non-storing mode case does not require the type change from 0x63 to 0x23,
> adversely affect the non-storing case. - It is not clear what RPI option type
> > 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
> Note that nodes are not part of the RPL instance indicated in the RPI and should not generate or forward packets for that instance before they receive the first DIO.
> 
> In the case of reboot, the node (6LN or 6LR) does not remember the RPI Option Type (i.e., whether or not the flag is set), so the node will not trigger DIO messages until a DIO message is received indicating the RPI value to be used. The node will use the value 0x23 if the network supports this feature.
> 
> </Ines>
> 
>  
> Section 6:
> 
> <Ines> the use of the MUST is to enforce the explanation of the use case when the RPI is present . It tends to add clarification to the reader
> 
> As Pascal pointed - RFC 6553 states: “ Datagrams sent between RPL routers MUST include a RPL Option or RPL Source Route Header ([RFC6554 <https://tools.ietf.org/html/rfc6554>]) and MAY include both.“ RFC 8138 requires it at all times for compression. Now we MUST the RPI in all cases, it is simpler.
> 
> </Ines>
> 
>  
> 
> down. In the basic case of root to RAL communication, IPv6-in-IPv6 is marked as
> “No”. Please clarify.
> 
> <Ines>  Corrected, we have deleted “The root always have to encapuslate on the way down”</Ines> 
> 
> Section 8.1.3:
> 
> ignore it (per [RFC8200]); thus, encapsulation is not necessary. - Figure 22
> - A sentence stating how does RAL recognize that the packet is destined for the
> <Ines>  Added: “Having the RAL information about the RPL domain, it may encapsulate to the root when the destination is not in the RPL domain of the RAL.”
> </Ines>
> 
> 
> 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
> <Ines> As the RUL parent adds  RPL headers in the RUL packet, the first 6LR (6LR_1) will add an RPI inside a new IPv6-in-IPv6 header. 
> 
> What do you think?
> 
>  </Ines> 
> 
> Nits:
> > The ROLL WG analysized how [RFC2460] rules apply to storing and non-storing
> > The migration procedure it is triggered when the DIO is sent with the flag
> > Namely, it remains at 0x63 until it is sure that the network is capable of
> Changes are displayed in https://github.com/roll-wg/useofrplinfo/blob/master/draft-ietf-roll-useofrplinfo-41.txt <https://github.com/roll-wg/useofrplinfo/blob/master/draft-ietf-roll-useofrplinfo-41.txt> 
>

---

From: Ines Robles <[email-masked]>
Date: Wed, 9 Sep 2020 00:12:05 +0300

Thank you very much Malisa for confirming.

Best,

Ines

On Tue, Sep 8, 2020 at 1:02 PM Mališa Vučinić <[email-masked]>
wrote:

> <Ines> As the RUL parent adds  RPL headers in the RUL packet, the first
> 6LR (6LR_1) will add an RPI inside a new IPv6-in-IPv6 header.
>
> What do you think?
>
>  </Ines>
>
>>
>> Nits: