Subject: Re: [Roll] New Version for draft-ietf-roll-useofrplinfo-38.txt

From: <[email-masked]>
Date: Wed, 8 Apr 2020 14:33:08 +0000

Hello all,

I'm doing another pass at reviewing draft-ietf-roll-useofrplinfo-38. I went as far as 7.2.1 at this time.
I've found a few issues/questions.
After discussing them with Pascal, I've submitted a Pull Request that addresses some of the questions, https://github.com/roll-wg/useofrplinfo/pull/9, have a look and I'm happy to discuss them.
One issue to be discussed is a contradiction between the beginning of Section 6, which says that the 6LBR MUST set the DagRank to 0 before letting the RPI go onto the Internet, and the corresponding example in Section 7, which says that the RPI is untouched. I'm not sure what the decision is about this.
Probably more questions/comments to follow as I progress through the document.
Another PR with nit fixes as well.
Best regards

Dominique

De : Roll <[email-masked]<mailto:[email-masked]>> on behalf of "Pascal Thubert (pthubert)" <pthubert=[email-masked]<mailto:pthubert=[email-masked]>>
Répondre à : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date : Monday 23 March 2020 18:57
À : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : Re: [Roll] New Version for draft-ietf-roll-useofrplinfo-38.txt

Dear Ines:

I checked and found it ready for publication.

Many thanks for your patience!

Be safe;

Pascal

From: Roll <[email-masked]<mailto:[email-masked]>> On Behalf Of Ines Robles
Sent: lundi 23 mars 2020 17:52
To: roll <[email-masked]<mailto:[email-masked]>>
Subject: [Roll] New Version for draft-ietf-roll-useofrplinfo-38.txt

Dear all,

We have updated the document:

-  We add in Section 7.1.3. SM: Example of Flow from Root to RUL, a case with no encapsulation (Figure 11)
- We add more clarification to the tables, e.g. in the Modified headers row, we changed IP-IP(RPI) to RPI - this indicates that only the RPI is modified and not the IP-IP.
- Adding text to explain the modifications.
- We eliminate the Hop-by-Hop re-encapuslation definition and following mention in the text, because it is not used.

Diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-38.txt

Comments welcome,

Thank you,

The authors.
---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, Mar 23, 2020 at 6:41 PM
Subject: New Version Notification for draft-ietf-roll-useofrplinfo-38.txt
To: Michael C. Richardson <[email-masked]<mailto:[email-masked]>>, Pascal Thubert <[email-masked]<mailto:[email-masked]>>, Maria Ines Robles <[email-masked]<mailto:[email-masked]>>

A new version of I-D, draft-ietf-roll-useofrplinfo-38.txt
has been successfully submitted by Maria Ines Robles and posted to the
IETF repository.

Name:           draft-ietf-roll-useofrplinfo
Revision:       38
Title:          Using RPI Option Type, Routing Header for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data Plane
Document date:  2020-03-23
Group:          roll
Pages:          63
URL:            https://www.ietf.org/internet-drafts/draft-ietf-roll-useofrplinfo-38.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/
Htmlized:       https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-38
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-roll-useofrplinfo
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-38

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.

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<http://tools.ietf.org>.

The IETF Secretariat

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Wed, 8 Apr 2020 16:56:10 +0000

Hello all,

More questions/comments:

In Section 5, leaf nodes G and J, which are assumed to "not speak RPL" are said to be referred as "IPv6 node" in this document. (seems to be used 4 times, may not justify for a special name).
However, RFC8504 uses "IPv6 node" to mean either "IPv6 host" or "IPv6 router".
I suggest we align terminology. Shall we call G and J "IPv6 hosts" instead?
On page 18, "IPv6 nodes" are said to include Internet routers.

In Section 7.3.2:
- the example provided (nodes F, D, B, E and G) does not include the 6LBR/root that the previous sentence mandates.
- The text says that the Root removes the RPI1, but Figure 19 shows that is it left untouched.

In Section 7.3.4:
- the text says that the RPI is ignored at the RUL dst node, but Figure 21 shows that the RPI is removed at the parent 6LR and does not reach the RUL dst node.

In Section 8.2.1:
The table shows that the RPI is untouched but the 6LBR/Root. As noted earlier, Section 6 says that the 6LBR MUST set the DagRank to 0 when passing the packet to the Internet.

