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

[[e-mail]]

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 <[e-mail]<mailto:[e-mail]>> on behalf of Dominique Barthel <[e-mail]<mailto:[e-mail]>>
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.