Re: [Roll] New Version for draft-ietf-roll-useofrplinfo-38.txt Wed, 08 April 2020 14:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B7BF3A0D95 for <>; Wed, 8 Apr 2020 07:33:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id anrn7rIuVVcm for <>; Wed, 8 Apr 2020 07:33:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AB3F03A0D7E for <>; Wed, 8 Apr 2020 07:33:11 -0700 (PDT)
Received: from (unknown [xx.xx.xx.2]) by (ESMTP service) with ESMTP id 48y6Fd6xYrz2y0s for <>; Wed, 8 Apr 2020 16:33:09 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1586356390; bh=NNl1vVZii0RTwg0AOsMm6JPEHvx6VlKFCWRiMQtvMzw=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=qIanyzEL0CJXQuypqiMcRWfc7hU0ULTaWM7n+V8IVjvziwBL/nLKFPieBeebLhxJ0 EdTOpkz/0puZxnB75ziIF8d5lFe9vcxFKlCxT0woV3RWtGb6kLQ13/ss3F99EUHcds p4jEGuiJhiLYlL7ikkvGFWKj61DznZzWRpNw1fqaX3YVB854phqNkEjGgRdtebhnCy UCtJ4uPIkhYbDm7tfFM2gO8VZQ9Kbo/23kDbSvBSX3SYxxRZuq9OrpifoN+OteKq1I 8K2ixRPg+tkM24NVgtVNQ2mEi7w/XsVaiqxT1OymZ3nQU6UnCP/TKg29KxGqqmoG6y 8LHEoJ8JYT6vA==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.64]) by (ESMTP service) with ESMTP id 48y6Fd5m19zBrLb for <>; Wed, 8 Apr 2020 16:33:09 +0200 (CEST)
To: Routing Over Low power and Lossy networks <>
Thread-Topic: [Roll] New Version for draft-ietf-roll-useofrplinfo-38.txt
Thread-Index: AQHWDbKfdH+aNa3fGEmLb8bczxMtwA==
Date: Wed, 08 Apr 2020 14:33:08 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_DAB3AA9C736B7dominiquebarthelorangecom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Roll] New Version for draft-ietf-roll-useofrplinfo-38.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Apr 2020 14:33:14 -0000

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


De : Roll <<>> on behalf of "Pascal Thubert (pthubert)" <<>>
Répondre à : "<>" <<>>
Date : Monday 23 March 2020 18:57
À : "<>" <<>>
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;


From: Roll <<>> On Behalf Of Ines Robles
Sent: lundi 23 mars 2020 17:52
To: roll <<>>
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.


Comments welcome,

Thank you,

The authors.
---------- Forwarded message ---------
From: <<>>
Date: Mon, Mar 23, 2020 at 6:41 PM
Subject: New Version Notification for draft-ietf-roll-useofrplinfo-38.txt
To: Michael C. Richardson <<>>, Pascal Thubert <<>>, Maria Ines Robles <<>>

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

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

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.