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

[Ines Robles <[e-mail]>]

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



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