Re: [Roll] John Scudder's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS and COMMENT)

Ines Robles <mariainesrobles@googlemail.com> Fri, 05 November 2021 19:38 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 DF02B3A0C95; Fri, 5 Nov 2021 12:38:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 ZOAitusJpsWn; Fri, 5 Nov 2021 12:37:59 -0700 (PDT)
Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 579853A0C7E; Fri, 5 Nov 2021 12:37:59 -0700 (PDT)
Received: by mail-ua1-x931.google.com with SMTP id l43so19042882uad.4; Fri, 05 Nov 2021 12:37:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nGlV5M1RZifZf/qtg6wDZh7PcwL+U0Sf0YirnTahm/U=; b=NyVdwvGDUTHH4R9liQb2uTY0fJXMZcdfkzSsdbw104MpMGCGM4mB4a7TLobpJgrOtJ t1w0CWs1RzLD3m/D2Pm2RRNPRP8nKj7SHPvZjxUjRDcPv78bHYowryPR58uxhg3uyUl7 /Ouf8eDC7dtFyTeHlBVsIp1N3TcJx63P2iK7KXQZqIXuqkY264C1HpWh8lu/UVSl/lBm oCk3sZq9stN74jxjKBaFQCdPgWkU9ljQbkURan4hONVpc5rUCHNG4AG+6MUmcJZHKEr1 DpdrXFt+CZB2jEERndmkJpVpBK0YG/2de8vzIBwqMqr8y5JHbLHrFgxRyzwfPguzvS0n PSvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nGlV5M1RZifZf/qtg6wDZh7PcwL+U0Sf0YirnTahm/U=; b=rzYY6PVMojYjpmP41+XyQcdBHrHPMsvY63530hTZaoLVUZ65dz0Y8zLOLk1zluCbTt mmj4C0iGrGQ5jZBZzncjX4zwpAhYG97GRD4uZ7wqPHzOwbBL7sBAxFfa396p0kfB9EoC wm5Z9QSjT15CPc3Ve9nBu0nD1v6m2l4qefje0Z7AnpBZ2qUvsaQpc2BNveUfjuuMQZ1Z LbPNEz9/4GAnS9nuWoyM+zZVAIR7gTW0s166Um1Bha99ZFBFT+0rCYHG874JMOnp+9wD 8rn8gSkMOXt1wnJyPk7Mn9yVVa3XjdwYh2GE1g7I7Pj/UacDazqcLMDiU25jBdr5G/5S s7iA==
X-Gm-Message-State: AOAM533zkpzA0Wt/3NupZcTtXHcaQKchyuskGZ+/LoAxT4O8Dorv4Ccc 206zFBTdK22Q6HcU/skeuwrliSRLMfghFnDepvE=
X-Google-Smtp-Source: ABdhPJwFJzxGjcDexPlRrP+ZM0iKDaxtjgUdM4qgSjALomBkg0ubwFpCRhRmoryol92kx9dosnP7uZk7y8M3jZuheAw=
X-Received: by 2002:a67:ec10:: with SMTP id d16mr8249218vso.58.1636141077219; Fri, 05 Nov 2021 12:37:57 -0700 (PDT)
MIME-Version: 1.0
References: <161886431878.23690.10633892549620498188@ietfa.amsl.com> <f80a127b-55a7-9ef6-d7b1-5b6358b1a61d@earthlink.net> <CAP+sJUfcy0Pn1E5C_Y03r4hxdFAJNvFkHNn1jUAX8xe-HfdM7g@mail.gmail.com> <4C51FD1A-AA10-47C9-BAC0-B41C294F10BE@juniper.net>
In-Reply-To: <4C51FD1A-AA10-47C9-BAC0-B41C294F10BE@juniper.net>
From: Ines Robles <mariainesrobles@googlemail.com>
Date: Fri, 5 Nov 2021 21:37:19 +0200
Message-ID: <CAP+sJUcvr8BQZq=fDgs6mtpgqiL2iTJndW3AuuXGnu69J0KbqQ@mail.gmail.com>
To: John Scudder <jgs@juniper.net>
Cc: John Scudder via Datatracker <noreply@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>, The IESG <iesg@ietf.org>, roll-chairs <roll-chairs@ietf.org>, "draft-ietf-roll-aodv-rpl@ietf.org" <draft-ietf-roll-aodv-rpl@ietf.org>, Charlie Perkins <charles.perkins@earthlink.net>, Alvaro Retana <aretana.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000b5cec605d00fc772"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/u3VqmYHxvQYJ3OOG2fAMiNki2lg>
Subject: Re: [Roll] John Scudder's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS and COMMENT)
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: Fri, 05 Nov 2021 19:38:07 -0000

Hi John,

Many thanks for your prompt reply :-).  The week following IETF-112 is Ok.

Best wishes,
Ines.

On Fri, Nov 5, 2021 at 9:34 PM John Scudder <jgs@juniper.net> wrote:

