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

[Ines Robles <[e-mail]>]

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 <[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.
>
> 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]> on behalf of Dominique Barthel <
> [e-mail]>
> Répondre à : "[e-mail]" <[e-mail]>
> Date : Wednesday 8 April 2020 16:33
> À : "[e-mail]" <[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]> on behalf of "Pascal Thubert
> (pthubert)" <pthubert=[e-mail]>
> Répondre à : "[e-mail]" <[e-mail]>
> Date : Monday 23 March 2020 18:57
> À : "[e-mail]" <[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]> *On Behalf Of *Ines Robles
> *Sent:* lundi 23 mars 2020 17:52
> *To:* roll <[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]>
> 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]>, Pascal Thubert <
> [e-mail]>, Maria Ines Robles <[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.
>
> 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]
> https://www.ietf.org/mailman/listinfo/roll
>