In Section 8.3.1:
There is this strange statement "It should be able to remove the RPI(RPI1), as it was contained in an IPv6-in-IPv6 header addressed to it. Otherwise, …". It looks like the authors are unsure.
If the explanation is valid (when the IPv6-in-IPv6 header is addressed to one-self, then one can remove the header extensions together with the encapsulating header), then the statement should be affirmative: "it removes the RPI(RPI1)".
Or are there situations where the explanation is false ?

In Section 8.3.1:
SRH is used in the text, and RH3 in Figures 32 and 33. Overall, SRH is only used a few times in the document, and is not defined.
"the IPv6 header is swapped with the SRH so both are changed alongside with the RPI2" —>  "Addresses in the IPv6 header are swapped with that of the RH3, …" ?

In Section 9
"(in either mode)": I suppose you are referring to storing and non-storing modes. It is not obvious at this point in the text.
"An operator that finds itself with a lot of traffic". Does "a lot of traffic" change the conclusions?

In Section 10:
"In case that a node join to a network that only process 0x63": what does it mean that "a network processes 0x63"? What type of node "joins"?
This paragraph needs rewriting.

That's all for me.
Expect a PR with nit fix suggestions in the coming hours/day.
Best regards

Dominique

De : Roll <[email-masked]<mailto:[email-masked]>> on behalf of Dominique Barthel <[email-masked]<mailto:[email-masked]>>
Répondre à : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date : Wednesday 8 April 2020 16:33
À : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : Re: [Roll] New Version for draft-ietf-roll-useofrplinfo-38.txt

Hello all,

Dominique

Dear Ines:

Be safe;

Pascal

Dear all,

Comments welcome,

Thank you,

The authors.
---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, Mar 23, 2020 at 6:41 PM
Subject: New Version Notification for draft-ietf-roll-useofrplinfo-38.txt
To: Michael C. Richardson <[email-masked]<mailto:[email-masked]>>, Pascal Thubert <[email-masked]<mailto:[email-masked]>>, Maria Ines Robles <[email-masked]<mailto:[email-masked]>>

Abstract:

The IETF Secretariat

---

From: Ines Robles <[email-masked]>
Date: Thu, 9 Apr 2020 10:33:35 +0300

Hello Dominique,

Thank you very much for your detailed review! :-), We will address your
comments and get back to you.

Best,

Ines.

On Wed, Apr 8, 2020 at 7:56 PM <[email-masked]> wrote:

> Hello all,
>
>
> More questions/comments:
>
> In Section 5, leaf nodes G and J, which are assumed to "not speak RPL" are
> said to be referred as "IPv6 node" in this document. (seems to be used 4
> times, may not justify for a special name).
> - the example provided (nodes F, D, B, E and G) does not include the
> 6LBR/root that the previous sentence mandates.
> - the text says that the RPI is ignored at the RUL dst node, but Figure 21
> shows that the RPI is removed at the parent 6LR and does not reach the RUL
> dst node.
>
> In Section 8.2.1:
> The table shows that the RPI is untouched but the 6LBR/Root. As noted
> earlier, Section 6 says that the 6LBR MUST set the DagRank to 0 when
> passing the packet to the Internet.
>
> In Section 8.3.1:
> There is this strange statement "It should be able to remove the
> RPI(RPI1), as it was contained in an IPv6-in-IPv6 header addressed to it.
> Otherwise, …". It looks like the authors are unsure.
> If the explanation is valid (when the IPv6-in-IPv6 header is addressed to
> one-self, then one can remove the header extensions together with the
> encapsulating header), then the statement should be affirmative: "it
> removes the RPI(RPI1)".
> SRH is used in the text, and RH3 in Figures 32 and 33. Overall, SRH is
> only used a few times in the document, and is not defined.
> "the IPv6 header is swapped with the SRH so both are changed alongside
> with the RPI2" —>  "Addresses in the IPv6 header are swapped with that of
> the RH3, …" ?
>
> In Section 9
> "(in either mode)": I suppose you are referring to storing and non-storing
> modes. It is not obvious at this point in the text.
> "In case that a node join to a network that only process 0x63": what does
> it mean that "a network processes 0x63"? What type of node "joins"?
> De : Roll <[email-masked]> on behalf of Dominique Barthel <
> [email-masked]>
> Répondre à : "[email-masked]" <[email-masked]>
> À : "[email-masked]" <[email-masked]>
> After discussing them with Pascal, I've submitted a Pull Request that
> addresses some of the questions,
> https://github.com/roll-wg/useofrplinfo/pull/9, have a look and I'm happy
> to discuss them.
> One issue to be discussed is a contradiction between the beginning of
> Section 6, which says that the 6LBR MUST set the DagRank to 0 before
> letting the RPI go onto the Internet, and the corresponding example in
> Section 7, which says that the RPI is untouched. I'm not sure what the
> decision is about this.
> De : Roll <[email-masked]> on behalf of "Pascal Thubert
> (pthubert)" <pthubert=[email-masked]>
> Répondre à : "[email-masked]" <[email-masked]>
> À : "[email-masked]" <[email-masked]>
> *From:* Roll <[email-masked]> *On Behalf Of *Ines Robles
> *Sent:* lundi 23 mars 2020 17:52
> *To:* roll <[email-masked]>
> *Subject:* [Roll] New Version for draft-ietf-roll-useofrplinfo-38.txt
>
>
>
> Dear all,
>
>
>
> - We add more clarification to the tables, e.g. in the Modified headers
> row, we changed IP-IP(RPI) to RPI - this indicates that only the RPI is
> modified and not the IP-IP.
>
> - We eliminate the Hop-by-Hop re-encapuslation definition and
> following mention in the text, because it is not used.
>
>
>
> Diff:
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-38.txt
>
>
>
> Comments welcome,
>
>
>
> Thank you,
>
>
>
> The authors.
>
> From: <[email-masked]>
> To: Michael C. Richardson <[email-masked]>, Pascal Thubert <
> [email-masked]>, Maria Ines Robles <[email-masked]>
>
>
>
>
> Title:          Using RPI Option Type, Routing Header for Source Routes
> and IPv6-in-IPv6 encapsulation in the RPL Data Plane
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-roll-useofrplinfo-38.txt
> Status:
> https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/
> Htmlized:
> https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-38
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ietf-roll-useofrplinfo
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-38
>
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: Ines Robles <[email-masked]>
Date: Thu, 9 Apr 2020 18:24:33 +0300

Hi Dominique,

Many thanks again for your comments and proposed changes in the PR. Please
find some comments below,

> On page 18, "IPv6 nodes" are said to include Internet routers.

[IR] I think it is better  to call G and J as a RUL instead IPv6
host/nodes. However, we could add in the definition that a RPL-unaware-leaf
refers to an IPv6 host.

Current:

RPL-unaware-node: A device which does not implement RPL, thus the

   device is not-RPL-aware.  Please note that the device can be found

   inside the LLN. -

RPL-Unaware-Leaf(RUL): A RPL-unaware-node that is also a RPL Leaf.

New:

RPL-unaware-node: same

 RPL-Unaware-Leaf(RUL): A RPL-unaware-node that is also a RPL Leaf. It is
an IPv6 host.

would it be ok?

> 6LBR/root that the previous sentence mandates.
[IR] fixed:  Node F (RAL)--> Node D   --> Node B -->node A -->Node B -->
Node E --> Node G (RUL)

> - The text says that the Root removes the RPI1, but Figure 19 shows that

[IR] To be fixed in the text: the root does not remove the RPI1.  the root
cannot remove an RPI if there is no encapsulation

> shows that the RPI is removed at the parent 6LR and does not reach the RUL

[IR] To delete in text: The RPI is ignored at the RUL dst node.

> passing the packet to the Internet.

[IR] I understand that the senderRank is modified at the root (in case that
is not zero) for security purposes. Then, Section 7 has to be modified
accordingly as follows:

   -

   Case SM: Example of Flow from RAL to Internet (no encapsulation) the RPI
   in the 6LBR changed from Untouched header to Modified header
   -

   Case SM: Example of Flow from RAL to Internet (encapsulation) the RPI
   added in Modified header
   -

   Case Non-SM: Summary of the use of headers from RAL to Internet with no
   encapsulation. RPI moved to modified headers.

