jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: roll-useofrplinfo

Commentary: I 'm good
Flag Day: It is a mechanism for resolving an interoperability
situation (e.g. lack of interoperation between new RPI Option Type
(0x23) and old RPI Option Type (0x63) nodes) by making an abrupt,
disruptive changeover from one to the other.
Flag Day: A Flag Day is caused when a network is reconfigured in a
way that nodes running the older configuration can not communicate
with nodes running the new configuration.  For instance, when the
ARPANET changed from IP version 3 to IP version 4 on January 1, 1983
(RFC0801).  In the context of this document, a switch from RPI Option
Type (0x63) and Option Type (0x23) presents as a disruptive
changeover.  In order to reduce the amount of time for such a
changeover, update6550 provides a mechanism to allow nodes to be
incrementally upgraded.
Draft: roll-useofrplinfo

Commentary: … S and COMMENT ) On December 18 , 2020 at 10:42:24 AM ,   ( pthubert ) ( ) wrote : Hello  and all : Yes , I expected policies that would validate the right of a Leaf to participate to a DODAG , or to remap the information from the leaf ( could be the RPI , the opaque field in the EARO , or the 6 - tuple ) into an RPI . Yes , as I said in my response I thought it was quite common . I 'm surprised to find little art to quote . Cool , we 're good ! Pascal Roll mailing list Roll mailing list
Consumed: A Routing Header is consumed when the Segments Left field
is zero, which indicates that the destination in the IPv6 header is
the final destination of the packet and that the hops in the Routing
Header have been traversed.
inspected.
inspected to match a policy that applies to this network and is
correctly processed by the leaves.
Draft: roll-useofrplinfo

Commentary: RPL was missing a good definition of a LEAF . this clarifies . 
 updated the deprecated ref to rul draft
RPL-aware-node: A device which implements RPL.  Please note that the
device can be found inside the LLN or outside LLN.
RPL-Aware-Leaf(RAL): A RPL-aware-node which is a leaf of a
(Destination Oriented Directed Acyclic Graph) DODAG.
RPL-Unaware-Leaf(RUL): A RPL-unaware-node which is a leaf of a
(Destination Oriented Directed Acyclic Graph) DODAG.
RPL Leaf: An IPv6 host that is attached to a RPL router and obtains
connectivity through a RPL Destination Oriented Directed Acyclic
Graph (DODAG).  As an IPv6 node, a RPL Leaf is expected to ignore a
consumed Routing Header and as an IPv6 host, it is expected to ignore
a Hop-by-Hop header.  It results that a RPL Leaf can correctly
receive a packet with RPL artifacts.  On the other hand, a RPL Leaf
is not expected to generate RPL artifacts or to support IP-in-IP
encapsulation.  For simplification, this document uses the standalone
term leaf to mean a RPL leaf.
RPL-aware-node (RAN): A device which implements RPL.  Please note
that the device can be found inside the LLN or outside LLN.
RPL-Aware-Leaf(RAL): A RPL-aware-node that is also a RPL Leaf.
RPL-Unaware-Leaf(RUL): A RPL-unaware-node that is also a RPL Leaf.
The final node should be able to remove one or more IPv6-in-IPv6
headers which are all addressed to it.  The final node does not
process the RPI, the node ignores the RPI.  Further details about
this are mentioned in I-D.thubert-roll-unaware-leaves, which
specifies RPL routing for a 6LN acting as a plain host and not being
aware of RPL.
The final node should be able to remove one or more IPv6-in-IPv6
headers which are all addressed to it.  The final node does not
process the RPI, the node ignores the RPI.  Further details about
this are mentioned in I-D.ietf-roll-unaware-leaves, which specifies
RPL routing for a 6LN acting as a plain host and not being aware of
RPL.
Draft: roll-useofrplinfo

Commentary: … ters but the 6LR that injects the route , and the Root itself .
This specification updates RPL RFC6550 to RECOMMEND that external
targets are advertised using Non-Storing Mode signaling even in a
Storing-Mode network.  This way, all packets to an external target
reach the Root that can encapsulate them, and the Root is informed of
the address of the 6LR that terminates the IP-in-IP tunnel.  In case
of an external target, the Root SHOULD use the same IP-in-IP
encapsulation for packets that it generates or that are originated
within the RPL domain as if the packets were coming from the
Internet.
This specification updates RFC6550 to RECOMMEND that external targets
are advertised using Non-Storing Mode DAO messaging even in a
Storing-Mode network.  This way, external routes are not advertised
within the DODAG and all packets to an external target reach the Root
like normal Non-Storing Mode traffic.  The Non-Storing Mode DAO
informs the Root of the address of the 6LR that injects the external
route, and the root uses IP-in-IP encapsulation to that 6LR, which
terminates the IP-in-IP tunnel and forwards the original packet
outside the RPL domain free of RPL artifacts.  This whole operation
is transparent to intermediate routers that only see traffic between
the 6LR and the Root, and only the Root and the 6LRs that inject
external routes in the network need to be upgraded to add this
function to the network.
Draft: roll-useofrplinfo

Commentary: Changes on the encapsulation of RPI
In Storing Mode, for the examples of Flow from RAL to RUL and RUL to
RUL comprise an IPv6-in-IPv6 and RPI compression headers.  The use of
the IPv6-in-IPv6 header is MANDATORY in this case, and it SHOULD be
compressed with RFC8138 section 7.  As exemplification of compressing
the RPI, section A.1 of RFC8138 illustrates the case in Storing mode
where the packet is received from the Internet, then the root
encapsulates the packet to insert the RPI.  The result is shown in
rtghc.
In Storing Mode, for the examples of Flow from RAL to RUL and RUL to
RUL comprise an IPv6-in-IPv6 and RPI compression headers.  The use of
the IPv6-in-IPv6 header is MANDATORY in this case, and it SHOULD be
compressed with RFC8138 section 7.  rtghc illustrates the case in
Storing mode where the packet is received from the Internet, then the
root encapsulates the packet to insert the RPI.  In that example, the
leaf is not known to support RFC 8138, and the packet is encapsulated
to the 6LR that is the parent and last hop to the final destination.
In rtghc, the source of the IP-in-IP encapsulation is the Root, so it
is elided in the IP-in-IP 6LoRH.  The destination is the parent 6LR
of the destination of the inner packet so it cannot be elided.  It is
placed as the single entry in an SRH-6LoRH as the first 6LoRH.  There
is a single entry so the SRH-6LoRH Size is 0.  In that example, the
type is 1 so the 6LR address is compressed to 2 bytes.  It results
that the total length of the SRH-6LoRH is 4 bytes.  Follows the RPI-
6LoRH and then the IP-in-IP 6LoRH.  When the IP-in-IP 6LoRH is
removed, all the router headers that precede it are also removed.
The Paging Dispatch RFC8025 may also be removed if there was no
previous Page change to a Page other than 0 or 1, since the
LOWPAN_IPHC is encoded in the same fashion in the default Page 0 and
in Page 1.  The resulting packet to the destination is the inner
packet compressed with RFC6282.