[Roll] Fwd: New Version Notification for draft-ietf-roll-useofrplinfo-39.txt

[Ines Robles <[e-mail]>]

Dear all,

Please find below the changeLog of userplinfo from v31 to v39 [
https://github.com/roll-wg/useofrplinfo/blob/master/ChangeLog]

Changelog from v31 to 32: [
https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-32.txt]
Section 2:
- Definition of "RPL Leaf" added.
- Definition of "RPL-aware-node (RAN)" added.
- Correction of RAL and RUL.
Section 4.1:
- Added a subsection: Updates to RFC6550: Advertise External Routes with
Non-Storing Mode Signaling.
Section 4.4:
- Updated Figure 5 changed from "IPv6-in-IPv6 6LoRH" to IP-in-IP 6LoRH.
Section 5:
- Clarification added: "6LBR has direct access to Internet and is the root
of the DODAG"
- Assumption deleted: The leaf can be a router 6LR or a host, both
indicated as 6LN
- Assumptions added:
*In the uses cases, we assume that the RAL supports IP-in-IP encapsulation.
* In the uses cases, we dont assume that the RUL supports IP-in-IP
encapsulation.
Section 7:
-Figure 7 changed:
* RUL to root from root to hop or root
* RUL to Int from root to hop or root
* Int to RUL from root to hop or root
* Int to RUL from hop to 6LR
* RUL to RUL from hop to 6LR
- Changes as well on these cases to reflect the change.
Section 14.1
- Added a normative reference to RFC8504
- Nits fixed in the whole Document.
Changelog from v32 to 33: [
https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-33.txt]
Abstract:
-Changed RPL Option Type to RPI Option Type.
Introduction:
-Clarification added about RPI.
Section 2:
- RPI definition added.
Section 4.2:
-Clarification added about RPI.
- Text deleted: A network which is switching from straight 6LoWPAN
compression mechanism to those described in [RFC8138]
will experience a flag day in the data compression anyway, and if possible
this change can be deployed at the same time.
Section 4.3:
-Added clarification that the DODAG Configuration Option might indicate
something different when MOP > 7.
-Text added: "If the flag is received with a value zero (which is the
default), then new nodes will remain in RFC6553
Compatible Mode; originating traffic with the old-RPI Option Type (0x63)
value.
If the flag is received with a value of 1, then the option value for the
RPL Option MUST be set to 0x23".
Nits fixed in the whole document.
Changelog from v33 to 34:[
https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-34.txt]
Introduction:
- Text added: " ...In the other direction, for traffic coming from an
external target into the LLN, the parent (6LR) that
injects the traffic always encapsulates to the root..."
Section 7:
-Hop-by-hop deleted from table and cases.
-Figure 7 changed:
*RUL to root from hop or root to root
*RUL to Int from hop or root to root
*RUL to RAL from RAL to root/RAL
*RUL to RUL from 6LR to root/6LR
-Changes in the mentioned case's sections to reflect the deletion of
hop-by-hop cases.
-Changed on all tables: "Modified headers" row moved from fifth to third
row.
Section 7.3.2:
- Change in the case from RAL to RUL in order to reflect the common parent
is the root (6LBR)
Section 7.3.3:
-Change in the case from RUL to RAL in order to reflect the common parent
is the root (6LBR)
Nits fixed in the whole document.
Changelog from v34 to 35:[
https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-35.txt]
Section 7:
- Figure 7 changed:
* RUL to RAL: changed from root/RAL to root
* RUL to RUL: changed from root/RAL to root
Section 8:N-SM
- Introduction of "may" cases that involves the optional IPv6-in-IPv6
encapsulation.
-Thereby text added:" The term "may(up)" refers that the IPv6-in-IPv6
header may
be necessary in the upwards direction. The term "must(up)" refers
that the IPv6-in-IPv6 header must be present in the upwards
direction. The term "must(down)" refers that the IPv6-in-IPv6 header
must be present in the downward direction."
-Figure 14: modified -cases:
* RAL to Int: IPv6-in-IPv6 column changed from "No" to "may(up)" and
IP-in-IP dst column to root.
* RAL to RAL: IPv6-in-IPv6 column changed from "must" to "may(up) and must
(down)" and IP-in-IP dst column from root/RAL
to root for up and RAL for down.
* RAL to RUL: IPv6-in-IPv6 column changed from "must" to "may(up) and must
(down)" and IP-in-IP dst column from root/6LR
to root for up and 6LR for down.
* RUL to RAL: IPv6-in-IPv6 column changed from "must" to "must(up) and must
(down)" and IP-in-IP dst column from root/RAL
to root for up and RAL for down.
* RUL to RUL: IPv6-in-IPv6 column changed from "must" to "must(up) and must
(down)" and IP-in-IP dst column from root/6LR
to root for up and 6LR for down.
- Changed in the mentioned cases such as update description and add extra
tabl, in order to reflect the optional
encapsulation.
Nits fixed.
Changelog from v35 to 36:[
https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-36.txt]
RFC Editor nits fixed.
Changelog from v36 to 37:[
https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-37.txt]
Section 4.3:
- Clarification added in case of node reboot.
Section 6:
- Two assumptions added:
* For traffic leaving a RUL, if the RUL adds an opaque RPI then the
description of the RAL applies.
* The description for RALs applies to RAN in general.
Section 7:
- Text added:" In each case, 6LR_i represents the intermediate routers from
source to destination. "1 <= i <= n",
n is the number of routers (6LR) that
the packet goes through from source (6LN) to destination"
- Figure 7: cases modified:
* root to RUL: IPv6-in-IPv6 column changed from "No" to "must" and
IPv6-in-IPv6 dst column from "No" to "6LR".
* RAL to Int: IPv6-in-IPv6 column changed from "No" to "may" and
IPv6-in-IPv6 dst column from "No" to "root".
* RAL to RUL: IPv6-in-IPv6 column changed from "No" to "must(down)" and
IPv6-in-IPv6 dst column from "No" to "6LR".
* RUL to RAL: IPv6-in-IPv6 column changed from "must" to
"must(up)/must(down)" and IPv6-in-IPv6 dst column from "root" to
"root" going up and RAL doing down.
* RUL to RUL: IPv6-in-IPv6 column changed from "must" to
"must(up)/must(down)" and IPv6-in-IPv6 dst column from "root" to
"root" going up and 6LR doing down.
-Changed in the mentioned cases (descriptions and tables) to reflect the
modifications in Figure 7.
Nits fixed.
Changelog from v37 to 38: [
https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-38.txt]
Section 2:
-Hop-by-Hop re-encapsulation definition deleted.
Section 4:
-Text deleted: "IP-in-IP encapsulation MAY be avoided for Root to RUL
communication if the RUL is known to process
the packets as forwarded by the parent 6LR without decapsulation."
Section 4.3:
-Text deleted:"This means that the non-storing mode case can avoid ever
using Hop-by-Hop re-encapsulation headers
for traffic originating from the root to the leaves."
Section 7:
- Added text referring one case in SM that RH3 can be used: "However, there
is one
scenario (from the root to the RUL in SM) where the RH3 can be used to
indicate the RUL (Figure 11)."
Figure 7, RAL to RUL case modified:
-"IPv6-in-IPv6 column changed from "must(down)" to "No(up)/must(down)" and
IPv6-in-IPv6 dst column keeps "6LR".
Section 7.1.3: SM -Example of Flow from Root to RUL:
-Text added:"IP-in-IP encapsulation MAY be avoided for Root to RUL
communication.
In SM, it can be replaced by a loose SRH header that indicates the
RUL, in which case the packet is routed to the 6LR as a normal SM
operation, then the 6LR forwards to the RUL based on the SRH, and the
RUL ignores both the consumed SRH and the RPI, as in Non-Storing
Mode." Figure 11 added to reflect this case.
Section 8.3.1:
- Text added:"Note that in the Modified headers row, going up in each
6LR_ia only the
RPI1 is changed. Going down, in each 6LR_id the IPv6 header is
swapped with the SRH so both are changed alongside with the RPI2." and
figure modified.
Nit fixed, tables(figures) aligned to ascii format
Changelog from v38 to 39: To be confirmed:
https://github.com/roll-wg/useofrplinfo/blob/master/draft-ietf-roll-useofrplinfo-39.txt
Section 2: Flag day definition modified as follows:
-Flag Day: In this document, refers to a transition that involves having a
network with different values of RPI Option Type.
Section 4.1
-"may have been learned through as a host route or may have been" changed
to "may have been learned through an external
routing protocol or may have been"
Section 5:
-"DAC and efficient-ND only to participate in the network [RFC6775]. In the
document these leaves (G and J)
are also referred to as an IPv6 node." changed to "DAC and 6LoWPAN ND only
to participate in the network [RFC8505].
In the document these leaves (G and J) are also referred to as a RUL."
Section 6:
-"A corollary is that an RH3 or RPL Option can only be removed by an
intermediate router if it is placed in an encapsulating
IPv6 Header, which is addressed TO the intermediate router.
When it does so, the whole..." changed to
"A corollary is that an intermediate router can remove an RH3 or RPL Option
only if it is placed in an
encapsulating IPv6 Header that is addressed TO this intermediate router.
When doing the above, the whole... "
-"The earlier examples are more extensive to make sure that the process is
clear, while later examples are more concise."
changed to "Throughout the following subsections, the examples are
described in more details in the first subsections,
and more concisely in the later ones."
-"The uses cases are delineated based on the following requirements:"
changed to
"The uses cases are delineated based on the following IPV6 and RPL
mandates:"
Section 7:
-"If the IPv6-in-IPv6 header is needed, the column shows "must"." changed
to "and the destination is N/A (Not Applicable).
If the IPv6-in-IPv6 header is needed, the column shows "must"".
-"to indicate the RUL (Figure 11)." changed to " to point at the RUL
(Figure 11)."
-Figure 7 changed from No to N/A, and
*RAL to RUL | No(up) | 6LR to
*RAL to RUL | No(up) | N/A
Section 7.1.3:
-" The 6LBR will insert an RPI, encapsulated in a IPv6-in-IPv6 header.
The IPv6-in-IPv6 header is addressed to the 6LR parent of the RUL (6LR_n).
The 6LR parent of the RUL removes the header and sends the packet to the
RUL" changed to
"The 6LBR will encapsulate the packet in an IPv6-in-IPv6 header, and
prepend an RPI.
The IPv6-in-IPv6 header is addressed to the 6LR parent of the RUL (6LR_n).
The 6LR parent of the RUL removes the header and sends the packet to the
RUL. "
-Figure 10: IP6-IP6 added in untouched headers.
-SRH changed to RH3
-Figure 11: RH3 added in untouched headers.
Section 7.1.4:
-"When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E), the
6LR_1 will insert an RPI,
encapsulated in a IPv6-in-IPv6 header. The IPv6-in-IPv6 header is addressed
to the root (Node A).
The root removes the header and processes the packet." changed to
"When the packet arrives from the RUL (Node G) to 6LR_1 (Node E), the 6LR_1
will insert encapsulate the packet
in an IPv6-in-IPv6 header and prepend an RPI. The IPv6-in-IPv6 header is
addressed to the root (Node A).
The root removes the header and processes the packet."
-Figure 12: IP6-IP6 added in untouched headers.
Section 7.2.1:
-Deleted: No IPv6-in-IPv6 header is required.
-Added text: "Note that the RPI is modified by 6LBR to set the SenderRank
to zero in case that it is not already zero."
-Figure 13: RPI moved from untouched headers to modified headers.
-Figure 14: IP6-IP6 added in untouched Headers
Section 7.3.2:
-"Node F (RAL)--> Node D --> Node B--> Node E --> Node G (RUL)" changed to
"Node F (RAL)--> Node D --> Node B--> Node A
-->Node B --> Node E --> Node G (RUL)".
-"The root removes the RPI1 and inserts an RPI2 encapsulated to the 6LR
parent of the RUL, which
removes the RPI2 before pasing the packet to the RUL." changed to "The root
does not removes the RPI1 (the root cannot
remove an RPI if there is no encapsulation). The root inserts an RPI2
encapsulated to the 6LR parent of the RUL, which
removes the RPI2 before pasing the packet to the RUL."
Section 7.3.4.
-Deleted: "The RPI is ignored at the RUL dst node."
Section 8.1.3:
-IPv6 node, which does not understand the RPI, changed to RUL, which does
not understand the RPI,
Section 8.1.4:
-"...packets from the IPv6 node." changed to "packets from the RUL"
Section 8.2.1:
-Figure 27: RPI is moved from untouched headers to modified headers.
Section 8.2.3:
"6LR_i are the intermediate routers" changed to "6LR_i represents the
intermediate routers from source to destination,"
Section 8.3.1.:
"It should be able to remove the RPI..." changed to "It removes the RPI..."
Section 9:
-(in either mode) changed to (in storing or non-storing mode)
Section 10:
-"In case that a node join to a network that only process 0x63, it would
produce a flag day as was mentioned previously.
Indicating the new RPI in the DODAG Configuration option Flag is a way to
avoid the flag day in a network.
It is recommended that a network process bothoptions to enable
interoperability " changed to "
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." Comments welcome, The authors.
---------- Forwarded message ---------
From: <[e-mail]>
Date: Mon, Jun 8, 2020 at 6:44 PM
Subject: New Version Notification for draft-ietf-roll-useofrplinfo-39.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-39.txt
has been successfully submitted by Maria Ines Robles and posted to the
IETF repository.

Name:           draft-ietf-roll-useofrplinfo
Revision:       39
Title:          Using RPI Option Type, Routing Header for Source Routes and
IPv6-in-IPv6 encapsulation in the RPL Data Plane
Document date:  2020-06-08
Group:          roll
Pages:          63
URL:
https://www.ietf.org/internet-drafts/draft-ietf-roll-useofrplinfo-39.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/
Htmlized:       https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-39
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-roll-useofrplinfo
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-39

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