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, 05 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. >> >> >
- [Roll] John Scudder's Discuss on draft-ietf-roll-… John Scudder via Datatracker
- Re: [Roll] John Scudder's Discuss on draft-ietf-r… Alvaro Retana
- Re: [Roll] John Scudder's Discuss on draft-ietf-r… John Scudder
- Re: [Roll] John Scudder's Discuss on draft-ietf-r… Alvaro Retana
- Re: [Roll] John Scudder's Discuss on draft-ietf-r… John Scudder
- Re: [Roll] John Scudder's Discuss on draft-ietf-r… Charlie Perkins
- Re: [Roll] John Scudder's Discuss on draft-ietf-r… John Scudder
- Re: [Roll] John Scudder's Discuss on draft-ietf-r… Charlie Perkins
- Re: [Roll] John Scudder's Discuss on draft-ietf-r… Ines Robles
- Re: [Roll] John Scudder's Discuss on draft-ietf-r… Ines Robles
- Re: [Roll] John Scudder's Discuss on draft-ietf-r… John Scudder