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

Ines Robles <mariainesrobles@googlemail.com> Tue, 08 September 2020 21:12 UTC

Return-Path: <mariainesrobles@googlemail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D601A3A148E; Tue, 8 Sep 2020 14:12:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAAF0csksluS; Tue, 8 Sep 2020 14:12:42 -0700 (PDT)
Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2C63A148B; Tue, 8 Sep 2020 14:12:42 -0700 (PDT)
Received: by mail-vs1-xe2a.google.com with SMTP id j3so151121vsm.0; Tue, 08 Sep 2020 14:12:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kE02lw2X9z/MLrgeg9CVLAHB/DaLodwSwRaXYCUOzUs=; b=PNypYL2pMC6wun5OMvzbIvG1OyGjWKKjzD5+clALg4bbAFmdfVf+tx9emRbZeZr8YM LZm6m80RP5SZYc6bSzUQY9lz5RgZrwjS902MOjGPvFGbFVI9B0q3a2wbvdQhLpD5Hdlx W9V+N7xMNCud14YrTvunQGn9Pxto2NJVi9bZa89aCPE2fCKHTbLfogymZZb/7ZKFvoY9 UYSLY4PLp5P3O9pcQbNW7BOvlPsPWwASq7MDp/77kwlq7QW6GI1PuK4quTqqY1Br3Gnv PBqlxYwn4i4zJqo+URPMyGKGktqq4KUrPclUH1PAjyorhClpa1IJjxwxH/5ATFGGHiWG 41Fg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kE02lw2X9z/MLrgeg9CVLAHB/DaLodwSwRaXYCUOzUs=; b=avubekgcxfy8lvUYDif7iq5+N2envWdjvy8pChzoMxFwkO2XOTXCWbnGTDX+6zDAeQ ymGQOM/rGmRcTeVu0bC9Hm2oeis6SRh0UlLclzAJwqCfRVFEbtBwd4kPnmQiO7QeLrY2 ZH/mohiLFpzGLNpcOFxh1TTIx0L/bvlf89JBPS+ivQ+SnqJuNjBee9eWCj3oGv2C8Aky dBaA9YiNBYDM1aJZSk5nxhTB1H6RMyRMUu4Y71gdjXgmmx/vFIvqWOoCtEIDYWwsbHzX 5dELn+/0BYxfDhDPV0v4GhPx19acxOuP0QLK6n37iBd8iug1vWhfrURFYBbOwTpa9rTO Vx/g==
X-Gm-Message-State: AOAM530sngEcLx9nB1JgK6Lp0upCi6AHj3e3Ip+ZxLBIzGwkRHf/Nxcn 2h/jPatwq5aBW0fwRHNksIxZS3UxXzI2XNkTtvMpGCIABS4=
X-Google-Smtp-Source: ABdhPJzUhIAZz+lqmzbv4yWx+b5JbGmv7Wo3hBAUFmW6+zer/SNYu/dx7yZZKfOMzgmPXBOZ6wmAGfP0uB5K1IbtbFw=
X-Received: by 2002:a67:ea88:: with SMTP id f8mr718721vso.2.1599599560966; Tue, 08 Sep 2020 14:12:40 -0700 (PDT)
MIME-Version: 1.0
References: <159602896040.32219.18351168129491497436@ietfa.amsl.com> <CAP+sJUda2f_cwx7-KDQmAGJn5NNKWTJwev2JkweDZU-=p4TixA@mail.gmail.com> <18354E7B-2F0D-4AF9-96F1-CB87EEF0484D@inria.fr>
In-Reply-To: <18354E7B-2F0D-4AF9-96F1-CB87EEF0484D@inria.fr>
From: Ines Robles <mariainesrobles@googlemail.com>
Date: Wed, 9 Sep 2020 00:12:05 +0300
Message-ID: <CAP+sJUe9TJdx0HfdiqQTpds38cK56kGji9TTPZdu0WfoZkzDyw@mail.gmail.com>
To: =?UTF-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <malisa.vucinic@inria.fr>
Cc: IETF IoT Directorate <iot-directorate@ietf.org>, draft-ietf-roll-useofrplinfo.all@ietf.org, roll <roll@ietf.org>, last-call@ietf.org
Content-Type: multipart/alternative; boundary="0000000000009d460305aed3cb2e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/HMi75bytJ8wju-4XstpsPjkwwbg>
Subject: Re: [Roll] Iotdir telechat review of draft-ietf-roll-useofrplinfo-40
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Sep 2020 21:12:45 -0000

Thank you very much Malisa for confirming.

Best,

Ines

On Tue, Sep 8, 2020 at 1:02 PM Mališa Vučinić <malisa.vucinic@inria.fr>
wrote:

> Hi Ines,
>
> Thanks for making these changes, they are fine by me.
>
> Mališa
>
> On 6 Sep 2020, at 00:38, Ines Robles <mariainesrobles@googlemail.com>
> 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 <
> noreply@ietf.org> 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.
>
>
>
>
>