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

[Ines Robles <[e-mail]>]

Hi Mališa,

Thank you very much for your review.
We will work on it and get back to you.

Best,

Ines.

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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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?
>
> >  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.
>
> 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.
>
> 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.
>
> Section 8.2.1:
>
> - A sentence stating how does RAL recognize that the packet is destined
> for the
> Internet would be useful.
>
> 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.
>
> Nits:
> > The ROLL WG analysized how [RFC2460] rules apply to storing and
> non-storing
> use of RPL. - s/analysized/analyzed
>
> > that transports that abstract information in an IPv6 Hob-by-Hop Header.
> - s/hob/hop
>
> > consumed Routing Header and to ignore a HbH header as prescribed by
> - define HbH, assuming Hop-by-Hop
>
> > The root does not removes the RPI1
> - s/removes/remove
>
> > The 6LR_ia (ia=1) (Node E)
> - s/6LR_ia (ia=1)/6LR_1
>
> > The root always have to encapuslate on the way down
> - s/have to encapuslate/has to encapsulate
>
> >  If the originating node does not not
> - s/does not not/does not
>
> > and add it's own
> - s/it’s/its
>
> > The migration procedure it is triggered when the DIO is sent with the
> flag
> indicating the new RPI Option Type. - s/it is/is
>
> > 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
>
>
>