Change:
…linfo-42: (with COMMENT) Hello Ines: I believe we need Michael for the flag day terminology. I do not believe that it denotes specifically a transition but rather the fact that you need to reboot the network to effectuate that transition. After all the method of using a bit also ends up in a transition, but the network can stay up during that time. More below: From: Ines Robles Sent: jeudi 7 janvier 2021 18:50 To: Pascal Thubert (pthubert) ; Pascal Thubert Cc: Michael Richardson Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-roll-useofrplinfo-42: (with COMMENT) Hi Michael, Pascal In the github-version the Ben's issues are addressed as follows: .... Section 2 Flag Day: In this document, refers to a transition that involves having a network with different values of RPI Option Type. Is the flag day the act of transitioning the network from one value to the other, or only the sub-case when it is a disruptive transition, or ...? transitioning the network from one value to the other. Section 3 routed. A RPL Instance is either fully storing or fully non-storing, i.e. a RPL Instance with a combination of storing and non-storing nodes is not supported with the current specifications at the time of writing this document. (I assume there is no conflict between this statement and the behavior described in Section 4.1.1 whereby external routes are advertised with non-storing-mode messaging even in a storing-mode network.) Added text to avoid confusion: RPL supports two modes of Downward traffic: in storing mode (SM), it is fully stateful; in non-storing mode (Non-SM), it is fully source routed. A RPL Instance is either fully storing or fully non-storing, i.e. a RPL Instance with a combination of a fully storing and non-storing nodes is not supported with the current specifications at the time of writing this document. Notice that external routes are advertised (Upwards traffic) with non-storing-mode messaging even in a storing-mode network. Adding “internal” RPL supports two modes of Downward traffic: -> RPL supports two modes of Downward internal traffic: Section 4.1.1 In order to enable IP-in-IP all the way to a 6LN, it is beneficial that the 6LN supports decapsulating IP-in-IP, but that is not assumed by [RFC8504]. If the 6LN is a RUL, the Root that encapsulates a packet SHOULD terminate the tunnel at a parent 6LR unless it is aware that the RUL supports IP-in-IP decapsulation. Is there anything useful to say about how the Root would know that the RUL supports IP-in-IP decapsulation? ("No" is a valid answer :) Not in the scope of this document. Section 4.3 This modification is required in order to be able to decompress the RPL Option with the new Option Type of 0x23. nit(?): is it the RPL Option or the entire header that is decompressed? decompress the option Section 6 For traffic leaving a RUL, if the RUL adds an opaque RPI then the description of the RAL applies. The 6LR as a RPL border router SHOULD rewrite the RPI to indicate the selected Instance and set the flags. I'm not sure that I fully understand this point (specifically, "the description of the RAL applies"). Similar text also appears in the Security Considerations. the description of the RAL applies, means that the 6LR has to modify the RPI that it receives from the leaf. For clarification we updated to: For traffic leaving a RUL, if the RUL adds an opaque RPI then the 6LR as a RPL border router SHOULD rewrite the RPI to indicate the selected Instance and set the flags. Thanks, Ines. Benjamin Kaduk via Datatracker wrote: Benjamin Kaduk has entered the following ballot position for draft-ietf-roll-useofrplinfo-42: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: Unfortunately, I only had time to review the diff from the -29 (that addressed my previous batch of comments) and the -42, and was not able to attempt to look closely at the new tables and their depiction of the added/modified/removed/untouched headers. As such, I do not have many comments. Since we are marking MOP value 7 as reserved, do we expect this document to be listed as a reference for that entry in the registry? Section 1 Most of the use cases described therein require the use of IPv6-in- nit: s/therein/herein/ Section 2 Flag Day: In this document, refers to a transition that involves having a network with different values of RPI Option Type. Is the flag day the act of transitioning the network from one value to the other, or only the sub-case when it is a disruptive transition, or ...? Section 3 routed. A RPL Instance is either fully storing or fully non-storing, i.e. a RPL Instance with a combination of storing and non-storing nodes is not supported with the current specifications at the time of writing this document. (I assume there is no conflict between this statement and the behavior described in Section 4.1.1 whereby external routes are advertised with non-storing-mode messaging even in a storing-mode network.) Section 4.1.1 In order to enable IP-in-IP all the way to a 6LN, it is beneficial that the 6LN supports decapsulating IP-in-IP, but that is not assumed by [RFC8504]. If the 6LN is a RUL, the Root that encapsulates a packet SHOULD terminate the tunnel at a parent 6LR unless it is aware that the RUL supports IP-in-IP decapsulation. Is there anything useful to say about how the Root would know that the RUL supports IP-in-IP decapsulation? ("No" is a valid answer :) Section 4.3 This modification is required in order to be able to decompress the RPL Option with the new Option Type of 0x23. nit(?): is it the RPL Option or the entire header that is decompressed? Section 6 For traffic leaving a RUL, if the RUL adds an opaque RPI then the description of the RAL applies. The 6LR as a RPL border router SHOULD rewrite the RPI to indicate the selected Instance and set the flags. I'm not sure that I fully understand this point (specifically, "the description of the RAL applies"). Similar text also appears in the Security Considerations. Section 8.2.4 There seem to be some changes in the table compared to the -29; were these verified to be correct? Section 12 Also, this applies in the case where the leaf is aware of the RPL instance and passes a correct RPI, the 6LR needs a configuration that allows that leaf to inject in that instance. nit: the second comma should probably be a colon or em dash.
Many thanks Ines! With I m good to green light this and the other 2 drafts (RUL and turnon). Are we ready to publish 43? Michael ? Take care , Pascal
Pascal Thubert wrote: I'm good.

Discussion:
Most of the use cases described herein require the use of IPv6-in- IPv6 packet encapsulation.  When encapsulating and decapsulating <del> packets, RFC 6040 [RFC6040] MUST be applied to map the setting of the explicit congestion notification (ECN) field between inner and outer headers.  Additionally, I-D.ietf-intarea-tunnels is recommended reading to explain the relationship of IP tunnels to existing protocol layers and the challenges in supporting IP tunneling. </del> <ins> packets, RFC6040 MUST be applied to map the setting of the explicit congestion notification (ECN) field between inner and outer headers. Additionally, I-D.ietf-intarea-tunnels is recommended reading to explain the relationship of IP tunnels to existing protocol layers and the challenges in supporting IP tunneling. </ins> Non-constrained uses of RPL are not in scope of this document, and applicability statements for those uses may provide different advice,

encapsulation.  For simplification, this document uses the standalone term leaf to mean a RPL leaf. <del> RPL Packet Information (RPI): The abstract information that RFC6550 places in IP packets.  The term is commonly used, including in this document, to refer to the RPL Option RFC6553 that transports that abstract information in an IPv6 Hop-by-Hop Header. </del> <ins> RPL Packet Information (RPI): The information defined abstractly in RFC6550 to be placed in IP packets.  The term is commonly used, including in this document, to refer to the RPL Option RFC6553 that transports that abstract information in an IPv6 Hop-by-Hop Header. RFC8138 provides an alternate (more compressed) formating for the same abstract information. </ins> RPL-aware-node (RAN): A device which implements RPL.  Please note that the device can be found inside the LLN or outside LLN.

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, <del> planned changeover from one to the other. </del> <ins> disruptive changeover from one to the other. </ins> Non-Storing Mode (Non-SM): RPL mode of operation in which the RPL- aware-nodes send information to the root about their parents.  Thus,

Object) messages are all RPL Control messages but with different Code values.  A RPL Stack is shown in fig_RPLStack. <del> RPL supports two modes of Downward traffic: in storing mode (SM), it is fully stateful; in non-storing mode (Non-SM), it is fully source routed.  A RPL Instance is either fully storing or fully non-storing, i.e. a RPL Instance with a combination of a fully storing and non- storing nodes is not supported with the current specifications at the time of writing this document.  Notice that external routes are advertised (Upwards traffic) with non-storing-mode messaging even in a storing-mode network. </del> <ins> RPL supports two modes of Downward internal traffic: in storing mode (SM), it is fully stateful; in non-storing mode (Non-SM), it is fully source routed.  A RPL Instance is either fully storing or fully non- storing, i.e. a RPL Instance with a combination of a fully storing and non-storing nodes is not supported with the current specifications at the time of writing this document.  External routes are advertised with non-storing-mode messaging even in a storing mode network, see nnstext </ins> 4.

When the packet arrives from Internet to 6LBR the RPI is added in a outer IPv6-in-IPv6 header (with the IPv6-in-IPv6 destination address set to the RAL) and sent to 6LR, which modifies the rank in the RPI. <del> When the packet arrives at the RAL, the IPv6-in-IPv6 header is decapsulated, the RPI is removed and the packet processed. </del> <ins> When the packet arrives at the RAL, the packet is decapsulated, which removes the RPI before the packet is processed. </ins> The Storing-int2rpl shows the table that summarizes what headers are needed for this use case.