We could also add clarification in the text, stating that the RPI is
untouched in case the Rank is already 0.

what do you think?

> Or are there situations where the explanation is false ?

[IR] Fixed as suggested: “It removes the  RPI(RPI1)”

> with the RPI2" —>  "Addresses in the IPv6 header are swapped with that of
[IR] Changed to RH3

> modes. It is not obvious at this point in the text.

[IR] Add clarification in the text

> traffic" change the conclusions?

[IR] I understand that with a high amount of traffic you might not want to
encapsulate. It is possible if the operator is certain of the  properties
of the leaf

> [IR] What about?
> As mentioned previously, indicating the new RPI in the DODAG Configuration
> option Flag is a way to avoid the flag day (lack of interoperation) in a
> network using 0x63 as the RPI Option Type value. It is suggested that RPL
> implementations accept both 0x63 and 0x23 RPI Option Type values when
> processing the header  to enable interoperability.
>
>

> Expect a PR with nit fix suggestions in the coming hours/day.

Many many thanks!

Ines

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 9 Apr 2020 16:56:06 +0000

Hello Ines

Hi Dominique,

Many thanks again for your comments and proposed changes in the PR. Please find some comments below,

On Wed, Apr 8, 2020 at 7:56 PM <[email-masked]<mailto:[email-masked]>> wrote:
Hello all,

More questions/comments:

[IR] I think it is better  to call G and J as a RUL instead IPv6 host/nodes. However, we could add in the definition that a RPL-unaware-leaf refers to an IPv6 host.

Current:

   inside the LLN. -

New:

RPL-unaware-node: same

 RPL-Unaware-Leaf(RUL): A RPL-unaware-node that is also a RPL Leaf. It is an IPv6 host.

would it be ok?

This is not needed... we already defined a leaf as an IPv6 host. We finely crafted those definitions and a last minute change is dangerous ...

Take care;

In Section 7.3.2:
- the example provided (nodes F, D, B, E and G) does not include the 6LBR/root that the previous sentence mandates.
[IR] fixed:  Node F (RAL)--> Node D   --> Node B -->node A -->Node B --> Node E --> Node G (RUL)

[IR] To be fixed in the text: the root does not remove the RPI1.  the root cannot remove an RPI if there is no encapsulation

In Section 7.3.4:

In Section 8.2.1:

[IR] I understand that the senderRank is modified at the root (in case that is not zero) for security purposes. Then, Section 7 has to be modified accordingly as follows:

  *   Case SM: Example of Flow from RAL to Internet (no encapsulation) the RPI in the 6LBR changed from Untouched header to Modified header

  *   Case SM: Example of Flow from RAL to Internet (encapsulation) the RPI added in Modified header

  *   Case Non-SM: Summary of the use of headers from RAL to Internet with no encapsulation. RPI moved to modified headers.

We could also add clarification in the text, stating that the RPI is untouched in case the Rank is already 0.

what do you think?

In Section 8.3.1:

In Section 8.3.1:

In Section 9

[IR] I understand that with a high amount of traffic you might not want to encapsulate. It is possible if the operator is certain of the  properties of the leaf

In Section 10:

[IR] What about?

As mentioned previously, indicating the new RPI in the DODAG Configuration option Flag is a way to avoid the flag day (lack of interoperation) in a network using 0x63 as the RPI Option Type value. It is suggested that RPL implementations accept both 0x63 and 0x23 RPI Option Type values when processing the header  to enable interoperability.

That's all for me.

Many many thanks!

Ines
Best regards

Dominique

De : Roll <[email-masked]<mailto:[email-masked]>> on behalf of Dominique Barthel <[email-masked]<mailto:dominique.barthel@orange..com>>

Hello all,

Dominique

Dear Ines:

Be safe;

Pascal

Dear all,

Comments welcome,

Thank you,

The authors.
---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, Mar 23, 2020 at 6:41 PM
Subject: New Version Notification for draft-ietf-roll-useofrplinfo-38.txt
To: Michael C. Richardson <[email-masked]<mailto:[email-masked]>>, Pascal Thubert <[email-masked]<mailto:[email-masked]>>, Maria Ines Robles <[email-masked]<mailto:[email-masked]>>

Abstract:

The IETF Secretariat

_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll