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

["Pascal Thubert (pthubert)" <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>> 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).
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.

[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?


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)


- The text says that the Root removes the RPI1, but Figure 19 shows that is it left untouched.

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


[IR] To delete in text: The RPI is ignored at 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.

[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:
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 ?

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

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, …" ?
[IR] Changed to 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.

[IR] Add clarification in the text

"An operator that finds itself with a lot of traffic". Does "a lot of 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

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.

[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.
Expect a PR with nit fix suggestions in the coming hours/day.

Many many thanks!

Ines
Best regards

Dominique

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

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 <[e-mail]<mailto:[e-mail]>> on behalf of "Pascal Thubert (pthubert)" <pthubert=[e-mail]<mailto:pthubert=[e-mail]>>
Répondre à : "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date : Monday 23 March 2020 18:57
À : "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Ines Robles
Sent: lundi 23 mars 2020 17:52
To: roll <[e-mail]<mailto:[e-mail]>>
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: <[e-mail]<mailto:[e-mail]>>
Date: Mon, Mar 23, 2020 at 6:41 PM
Subject: New Version Notification for draft-ietf-roll-useofrplinfo-38.txt
To: Michael C. Richardson <[e-mail]<mailto:[e-mail]>>, Pascal Thubert <[e-mail]<mailto:[e-mail]>>, Maria Ines Robles <[e-mail]<mailto:[e-mail]>>



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.


_________________________________________________________________________________________________________________________

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.


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