Re: [Roll] John Scudder's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS and COMMENT)
Charlie Perkins <charles.perkins@earthlink.net> Wed, 18 August 2021 20:00 UTC
Return-Path: <charles.perkins@earthlink.net>
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 DACC03A1B85; Wed, 18 Aug 2021 13:00:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=earthlink.net
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 S9nqPa-_me_s; Wed, 18 Aug 2021 12:59:56 -0700 (PDT)
Received: from mta-201a.oxsus-vadesecure.net (mta-201a.oxsus-vadesecure.net [51.81.229.180]) (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 379623A1B48; Wed, 18 Aug 2021 12:59:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; bh=oDXUiHHPqnTKV6LhONImTF7RbKyIkRv0hMfpbI xhiZU=; c=relaxed/relaxed; d=earthlink.net; h=from:reply-to:subject: date:to:cc:resent-date:resent-from:resent-to:resent-cc:in-reply-to: references:list-id:list-help:list-unsubscribe:list-subscribe:list-post: list-owner:list-archive; q=dns/txt; s=dk12062016; t=1629316794; x=1629921594; b=Vr3fNSWrLFR7UZuFw3tHrdjaPPaYxYq3GcT4aIzZv6Y/uIXYfivFaRU gh2ICcV6gYV7QHlPMvg5qKxTY5H2hpqYij6JkBQtdMvCC4OsxJ8ghrlcFR44ynl54x3rVZN inJD0gtfmLVeQSAJePZoJGHtO48goIvym7y+Zy9GCSHmOWXNrSzfMBUzBMkZJmWhcu/+pk7 r4Nln75ERZ9W/FIY3eP3M7amafJEVc6vJO2kAMj2+3MN6rT8m+oXp9g89+RZ6HUbUCXrFc7 CTWIo7w2Gtf6ZPtxFHM9vYwxLuSXZr848hhB1bENeGe4lR72NaddEw7nN1iCyDyI6tbBHv2 VGQ==
Received: from [192.168.1.72] ([99.51.72.196]) by smtp.oxsus-vadesecure.net ESMTP oxsus2nmtao01p with ngmta id 2bc93ab5-169c7efdc7b99bde; Wed, 18 Aug 2021 19:59:54 +0000
To: John Scudder <jgs@juniper.net>, The IESG <iesg@ietf.org>
Cc: draft-ietf-roll-aodv-rpl@ietf.org, roll-chairs@ietf.org, roll@ietf.org, Ines Robles <mariainesrobles@googlemail.com>, aretana.ietf@gmail.com
References: <161886431878.23690.10633892549620498188@ietfa.amsl.com>
From: Charlie Perkins <charles.perkins@earthlink.net>
Message-ID: <2eb22feb-05e7-d811-9d7c-6b5b7d45bf0c@earthlink.net>
Date: Wed, 18 Aug 2021 12:59:51 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <161886431878.23690.10633892549620498188@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/6iINpj02O00k1EkHkwEtFmrAr3Y>
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: Wed, 18 Aug 2021 20:00:13 -0000
Hello John, Please excuse the unusually long delay it has taken for us to respond to your comments. The responses below have been broken up comment by comment in an attempt to make it easier to keep track of the association between comments and responses. > 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 > 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/ ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- RESPONSE to introductory comment: ---------------------------------------------------------------------- Here is some new text to resolve the comment. 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 RPL 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 is assumed to be the same as described in Section 1 of <xref target="RFC6550"/>. ---------------------------------------------------------------------- COMMENT 1: ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- RESPONSE to Comment 1: ---------------------------------------------------------------------- AODV-RPL currently omits some features compared to AODV -- in particular, flagging Route Errors, "blacklisting" unidirectional links (<xref target="RFC3561"/>, multihoming, and handling unnumbered interfaces. We will use the quotation marks as suggested. ---------------------------------------------------------------------- COMMENT 2: ---------------------------------------------------------------------- 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"? ---------------------------------------------------------------------- RESPONSE to Comment 2: ---------------------------------------------------------------------- Yes. We will modify the text. Thanks for pointing it out. ---------------------------------------------------------------------- COMMENT 3: ---------------------------------------------------------------------- 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?) ---------------------------------------------------------------------- RESPONSE to Comment 3: ---------------------------------------------------------------------- Updated definition: The upstream and downstream routes traverse the same routers and over the same links. ---------------------------------------------------------------------- COMMENT 4: ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- RESPONSE to Comment 4: ---------------------------------------------------------------------- We could quote this definition and cite RFC 6550. It should say that "one of its IPv6 addresses". ---------------------------------------------------------------------- COMMENT 5: ---------------------------------------------------------------------- 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? ---------------------------------------------------------------------- RESPONSE to Comment 5: ---------------------------------------------------------------------- It shouild say that TargNode can join the RREQ instance at a Rank whose integer portion is less than or equal to the MaxRank. ---------------------------------------------------------------------- COMMENT 6: ---------------------------------------------------------------------- 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, ---------------------------------------------------------------------- RESPONSE to Comment 6: ---------------------------------------------------------------------- Same as response to comment #4. ---------------------------------------------------------------------- COMMENT 7: ---------------------------------------------------------------------- 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"? ---------------------------------------------------------------------- RESPONSE to Comment 7: ---------------------------------------------------------------------- You are right. We will fix this. ---------------------------------------------------------------------- COMMENT 8: ---------------------------------------------------------------------- 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"? ---------------------------------------------------------------------- RESPONSE to Comment 8: ---------------------------------------------------------------------- Thanks for pointing this out. We will fix this. ---------------------------------------------------------------------- COMMENT 9: ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- RESPONSE to Comment 9: ---------------------------------------------------------------------- Agree. We will fix this. ---------------------------------------------------------------------- COMMENT 10: ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- RESPONSE to Comment 10: ---------------------------------------------------------------------- Agree. We will use "criteria are beyond". ---------------------------------------------------------------------- COMMENT 11: ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- RESPONSE to Comment 11: ---------------------------------------------------------------------- We will include reference to 6tisch. ---------------------------------------------------------------------- COMMENT 12: ---------------------------------------------------------------------- 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". ---------------------------------------------------------------------- RESPONSE to Comment 12: ---------------------------------------------------------------------- Agree. We will fix this. ---------------------------------------------------------------------- COMMENT 13: ---------------------------------------------------------------------- 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". ---------------------------------------------------------------------- RESPONSE to Comment 13: ---------------------------------------------------------------------- New text: 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. ---------------------------------------------------------------------- COMMENT 14: ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- RESPONSE to Comment 14: ---------------------------------------------------------------------- [A] be set as 0. 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. ---------------------------------------------------------------------- COMMENT 15: ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- RESPONSE to Comment 15: ---------------------------------------------------------------------- We are not assuming nodes with single interface. The link-local multicast should go out over all local interfaces. The document should be reviewed to ensure that this is not ambiguous. ---------------------------------------------------------------------- COMMENT 16: ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- RESPONSE to Comment 16: ---------------------------------------------------------------------- New text: 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. ---------------------------------------------------------------------- COMMENT 17: ---------------------------------------------------------------------- 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? ---------------------------------------------------------------------- RESPONSE to Comment 17: ---------------------------------------------------------------------- New text: 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 incoming RREQ-DIO message having multiple ART Options coming from a router with higher Rank than the Rank of the stored targets is ignored. ---------------------------------------------------------------------- COMMENT 18: ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- RESPONSE to Comment 18: ---------------------------------------------------------------------- Agree. Will be updated. ---------------------------------------------------------------------- COMMENT 19: ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- RESPONSE to Comment 19: ---------------------------------------------------------------------- All instances of "L bit" will be changed to "L field". If L is zero, RREP_WAIT_TIME should be set to the lifetime of the DODAG. <<<<<<<<<<<<< Anand -- this is my GUESS. Please verify >>>>>>>>>>>>>> [Anand] Yes. We need to change "L bit" to "L field" ---------------------------------------------------------------------- COMMENT 20: ---------------------------------------------------------------------- 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)? Question: Are we assuming single interface? ---------------------------------------------------------------------- RESPONSE to Comment 20: ---------------------------------------------------------------------- AODV-RPL routers can have multiple router interfaces. Per-node configuration of "RREP-DIO tranmission interfaces" is an administrative feature which is beyond the scope of the document. ---------------------------------------------------------------------- COMMENT 21: ---------------------------------------------------------------------- 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? ---------------------------------------------------------------------- RESPONSE to Comment 21: ---------------------------------------------------------------------- Replace "In this type of scenario" by "When rogue routers might be present" ---------------------------------------------------------------------- COMMENT 22: ---------------------------------------------------------------------- 22. Appendix A: s/pakcet/packet/ ---------------------------------------------------------------------- RESPONSE to Comment 22: ---------------------------------------------------------------------- Will be updated. ---------------------------------------------------------------------- COMMENT 23: ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- RESPONSE to Comment 23: ---------------------------------------------------------------------- We will add acknowledgements. 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 > 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/ > > > > ---------------------------------------------------------------------- > 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. > > > ---------------------------------------------------------------------- > 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. > > 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”? > > 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?) > > 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. > > 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? > > 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…”? > > 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”? > > 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. > > 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. > > 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. > > 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”. > > 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”. > > 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. > > 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. > > 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. > > 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? > > 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. > > 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. > > 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)? > > 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? > > 22. Appendix A: > > s/pakcet/packet/ > > 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. > > >
- [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