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

Ines Robles <mariainesrobles@googlemail.com> Thu, 09 April 2020 07:34 UTC

Return-Path: <mariainesrobles@googlemail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDCE93A0D85 for <roll@ietfa.amsl.com>; Thu, 9 Apr 2020 00:34:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqiJhXXF6-QR for <roll@ietfa.amsl.com>; Thu, 9 Apr 2020 00:34:16 -0700 (PDT)
Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6483D3A0D7E for <roll@ietf.org>; Thu, 9 Apr 2020 00:34:16 -0700 (PDT)
Received: by mail-vs1-xe2c.google.com with SMTP id j65so1918474vsd.12 for <roll@ietf.org>; Thu, 09 Apr 2020 00:34:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=KYKGHJ1dVZoDDZFydfm+no5L7I+pdO8XPxvvon1QaSY=; b=lb/7bYn9B33gapGBoqWA3Og4+NIbEevogaU1+RZtySwnTPwNzuF6Vb0I7z4JSOM7MB JeWuzIQl5+4M95izTXD3oGD4e30XNQgkh6ufaky2xbWKS0y6wv12hI3dhuGoIeEa+ESk CxNdq9vFHs0Df+DoHS2dSPm4RP15g5QynYZd8IsThEDpEaWVoYPb2PV5RRe9aloxp2Kv 7D1xxIUTE3saaXMumWTe4uutKgZmUfmhV8piLSSFt3OhXilc857V7eCHs1yuxISjumeg P+JR/Oo/YgmxJU2QgOvDk+osmcmqpvejco2f9XuWT/RVDQP1DtKDgey/eUd+ZI9C7Zfz CKxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=KYKGHJ1dVZoDDZFydfm+no5L7I+pdO8XPxvvon1QaSY=; b=ZUBmna3rQRaXTMLQ/N4EQY5fV2xWMZujS952hDHwz3ksdLa+FYsmOCClKAlm/mDTSM UDvLM0Nb2v8jxdcKGMOxYCCxZjEqSU6a9YtWC6o0SduOMXoq3prnFAu/VtFGIqz5CM1B eBNClTFWmEK8IqJDeG4ZNe53MTl0DvzlOTTTAkp3fX85h4jnVNi5fpO6JU+KtZq4tu22 aOLOn3qAonQlX14wGSqrJ0J7G6nWE2t/CU1N3BWLKTquVcK78wkJgcWOSRJ4ZkX5moxi pnSjZ5yRbQT/qVuZxD7MTqjdOlEUg/qoo/CbQC2YstbdaZMxO2wgywBsyw/EFN70PjBb Ougg==
X-Gm-Message-State: AGi0PuZ7rRRommB+SHFzt8D60gMifPSsJfZwk+R7O9hc7L8VXs+Q+7Mk KhQuZuAqoVBnxC1bv2C+ZVxYAw5lrVILCA4YhXDKqyBE
X-Google-Smtp-Source: APiQypL1eJYgJ9BQ7WOEC/fnTOR/KF5begXYEYNruK9zfkmqKATBnwEC0PcppIX182Yx9kyaqfDGjcfRmQ5IwRVK3ew=
X-Received: by 2002:a67:e83:: with SMTP id 125mr3421923vso.100.1586417654260; Thu, 09 Apr 2020 00:34:14 -0700 (PDT)
MIME-Version: 1.0
References: <158498166784.6801.9613080205022489175@ietfa.amsl.com> <CAP+sJUcMu1aoAPSf5BqYe07Y0Z3FNvm6uD+O_Dvdz6uuqZZ1bw@mail.gmail.com> <MN2PR11MB3565700D99E1EBD8378B750DD8F00@MN2PR11MB3565.namprd11.prod.outlook.com> <28141_1586356389_5E8DE0A5_28141_164_1_DAB3AA9C.736B7%dominique.barthel@orange.com> <14013_1586364972_5E8E022C_14013_424_1_DAB3AF42.736E6%dominique.barthel@orange.com>
In-Reply-To: <14013_1586364972_5E8E022C_14013_424_1_DAB3AF42.736E6%dominique.barthel@orange.com>
From: Ines Robles <mariainesrobles@googlemail.com>
Date: Thu, 9 Apr 2020 10:33:35 +0300
Message-ID: <CAP+sJUd4KVqBnnJJngVXWJHcS2znTmrHN0Lc_OsGiOO0zT2rfg@mail.gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bf68d705a2d6a4b0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/EXtAjRMl5GDSFN0u3lKxMAvpS2c>
Subject: Re: [Roll] New Version for draft-ietf-roll-useofrplinfo-38.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Apr 2020 07:34:20 -0000

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 <dominique.barthel@orange.com> 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 <roll-bounces@ietf.org> on behalf of Dominique Barthel <
> dominique.barthel@orange.com>
> Répondre à : "roll@ietf.org" <roll@ietf.org>
> Date : Wednesday 8 April 2020 16:33
> À : "roll@ietf.org" <roll@ietf.org>
> 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 <roll-bounces@ietf.org> on behalf of "Pascal Thubert
> (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>
> Répondre à : "roll@ietf.org" <roll@ietf.org>
> Date : Monday 23 March 2020 18:57
> À : "roll@ietf.org" <roll@ietf.org>
> 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 <roll-bounces@ietf.org> *On Behalf Of *Ines Robles
> *Sent:* lundi 23 mars 2020 17:52
> *To:* roll <roll@ietf.org>
> *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: <internet-drafts@ietf.org>
> Date: Mon, Mar 23, 2020 at 6:41 PM
> Subject: New Version Notification for draft-ietf-roll-useofrplinfo-38.txt
> To: Michael C. Richardson <mcr+ietf@sandelman.ca>ca>, Pascal Thubert <
> pthubert@cisco.com>gt;, Maria Ines Robles <mariainesrobles@gmail.com>
>
>
>
>
> 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
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>