Re: [Roll] Iotdir telechat review of draft-ietf-roll-useofrplinfo-40

[Ines Robles <[e-mail]>]

Thank you very much Malisa for confirming.

Best,

Ines

On Tue, Sep 8, 2020 at 1:02 PM Mališa Vučinić <[e-mail]>
wrote:

> Hi Ines,
>
> Thanks for making these changes, they are fine by me.
>
> Mališa
>
> On 6 Sep 2020, at 00:38, Ines Robles <[e-mail]>
> wrote:
>
> Hi Mališa,
>
> Many many thanks for your review. Please find below comments in-line.
>
> On Wed, Jul 29, 2020 at 4:22 PM Mališa Vučinić via Datatracker <
> [e-mail]> wrote:
>
>> Reviewer: Mališa Vučinić
>> Review result: Ready with Issues
>>
>> As part of the IoT-Directorate review process, I went through
>> draft-ietf-roll-useofrplinfo-40. In general, I believe the document is
>> ready to
>> proceed once a couple of issues that I outline below are resolved.
>>
>> I have concerns whether the use of the normative language is appropriate
>> in the
>> use cases section. I believe all such cases are covered either in the
>> sections
>> updating RFC 6553, RFC 6550 and RFC 8138 or in these respective RFCs.
>> Please
>> consider using lowercase keywords in Section 6.
>>
>
> <Ines> In section 3 times the  normative vocabulary is used not specially
> oriented to the use cases but to the general behavior. :
>
> -”The DODAG root MUST force it to zero when passing the packet out to the
> Internet. The Internet will therefore not see any SenderRank  information”
>
> -”an intermediate router that needs to add an extension header (e.g.  RH3
> or RPL Option) MUST still encapsulate the packet in an (additional) outer
> IP header”
>
> -“The RPI MUST be present in every single RPL data packet.”: in order to
> avoid e.g loops
>
>
> In section 7 where the use cases are explained, we have not used normative
> language, since they are basically examples.
>
> What do you think?
>
> </Ines>
>
>
>
>>
>> As a minor note, there also appears to be an inconsistent use of the
>> IP6-IP6
>> acronym. Please use a single acronym throughout the doc, currently a mix
>> of
>> IPv6-in-IPv6 and IP6-IP6 is present.
>>
>
> <Ines>
>  We specify the use of IP6-IP6  in section 2: “Note: Due to lack of space
> in some figures (tables) we refer to IPv6-in-IPv6 as IP6-IP6.”
> </Ines>
>
>
>
>>
>> My detailed comments are given below.
>>
>> Section 1:
>>
>> > Since some of the uses cases here described, use IPv6-in-IPv6
>> encapsulation.
>> It MUST take in consideration, when encapsulation is applied, the RFC6040
>> [RFC6040], which defines how the explicit congestion notification (ECN)
>> field
>> of the IP header should be constructed on entry to and exit from any
>> IPV6-in-IPV6 tunnel. - Please clarify the sentence. Consider whether it is
>> appropriate to have a normative MUST here.
>>
>
> <Ines> New text:
> Most of the use cases described therein require the use of IPv6-in-IPv6
> packet encapsulation.
> When encapsulating and decapsulating packets, RFC 6040 [RFC6040] MUST be
> applied to map the setting of the explicit congestion notification (ECN)
> field between inner and outer headers.
>
> The normative is used in order to highlight support of ECN for any
> tunnelling solutions.
>
> What do you think?
>
> </Ines>
>
>
>
>>
>> Section 4.2:
>> > The non-storing mode case does not require the type change from 0x63 to
>> 0x23,
>> as the root can always create the right packet.  The type change does not
>> adversely affect the non-storing case. - It is not clear what RPI option
>> type
>> should non-storing networks use. A pointer to the discussion in Section
>> 4.3
>> would be useful.
>>
>> <Ines> done </Ines>
>
>
>> Section 4.4:
>>
>> > A node that is decompressing this header MUST decompress using the RPI
>> Option
>> Type that is currently active: that is, a choice between 0x23 (new) and
>> 0x63
>> (old). The node will know which to use based upon the presence of the
>> flag in
>> the DODAG Configuration option defined in Section 4.3. E.g.  If the
>> network is
>> in 0x23 mode (by DIO option), then it should be decompressed to 0x23. -
>> If my
>> understanding is correct, this means that in order to decompress data
>> plane
>> packets, a node first needs to remember the option type mode the network
>> is
>> operating in, advertised in DIOs. Consequently, decompression is not
>> possible
>> before at least one DIO is received.
>>
>> <Ines>
>  In order to be able to decompress, the node should support RFC8138.
>
> The DODAG configuration Option indicates the setting 0x63 or 0x23.
>
> Note that nodes are not part of the RPL instance indicated in the RPI and
> should not generate or forward packets for that instance before they
> receive the first DIO.
>
> In the case of reboot, the node (6LN or 6LR) does not remember the RPI
> Option Type (i.e., whether or not the flag is set), so the node will not
> trigger DIO messages until a DIO message is received indicating the RPI
> value to be used. The node will use the value 0x23 if the network supports
> this feature.
>
> </Ines>
>
>
>
>> Section 6:
>>
>> > The RPI MUST be present in every single RPL data packet.
>> - How is the normative text here appropriate at this point? Is this not
>> redundant with RFC6553?
>>
>
> <Ines> the use of the MUST is to enforce the explanation of the use case
> when the RPI is present . It tends to add clarification to the reader
>
> As Pascal pointed - RFC 6553 states: “ Datagrams sent between RPL routers
> MUST include a RPL Option or RPL Source Route Header ([RFC6554
> <https://tools.ietf.org/html/rfc6554>]) and MAY include both.“ RFC 8138
> requires it at all times for compression. Now we MUST the RPI in all cases,
> it is simpler.
>
> </Ines>
>
>
>
>>
>> >  This document assumes that the LLN is using the no-drop RPI Option Type
>> (0x23). - This statement appears twice in the document and is as such
>> redundant. please remove one appearance.
>>
>
> <Ines> done </Ines>
>
>>
>> Section 8:
>>
>> > The root always have to encapuslate on the way down
>> - It is not clear how come does root need to always encapsulate on the way
>> down. In the basic case of root to RAL communication, IPv6-in-IPv6 is
>> marked as
>> “No”. Please clarify.
>>
>
> <Ines>  Corrected, we have deleted “The root always have to encapuslate
> on the way down”</Ines>
>
>>
>> Section 8.1.3:
>>
>> > When the RPI is added, the RUL, which does not understand the RPI, will
>> ignore it (per [RFC8200]); thus, encapsulation is not necessary. - Figure
>> 22
>> states that for root to RUL communication IPv6-in-IPv6 encapsulation is
>> mandatory which is not consistent with this text.
>>
>> <Ines> corrected on the table </Ines>
>
>
>> Section 8.2.1:
>>
>> - A sentence stating how does RAL recognize that the packet is destined
>> for the
>> Internet would be useful.
>>
>
> <Ines>  Added: “Having the RAL information about the RPL domain, it may
> encapsulate to the root when the destination is not in the RPL domain of
> the RAL.”
> </Ines>
>
>
>> Section 8.2.3:
>>
>> > As RPL headers are added in the RUL packet, the first 6LR (6LR_1) will
>> add an
>> RPI inside a new IPv6-in-IPv6 header. - this statement makes it sound as
>> if RUL
>> originates a packet with RPL headers. Please rephrase.
>>
>
> <Ines> As the RUL parent adds  RPL headers in the RUL packet, the first
> 6LR (6LR_1) will add an RPI inside a new IPv6-in-IPv6 header.
>
> What do you think?
>
>  </Ines>
>
>>
>> Nits:
>> > The ROLL WG analysized how [RFC2460] rules apply to storing and
>> non-storing
>> use of RPL. - s/analysized/analyzed
>>
> <Ines>  done </Ines>
>
>>
>> > that transports that abstract information in an IPv6 Hob-by-Hop Header.
>> - s/hob/hop
>>
> <Ines>  done </Ines>
>
>>
>> > consumed Routing Header and to ignore a HbH header as prescribed by
>> - define HbH, assuming Hop-by-Hop
>>
> <Ines>  done </Ines>
>
>>
>> > The root does not removes the RPI1
>> - s/removes/remove
>>
> <Ines>  done </Ines>
>
>>
>> > The 6LR_ia (ia=1) (Node E)
>> - s/6LR_ia (ia=1)/6LR_1
>> <Ines>  done </Ines>
>>
>
>
>> > The root always have to encapuslate on the way down
>> - s/have to encapuslate/has to encapsulate
>>
> <Ines>  done </Ines>
>
>>
>> >  If the originating node does not not
>> - s/does not not/does not
>>
> <Ines>  done </Ines>
>
>>
>> > and add it's own
>> - s/it’s/its
>>
> <Ines>  done </Ines>
>
>>
>> > The migration procedure it is triggered when the DIO is sent with the
>> flag
>> indicating the new RPI Option Type. - s/it is/is
>>
> <Ines>  done </Ines>
>
>>
>> > Namely, it remains at 0x63 until it is sure that the network is capable
>> of
>> 0x23, then it abruptly change to 0x23. - s/change/changes
>>
> <Ines>  done </Ines>
>
> Changes are displayed in
> https://github.com/roll-wg/useofrplinfo/blob/master/draft-ietf-roll-useofrplinfo-41.txt
>
>
> Thank you very much again for your useful comments,
>
> Ines.
>
>
>
>
>