> Hi Ines and all,
>
> Thanks for your patience. I hope it will be OK if I don’t review and reply
> in detail until the week following IETF-112? If it’s more urgent than that,
> let me know please.
>
> Thanks,
>
> —John
>
> On Nov 5, 2021, at 3:28 PM, Ines Robles <mariainesrobles@googlemail.com>
> wrote:
>
>
> [External Email. Be cautious of content]
>
>
> Hello John,
>
> Thank you for your comments to improve the document. We believe that v11
> addresses your DISCUSS points, please let us know.
>
> Please find comments below corresponding to version 11 in [v11]
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> A lot of effort has clearly gone into this work, thank you. I do have one
> topic
> I want to DISCUSS, as it seriously impacted the readability of the document
> from my point of view. I don’t anticipate that it will be very difficult to
> resolve this DISCUSS as it relates to clarity and not to anything
> fundamental.
>
> My chief difficulty with the document is placing it in context. No hints
> are
> given to the reader as to what the expected network environment is. I
> think it
> would be almost sufficient to say, for example “the network environment is
> assumed to be the same as described in RFC 6550, Section 1” for example,
> but
> without that hint and without a strong background in ROLL, I found myself
> struggling. Figures 4 and 5 in particular lead me to believe the expected
> environment looks similar to a classic ISP network — a collection of nodes
> connected by point-to-point links. If this isn’t correct (and I bet it’s
> not)
> that may have led me into incorrect assumptions, which may be reflected in
> my
> other comments below.
>
> [v11] Page 3, new text: The network environment that is considered in this
>    document is assumed to be the same as described in Section 1 of
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc6550*section-1__;Iw!!NEt6yMaO-gk!Rstby0bTB7wzJO1NoK_SCiEP-uCChnwCWuKE4nSeCB3Pg-FgUc84JZy79-H5mg$>
>    [RFC6550]
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc6550*section-1__;Iw!!NEt6yMaO-gk!Rstby0bTB7wzJO1NoK_SCiEP-uCChnwCWuKE4nSeCB3Pg-FgUc84JZy79-H5mg$>
> .
>
>
> Further, it’s not stated anywhere whether AODV-RPL is intended to stand
> alone
> as its own routing protocol, or to be viewed as an extension of RPL. In
> the
> former case, it seems the document is lacking details that are present in
> RFC
> 6550. I’m assuming the latter is the case, but a clear statement to that
> effect
> seems indicated.
>
> [v11] Page 3, new text: AODV-RPL reuses and extends the core RPL
> functionality to support
>    routes with bidirectional asymmetric links
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 1. Section 1:
>
>    Reply.  AODV-RPL currently omits some features compared to AODV -- in
>    particular, flagging Route Errors, blacklisting unidirectional links,
>    multihoming, and handling unnumbered interfaces.
>
> Your use of language is entirely up to you, but I feel obliged to point out
> that there’s been a lot of discussion in the IETF community recently about
> use
> of language that raises sensitive points, and about the term
> “blacklisting” in
> particular. I understand that this is the only place in the document the
> term
> appears, and since it refers to AODV you can’t just use another term, but
> placing it in quotation marks might make it clear that it’s referring
> verbatim
> to the language of RFC 3561.
>
> [v11] (Page 3), new text:  AODV-RPL currently omits some features
> compared to AODV -- in
>    particular, flagging Route Errors, "blacklisting" unidirectional
>    links ([RFC3561
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc3561__;!!NEt6yMaO-gk!Rstby0bTB7wzJO1NoK_SCiEP-uCChnwCWuKE4nSeCB3Pg-FgUc84JZwouiSuEQ$>]),
> multihoming, and handling unnumbered interfaces.
>
>
> 2. Section 1:
>
>   support for storing and non-storing modes.  AODV adds basic messages
>   RREQ and RREP as part of RPL DIO (DODAG Information Object) control
>
> Did you mean “AODV-RPL adds”?
>
>
> [v11] Page 3: It was changed to AODV-RPL adds basic messages
>
>
> 3. Section 2:
>
>    Symmetric route
>       The upstream and downstream routes traverse the same routers.
>
> Same routers? Or same links? (Or both, if multi-access links are part of
> the
> mix, as I imagine they may be?)
>
> [v11] Page 5, new text: Symmetric route: The upstream and downstream
> routes traverse the same routers and
>       over the same links.
>
>
> 4. Section 4.1:
>
>    OrigNode sets its IPv6 address in the DODAGID field of the RREQ-DIO
>    message.  A RREQ-DIO message MUST carry exactly one RREQ option,
>
> Should that say “one of its IPv6 addresses"? Is it even necessary to
> restate
> this? RFC 6550 §6.3.1 already has a clearer requirement:
>
>    DODAGID: 128-bit IPv6 address set by a DODAG root that uniquely
>          identifies a DODAG.  The DODAGID MUST be a routable IPv6
>          address belonging to the DODAG root.
>
> [v11] Page 6-New text: OrigNode selects one of its IPv6 addresses and
> sets it in the DODAGID
>    field of the RREQ-DIO message.
>
>
> 5. Section S4.1:
>
>   TargNode can join the RREQ instance at a Rank whose integer portion
>   is equal to the MaxRank.
>
> Not less than or equal, right? Strict equality to MaxRank is required?
>
> [v11] Page 8, new text: TargNode can join the RREQ instance at a Rank
> whose integer portion
>    is less than or equal to the MaxRank.
>
>
> 6. Section 4.2:
>
>    TargNode sets its IPv6 address in the DODAGID field of the RREP-DIO
>    message.  A RREP-DIO message MUST carry exactly one RREP option,
>
> Same as #4.
>
> [v11] Page 8, new text: TargNode sets one of its IPv6 addresses in the
> DODAGID field of the
>    RREP-DIO message.
>
>
> 7. Section 4.2:
>
>   Address Vector
>      Only present when the H bit is set to 0.  For an asymmetric route,
>      the Address Vector represents the IPv6 addresses of the route that
>      the RREP-DIO has passed.
>
> The first time I read through this, I didn’t understand it at all. On
> re-reading, I think you’re using the word “route” in two different ways in
> the
> same sentence, the first time to mean “route” in the sense of an object in
> the
> protocol, the second time in the more casual sense of “a path through the
> network”. If that’s right, I suggest rewriting the second instance, as in
> “…
> represents the IPv6 addresses of the path through the network the RREP-DIO
> has
> Traversed.”
>
> [v11] Page 10, new text: Address Vector
>       Only present when the H bit is set to 0.  For an asymmetric route,
>       the Address Vector represents the IPv6 addresses of the path
>       through the network the RREP-DIO has passed.
>
> Passed was not changed to Traversed.
>
>
> Also, as in point #4, is it right to say *the* IPv6 addresses? Couldn’t any
> given node have various IPv6 addresses? So maybe just lose the definite
> article, as in “… represents IPv6 addresses of the path…”?
>
> 8. Section 4.3:
>
>   r
>      A one-bit reserved field.  This field MUST be initialized to zero
>      by the sender and MUST be ignored by the receiver.
>
> The figure doesn’t show an “r” field. I assume the field labeled “X”
> should be
> relabeled as “r”?
>
> [v11] Page 11: changed to X.
>
> 9. Section 5:
>
>    Figure 4.  If an intermediate router sends out RREQ-DIO with the S
>    bit set to 1, then all the one-hop links on the route from the
>    OrigNode O to this router meet the requirements of route discovery,
>
> On first reading I didn’t understand this. Having read the whole document,
> I
> now get it (I think!). Possibly changing “meet” to “have met” would have
> been
> enough to get me past my initial befuddlement.
>
> [v11] Page 11: changed to “has met”
>
> 10. Section 5:
>
>    The criteria used to determine whether or not each link is symmetric
>    is beyond the scope of the document.  For instance, intermediate
>
> Should be “criterion … is beyond", or "criteria … are beyond", depending on
> whether you want singular or plural.
>
> [v11] Page12, Not Corrected. [Can this be addressed by the RFC Editor?]
>
>
> 11. Section 5:
>
>   routers can use local information (e.g., bit rate, bandwidth, number
>   of cells used in 6tisch)
>
> I wouldn’t have minded a reference for 6tisch.
>
> [v11]Page 12, reference added, new text: ...cells used in 6tisch [RFC9030
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc9030__;!!NEt6yMaO-gk!Rstby0bTB7wzJO1NoK_SCiEP-uCChnwCWuKE4nSeCB3Pg-FgUc84JZzNb2CTyA$>
> ])...
>
>
> 12. Section 5:
>
>    Upon receiving a RREQ-DIO with the S bit set to 1, a node determines
>    whether this one-hop link can be used symmetrically, i.e., both the
>    two directions meet the requirements of data transmission.  If the
>    RREQ-DIO arrives over an interface that is not known to be symmetric,
>    or is known to be asymmetric, the S bit is set to 0.  If the S bit
>    arrives already set to be '0', it is set to be '0' on retransmission
>
> The term “retransmission” seems misused here. I guess you mean something
> like
> “when the RREQ-DIO is propagated”.
>
> [v11] Page 12, changed to propagated: ..when the RREQ-DIO is propagated.
>
> 13. Section 5:
>
>   Appendix A describes an example method using the upstream Expected
>   Number of Transmissions" (ETX) and downstream Received Signal
>   Strength Indicator (RSSI) to estimate whether the link is symmetric
>   in terms of link quality is given in using an averaging technique.
>
> This sentence needs a rewrite to make it grammatical. It works up until "is
> given in using an averaging technique”.
>
> [v11] Page 13, new text: “ Appendix A
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-roll-aodv-rpl-11*appendix-A__;Iw!!NEt6yMaO-gk!Rstby0bTB7wzJO1NoK_SCiEP-uCChnwCWuKE4nSeCB3Pg-FgUc84JZxX0Ve_6g$>
> describes an example method using the upstream Expected
>    Number of Transmissions (ETX) and downstream Received Signal Strength
>    Indicator (RSSI) to estimate whether the link is symmetric in terms
>    of link quality using an averaging technique.”
>
> 14. Section 6.2.1:
>
>      If the S bit in the received RREQ-DIO is set to 1, the router MUST
>      determine whether each direction of the link (by which the RREQ-
>      DIO is received) satisfies the Objective Function.  In case that
>      the downward (i.e. towards the TargNode) direction of the link
>      does not satisfy the Objective Function, the link can't be used
>      symmetrically, thus the S bit of the RREQ-DIO to be sent out MUST
>      be set as 0.  If the S bit in the received RREQ-DIO is set to 0,
>      the router MUST determine into the upward direction (towards the
>      OrigNode) of the link.
>
> The last sentence doesn’t make sense.
>
> [v11] Page 14, Step 1 section was re-written, new text:”Step 1:
>
>       The router MUST first determine whether to propagate the RREQ-DIO.
>       It does this by determining whether or not the downstream
>       direction of the incoming link satisfies the Objective Function
>       (OF).  If not the RREQ-DIO MUST be dropped, and the following
>       steps are not processed.  Otherwise, the router MUST join the
>       RREQ-Instance and prepare to propagate the RREQ-DIO.  The upstream
>       neighbor router that transmitted the received RREQ-DIO is selected
>       as the preferred parent.”
>
> 15. Section 6.2.1:
>
>      If the router is an intermediate router, then it transmits a RREQ-
>      DIO via link-local multicast;
>
> On what interface? Routers generally can have multiple interfaces. Again,
> this
> is a place a clear description of the network environment might have
> helped.
>
> [v11] Page 15, Step 4 new text as follows: “Step 4:
>
>       The router checks whether one of its addresses is included in one
>       of the ART Options.  If so, this router is one of the TargNodes.
>       Otherwise, it is an intermediate router.
>
>       If the router is an intermediate router, then it transmits the
>       RREQ-DIO via link-local multicast; if the H bit is set to 0, the
>       intermediate router MUST include the address of the interface
>       receiving the RREQ-DIO into the address vector.  Otherwise, the
>       router is TargNode; if it was not already associated with the
>       RREQ-Instance, it prepares and transmits a RREP-DIO (Section 6.3
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-roll-aodv-rpl-11*section-6.3__;Iw!!NEt6yMaO-gk!Rstby0bTB7wzJO1NoK_SCiEP-uCChnwCWuKE4nSeCB3Pg-FgUc84JZxWUDAY_A$>
> ).
>       If, on the other hand, TargNode was already associated with the
>       RREQ-Instance, it takes no further action and does not send an
>       RREP-DIO.”
>
> 16. Section 6.2.2:
>
>   If the OrigNode tries to reach multiple TargNodes in a single RREQ-
>   Instance, one of the TargNodes can be an intermediate router to the
>   others, therefore it MUST continue sending RREQ-DIO to reach other
>   targets.  In this case, before rebroadcasting the RREQ-DIO
>
> The use of the term “broadcast” here confuses me. Is this “broadcast” in
> the RF
> sense? Again, this is a place a clear description of the network
> environment
> might have helped.
>
> [v11] Page 16, rebroadcasting changed to transmitting, new text states: “
> If the OrigNode tries to reach multiple TargNodes in a single RREQ-
>    Instance, one of the TargNodes can be an intermediate router to the
>    others, therefore it MUST continue sending RREQ-DIO to reach other
>    targets.  In this case, before transmitting the RREQ-DIO via link-
>    local multicast, a TargNode MUST delete the Target Option
>    encapsulating its own address, so that downstream routers with higher
>    Rank values do not try to create a route to this TargNode.”
>
> 17. Section 6.2.2:
>
>   send out any RREQ-DIO.  For the purposes of determining the
>   intersection with previous incoming RREQ-DIOs, the intermediate
>   router maintains a record of the targets that have been requested
>   associated with the RREQ-Instance.  Any RREQ-DIO message with
>   different ART Options coming from a router with higher Rank is
>   ignored.
>
> It’s not clear to me if the last sentence goes with the previous and if so,
> how. Does it even relate to multiple targets? Also, different from what?
> If it
> has the same ART Options (same as what?) is it *not* ignored?
>
> [v11] Page 16, new text: “ ...If the intersection is empty, it
>    means that all the targets have been reached, and the router MUST NOT
>    transmit any RREQ-DIO.  For the purposes of determining the
>    intersection with previous incoming RREQ-DIOs, the intermediate
>    router maintains a record of the targets that have been requested for
>    a given RREQ-Instance.  Any incoming RREQ-DIO message having multiple
>    ART Options coming from a router with higher Rank than the Rank of
>    the stored targets is ignored.”
>
> 18. Section 6.3.1:
>
>   implementation-specific and out of scope.  If the implementation
>   selects the symmetric route, and the L bit is not 0, the TargNode MAY
>   delay transmitting the RREP-DIO for duration RREP_WAIT_TIME to await
>   a symmetric route with a lower Rank.  The value of RREP_WAIT_TIME is
>   set by default to 1/4 of the time duration determined by the L bit.
>
> It’s not an L bit though, it’s an L field.
>
> [v11] L bit was changed to L field in the document
>
> 19. Section 6.3.2:
>
>   multicast until the OrigNode is reached or MaxRank is exceeded.  The
>   TargNode MAY delay transmitting the RREP-DIO for duration
>   RREP_WAIT_TIME to await a route with a lower Rank.  The value of
>   RREP_WAIT_TIME is set by default to 1/4 of the time duration
>   determined by the L bit.
>
> Again, it’s an L field. Also, what if L is zero? Is RREP_WAIT_TIME set to
> infinity, as the text implies?
>
> Please do a global search for “L bit”, as there are additional instances I
> haven’t called out.
>
> [v11] L bit was changed to L field in the document
>
> 20. Section 6.4:
>
>   Step 4:
>
>       If the receiver is the OrigNode, it can start transmitting the
>       application data to TargNode along the path as provided in RREP-
>       Instance, and processing for the RREP-DIO is complete.  Otherwise,
>       in case of an asymmetric route, the intermediate router MUST
>       include the address of the interface receiving the RREP-DIO into
>       the address vector, and then transmit the RREP-DIO via link-local
>       multicast.  In case of a symmetric route, the RREP-DIO message is
>
> As with #15: on what interface(s)?
>
> [v11] Page 19,  Step 4 first paragraph remains the same,
> Charlie made a question: “ Are we assuming a single interface?”
> ----------------------------------------------------------------------
> RESPONSE to Comment 20:
> ----------------------------------------------------------------------
>
> AODV-RPL routers can have multiple router interfaces.  Per-node
> configuration of "RREP-DIO transmission interfaces" is an administrative
> feature which is beyond the scope of the document.
>
> 21. Section 10:
>
>   fake AODV-RPL route discoveries.  In this type of scenario, RPL's
>   preinstalled mode of operation, where the key to use for a P2P-RPL
>   route discovery is preinstalled, SHOULD be used.
>
> What type of scenario is that?
>
> [V11] Page 22, new text: When rogue routers might be  present, RPL's
> preinstalled mode of operation, where the key to use  for route discovery
> is preinstalled, SHOULD be used.
>
>
> 22. Appendix A:
>
> s/pakcet/packet/
>
> [V11] Page 25, fixed.
>
> 23. General remark:
>
> Although “acknowledgements” isn’t a required section I was a little
> surprised
> not to encounter it, as it’s usually present. Your call of course.
>
> [v11] Added
>
>
> Thank you very much,
>
> Ines.
>
> On Fri, May 7, 2021 at 4:58 AM Charlie Perkins <
> charles.perkins@earthlink.net> wrote:
>
>> Hello John,
>>
>> It's taken a while for me to get to this, please excuse the delay. I
>> have some followup to your comments interspersed below.
>>
>> On 4/19/2021 1:31 PM, John Scudder via Datatracker wrote:
>> > John Scudder has entered the following ballot position for
>> > draft-ietf-roll-aodv-rpl-10: Discuss
>> >
>> > 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
>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>> <https://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!NEt6yMaO-gk!Rstby0bTB7wzJO1NoK_SCiEP-uCChnwCWuKE4nSeCB3Pg-FgUc84JZzWjkQ5DQ$>
>> > for more information about DISCUSS and COMMENT positions.
>> >
>> >
>> > The document, along with other ballot positions, can be found here:
>> > https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/
>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/__;!!NEt6yMaO-gk!Rstby0bTB7wzJO1NoK_SCiEP-uCChnwCWuKE4nSeCB3Pg-FgUc84JZzbGphdAw$>
>> >
>> >
>> >
>> > ----------------------------------------------------------------------
>> > DISCUSS:
>> > ----------------------------------------------------------------------
>> >
>> > A lot of effort has clearly gone into this work, thank you. I do have
>> one topic
>> > I want to DISCUSS, as it seriously impacted the readability of the
>> document
>> > from my point of view. I don’t anticipate that it will be very
>> difficult to
>> > resolve this DISCUSS as it relates to clarity and not to anything
>> fundamental.
>> >
>> > My chief difficulty with the document is placing it in context. No
>> hints are
>> > given to the reader as to what the expected network environment is. I
>> think it
>> > would be almost sufficient to say, for example “the network environment
>> is
>> > assumed to be the same as described in RFC 6550, Section 1” for
>> example, but
>> > without that hint and without a strong background in ROLL, I found
>> myself
>> > struggling. Figures 4 and 5 in particular lead me to believe the
>> expected
>> > environment looks similar to a classic ISP network — a collection of
>> nodes
>> > connected by point-to-point links. If this isn’t correct (and I bet
>> it’s not)
>> > that may have led me into incorrect assumptions, which may be reflected
>> in my
>> > other comments below.
>> >
>> > Further, it’s not stated anywhere whether AODV-RPL is intended to stand
>> alone
>> > as its own routing protocol, or to be viewed as an extension of RPL. In
>> the
>> > former case, it seems the document is lacking details that are present
>> in RFC
>> > 6550. I’m assuming the latter is the case, but a clear statement to
>> that effect
>> > seems indicated.
>> How about this text:
>>     Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550] is
>>     an IPv6 distance vector routing protocol designed to support multiple
>>     traffic flows through a root-based Destination-Oriented Directed
>>     Acyclic Graph (DODAG).  Typically, a router does not have routing
>>     information for most other routers.  Consequently, for traffic
>>     between routers within the DODAG (i.e., Point-to-Point (P2P) traffic)
>>     data packets either have to traverse the root in non-storing mode, or
>>     traverse a common ancestor in storing mode.  Such P2P traffic is
>>     thereby likely to traverse longer routes and may suffer severe
>>     congestion near the root (for more information see [RFC6997],
>>     [RFC6998]). The network environment that is considered in this
>> document
>>     assumed to be the same as described in Section 1 of [RFC6550].
>>
>> > ----------------------------------------------------------------------
>> > COMMENT:
>> > ----------------------------------------------------------------------
>> >
>> > 1. Section 1:
>> >
>> >     Reply.  AODV-RPL currently omits some features compared to AODV --
>> in
>> >     particular, flagging Route Errors, blacklisting unidirectional
>> links,
>> >     multihoming, and handling unnumbered interfaces.
>> >
>> > Your use of language is entirely up to you, but I feel obliged to point
>> out
>> > that there’s been a lot of discussion in the IETF community recently
>> about use
>> > of language that raises sensitive points, and about the term
>> “blacklisting” in
>> > particular. I understand that this is the only place in the document
>> the term
>> > appears, and since it refers to AODV you can’t just use another term,
>> but
>> > placing it in quotation marks might make it clear that it’s referring
>> verbatim
>> > to the language of RFC 3561.
>>
>> This is an evolving issue.  I am fine with using quotes but otherwise
>> maintaining consistent terminology.  For instance,
>>
>>      AODV-RPL currently omits some features compared to AODV -- in
>>      particular, flagging Route Errors, "blacklisting" unidirectional
>> links
>>      [RFC3561], multihoming, and handling unnumbered interfaces.
>>
>> If there is an official list of terms to search for please let us know.
>>
>> >
>> > 2. Section 1:
>> >
>> >    support for storing and non-storing modes.  AODV adds basic messages
>> >    RREQ and RREP as part of RPL DIO (DODAG Information Object) control
>> >
>> > Did you mean “AODV-RPL adds”?
>> Yes, will fix.
>>
>> >
>> > 3. Section 2:
>> >
>> >     Symmetric route
>> >        The upstream and downstream routes traverse the same routers.
>> >
>> > Same routers? Or same links? (Or both, if multi-access links are part
>> of the
>> > mix, as I imagine they may be?)
>>
>>        The upstream and downstream routes traverse the same routers and
>> over
>>        the same links.
>> > 4. Section 4.1:
>> >
>> >     OrigNode sets its IPv6 address in the DODAGID field of the RREQ-DIO
>> >     message.  A RREQ-DIO message MUST carry exactly one RREQ option,
>> >
>> > Should that say “one of its IPv6 addresses"? Is it even necessary to
>> restate
>> > this? RFC 6550 §6.3.1 already has a clearer requirement:
>> >
>> >     DODAGID: 128-bit IPv6 address set by a DODAG root that uniquely
>> >           identifies a DODAG.  The DODAGID MUST be a routable IPv6
>> >           address belonging to the DODAG root.
>>
>> I'm not quite sure what is requested.  Should it be "OrigNode sets the
>> DODAGID field", relying on the definition provided in RFC 6550? Should
>> it be "OrigNode sets one of its routable IPv6 address in the DODAGID
>> field"?
>> Honestly, I thought the meaning was clear.  Unless there is an
>> objection, I reckon we will use the latter wording.
>>
>> >
>> > 5. Section S4.1:
>> >
>> >    TargNode can join the RREQ instance at a Rank whose integer portion
>> >    is equal to the MaxRank.
>> >
>> > Not less than or equal, right? Strict equality to MaxRank is required?
>> The existing text isn't good.  Instead,
>>
>>     TargNode can join the RREQ instance at a Rank whose integer portion
>>     is less than the MaxRank.
>>
>>
>> > 6. Section 4.2:
>> >
>> >     TargNode sets its IPv6 address in the DODAGID field of the RREP-DIO
>> >     message.  A RREP-DIO message MUST carry exactly one RREP option,
>> >
>> > Same as #4.
>> >
>> > 7. Section 4.2:
>> >
>> >    Address Vector
>> >       Only present when the H bit is set to 0.  For an asymmetric route,
>> >       the Address Vector represents the IPv6 addresses of the route that
>> >       the RREP-DIO has passed.
>> >
>> > The first time I read through this, I didn’t understand it at all. On
>> > re-reading, I think you’re using the word “route” in two different ways
>> in the
>> > same sentence, the first time to mean “route” in the sense of an object
>> in the
>> > protocol, the second time in the more casual sense of “a path through
>> the
>> > network”. If that’s right, I suggest rewriting the second instance, as
>> in “…
>> > represents the IPv6 addresses of the path through the network the
>> RREP-DIO has
>> > traversed.”
>> >
>> > Also, as in point #4, is it right to say *the* IPv6 addresses? Couldn’t
>> any
>> > given node have various IPv6 addresses? So maybe just lose the definite
>> > article, as in “… represents IPv6 addresses of the path…”?
>>
>> Good point.  We will use your formulation.
>>
>> >
>> > 8. Section 4.3:
>> >
>> >    r
>> >       A one-bit reserved field.  This field MUST be initialized to zero
>> >       by the sender and MUST be ignored by the receiver.
>> >
>> > The figure doesn’t show an “r” field. I assume the field labeled “X”
>> should be
>> > relabeled as “r”?
>> Actually, the description should refer to an "X" field, not an "r"
>> field.  We will update.
>>
>>
>> >
>> > 9. Section 5:
>> >
>> >     Figure 4.  If an intermediate router sends out RREQ-DIO with the S
>> >     bit set to 1, then all the one-hop links on the route from the
>> >     OrigNode O to this router meet the requirements of route discovery,
>> >
>> > On first reading I didn’t understand this. Having read the whole
>> document, I
>> > now get it (I think!). Possibly changing “meet” to “have met” would
>> have been
>> > enough to get me past my initial befuddlement.
>>
>> Yes, that's better.
>>
>> >
>> > 10. Section 5:
>> >
>> >     The criteria used to determine whether or not each link is symmetric
>> >     is beyond the scope of the document.  For instance, intermediate
>> >
>> > Should be “criterion … is beyond", or "criteria … are beyond",
>> depending on
>> > whether you want singular or plural.
>> We will use "criteria … are beyond".
>>
>> >
>> > 11. Section 5:
>> >
>> >    routers can use local information (e.g., bit rate, bandwidth, number
>> >    of cells used in 6tisch)
>> >
>> > I wouldn’t have minded a reference for 6tisch.
>> No problem.
>>
>> >
>> > 12. Section 5:
>> >
>> >     Upon receiving a RREQ-DIO with the S bit set to 1, a node determines
>> >     whether this one-hop link can be used symmetrically, i.e., both the
>> >     two directions meet the requirements of data transmission.  If the
>> >     RREQ-DIO arrives over an interface that is not known to be
>> symmetric,
>> >     or is known to be asymmetric, the S bit is set to 0.  If the S bit
>> >     arrives already set to be '0', it is set to be '0' on retransmission
>> >
>> > The term “retransmission” seems misused here. I guess you mean
>> something like
>> > “when the RREQ-DIO is propagated”.
>> That is better.  We will use that.
>>
>> >
>> > 13. Section 5:
>> >
>> >    Appendix A describes an example method using the upstream Expected
>> >    Number of Transmissions" (ETX) and downstream Received Signal
>> >    Strength Indicator (RSSI) to estimate whether the link is symmetric
>> >    in terms of link quality is given in using an averaging technique.
>> >
>> > This sentence needs a rewrite to make it grammatical. It works up until
>> "is
>> > given in using an averaging technique”.
>> How about:
>>      Appendix A describes an example method using the upstream Expected
>>      Number of Transmissions" (ETX) and downstream Received Signal
>>      Strength Indicator (RSSI) to estimate whether the link is symmetric
>>      in terms of link quality using an averaging technique.
>>
>>
>> >
>> > 14. Section 6.2.1:
>> >
>> >       If the S bit in the received RREQ-DIO is set to 1, the router MUST
>> >       determine whether each direction of the link (by which the RREQ-
>> >       DIO is received) satisfies the Objective Function.  In case that
>> >       the downward (i.e. towards the TargNode) direction of the link
>> >       does not satisfy the Objective Function, the link can't be used
>> >       symmetrically, thus the S bit of the RREQ-DIO to be sent out MUST
>> >       be set as 0.  If the S bit in the received RREQ-DIO is set to 0,
>> >       the router MUST determine into the upward direction (towards the
>> >       OrigNode) of the link.
>> >
>> > The last sentence doesn’t make sense.
>> How about:
>>                 ...  If the S bit in the received RREQ-DIO is set to 0,
>>       the router MUST determine the upward direction (towards the
>>       OrigNode) of the link.
>> >
>> > 15. Section 6.2.1:
>> >
>> >       If the router is an intermediate router, then it transmits a RREQ-
>> >       DIO via link-local multicast;
>> >
>> > On what interface? Routers generally can have multiple interfaces.
>> Again, this
>> > is a place a clear description of the network environment might have
>> helped.
>>
>> The link-local multicast should go out over all local interfaces.
>>
>> >
>> > 16. Section 6.2.2:
>> >
>> >    If the OrigNode tries to reach multiple TargNodes in a single RREQ-
>> >    Instance, one of the TargNodes can be an intermediate router to the
>> >    others, therefore it MUST continue sending RREQ-DIO to reach other
>> >    targets.  In this case, before rebroadcasting the RREQ-DIO
>> >
>> > The use of the term “broadcast” here confuses me. Is this “broadcast”
>> in the RF
>> > sense? Again, this is a place a clear description of the network
>> environment
>> > might have helped.
>> This needs to be reformulated to avoid suggesting anything about RF
>> broadcast.  TBD.
>>
>> >
>> > 17. Section 6.2.2:
>> >
>> >    send out any RREQ-DIO.  For the purposes of determining the
>> >    intersection with previous incoming RREQ-DIOs, the intermediate
>> >    router maintains a record of the targets that have been requested
>> >    associated with the RREQ-Instance.  Any RREQ-DIO message with
>> >    different ART Options coming from a router with higher Rank is
>> >    ignored.
>> >
>> > It’s not clear to me if the last sentence goes with the previous and if
>> so,
>> > how. Does it even relate to multiple targets? Also, different from
>> what? If it
>> > has the same ART Options (same as what?) is it *not* ignored?
>> How about:
>>                    .....                     For the purposes of
>> determining the
>>    intersection with previous incoming RREQ-DIOs, the intermediate
>>    router maintains a record of the targets that have been requested
>>    associated with the RREQ-Instance. Any incoming RREQ-DIO message having
>>    multiple ART Options coming from a router with higher Rank than the
>> Rank of
>>    the stored targets is ignored.
>>
>> >
>> > 18. Section 6.3.1:
>> >
>> >    implementation-specific and out of scope.  If the implementation
>> >    selects the symmetric route, and the L bit is not 0, the TargNode MAY
>> >    delay transmitting the RREP-DIO for duration RREP_WAIT_TIME to await
>> >    a symmetric route with a lower Rank.  The value of RREP_WAIT_TIME is
>> >    set by default to 1/4 of the time duration determined by the L bit.
>> >
>> > It’s not an L bit though, it’s an L field.
>> Good point!
>>
>> >
>> > 19. Section 6.3.2:
>> >
>> >    multicast until the OrigNode is reached or MaxRank is exceeded.  The
>> >    TargNode MAY delay transmitting the RREP-DIO for duration
>> >    RREP_WAIT_TIME to await a route with a lower Rank.  The value of
>> >    RREP_WAIT_TIME is set by default to 1/4 of the time duration
>> >    determined by the L bit.
>> >
>> > Again, it’s an L field. Also, what if L is zero? Is RREP_WAIT_TIME set
>> to
>> > infinity, as the text implies?
>> Thanks for pointing this out.  We need to be explicit about it.  I don't
>> think the RREP_WAIT_TIME should ever be zero or infinity. But, if it
>> were, the implementations would still be interoperable in a sense.  Do
>> we really want to get into exactly what wait times make sense in this
>> context?
>>
>>
>> >
>> > Please do a global search for “L bit”, as there are additional
>> instances I
>> > haven’t called out.
>> >
>> > 20. Section 6.4:
>> >
>> >    Step 4:
>> >
>> >        If the receiver is the OrigNode, it can start transmitting the
>> >        application data to TargNode along the path as provided in RREP-
>> >        Instance, and processing for the RREP-DIO is complete.
>> Otherwise,
>> >        in case of an asymmetric route, the intermediate router MUST
>> >        include the address of the interface receiving the RREP-DIO into
>> >        the address vector, and then transmit the RREP-DIO via link-local
>> >        multicast.  In case of a symmetric route, the RREP-DIO message is
>> >
>> > As with #15: on what interface(s)?
>> It should go out to all the neighbors over multiple interfaces if
>> necessary.
>>
>> >
>> > 21. Section 10:
>> >
>> >    fake AODV-RPL route discoveries.  In this type of scenario, RPL's
>> >    preinstalled mode of operation, where the key to use for a P2P-RPL
>> >    route discovery is preinstalled, SHOULD be used.
>> >
>> > What type of scenario is that?
>>
>>   "In this type of scenario" -> "When rogue routers might be present"
>>
>> >
>> > 22. Appendix A:
>> >
>> > s/pakcet/packet/
>> Check.
>> >
>> > 23. General remark:
>> >
>> > Although “acknowledgements” isn’t a required section I was a little
>> surprised
>> > not to encounter it, as it’s usually present. Your call of course.
>> Acknowledgements are due to a lot of people - thanks for the reminder!
>>
>> Naturally Yours,
>> Charlie P.
>>
>>
>