Ballot for draft-ietf-roll-aodv-rpl
Yes
No Objection
Abstain
No Record
Summary: Has enough positions to pass.
Alvaro Retana Yes
Erik Kline No Objection
[[ nits ]] [ section 4.1 ] * "sets its IPv6 address" could perhaps be something like "sets a selected IPv6 source address" [ section 4.3 ] * "r" is not depicted in Figure 3? Probably "X"? Or update Figure to match the field description.
Francesca Palombini No Objection
Thank you for the work on this document. I have some minor comments/questions below. Francesca 1. ----- Section 2. FP: Thank you for this very extensive (and useful) terminology section. I would suggest to add a sentence to say that the reader is expected to be familiar with RFC 6550 terminology. Alternatively, it might be good to add terms defined there and used in this document, such as DODAG and DODAGID, into this section as well. It also might improve readability to add references to documents when appropriate (for example, DIO could reference RFC 6550). 2. ----- to OrigNode. Intermediate routers join the Paired DODAGs based on the Rank as calculated from the DIO message. Henceforth in this FP: Please add a reference to where Rank is first defined, and/or add it to the terminology. 3. ----- Target Prefix / Address (variable-length field) An IPv6 destination address or prefix. The Prefix Length field contains the number of valid leading bits in the prefix. The length of the field is the least number of octets that can contain all of the bits of the Prefix, in other words Floor((7+(Prefix Length))/8) octets. The remaining bits in FP: "Floor((7+(Prefix Length))/8)" I am not sure where the "7+" comes from. Noting that the Prefix Length is 7-bit long, I am tempted to say that the number of octets calculated here also includes Prefix Length, however that is not clear from the sentence above ("The length of the field" - I assume the field refers to the Target Prefix / Address only). I think some clarification is necessary.
John Scudder (was Discuss) No Objection
Thanks for the discussion and updates, I'm clearing my discuss. I trust we'll separately come to a conclusion on the remaining topic Alvaro and I have been discussing in email. ---previous DISCUSS for posterity: 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. ---previous comments: (Note, added point 19.5.) I support Éric's DISCUSS. 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. 19.5 Section 6.3.2: (Adding one I missed earlier.) When a RREQ-DIO arrives at a TargNode with the S bit set to 0, the TargNode MUST build a DODAG in the RREP-Instance rooted at itself in order to discover the downstream route from the OrigNode to the TargNode. The RREP-DIO message MUST be re-transmitted via link-local multicast until the OrigNode is reached or MaxRank is exceeded. The As in comment 12, the use of the term "re-transmitted" is a little weird here. Do you mean TargNode sends the RREP-DIO again and again, as the text seems to say? (And as with some of my other comments, it's not obvious to me what interface(s) the link-local multicast takes place on.) 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.
Lars Eggert No Objection
Section 2, paragraph 1, comment: > 2. Terminology Is there some logic as to which terms are capitalized and which are not? (Also in the text.) ------------------------------------------------------------------------------- All comments below are very minor change suggestions that you may choose to incorporate in some way (or ignore), as you see fit. There is no need to let me know what you did with these suggestions. Section 4.1, paragraph 10, nit: > X > Reserved. Any recommendation what this should be set to on send? Section 4.2, paragraph 9, nit: > X > Reserved. Any recommendation what this should be set to on send? Section 4.2, paragraph 13, nit: > Rsv > MUST be initialized to zero and ignored upon reception. I guess these bits are reserved? Could you not just mark them X? Section 4.3, paragraph 6, nit: > Figure 3: ART Option format for AODV-RPL MOP X is missing from the description of the fields. Section 1, paragraph 4, nit: - functionality to support routes with birectional asymmetric links. + functionality to support routes with bidirectional asymmetric links. + ++ Section 5, paragraph 7, nit: - of cells used in 6tisch), a priori knowledge (e.g. link quality + of cells used in 6tisch), a priori knowledge (e.g., link quality + + Section 5, paragraph 7, nit: - for evaluating link state (see([RFC7548], [RFC7276], [co-ioam]) MAY - ^ + for evaluating link state (see [RFC7548], [RFC7276], [co-ioam]) MAY + ^ Section 6.2.1, paragraph 4, nit: - the downward (i.e. towards the TargNode) direction of the link + the downward (i.e., towards the TargNode) direction of the link + + Section 6.3.1, paragraph 2, nit: - symmetric route along which both directions satisfy the Objective - ------------ + symmetric route both of whose directions satisfy the Objective + +++++++++ Section 6.3.1, paragraph 2, nit: - routes (i.e. S=0). Selection between a qualified symmetric route - ^ + routes (i.e., S=0). Selection between a qualified symmetric route + ^
Murray Kucherawy No Objection
I concur with Roman's DISCUSS, especially around the use of SHOULD. I'd go further and ask why that's not a MUST, or in the alternative, suggest that you provide some guidance around why an implementer might legitimately decide against doing what the SHOULD says. I also support John's DISCUSS. The document shepherd writeup is more than two years old. In Section 2, although "AODV-RPL Instance" is defined, it is present nowhere in the document. Also "ART Option" doesn't seem to be ordered correctly. In Section 9, I suggest being clear that what you're actually updating are the named sub-registries of the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry.
Robert Wilton (was Discuss) No Objection
Roman Danyliw (was Discuss) No Objection
Thank you for addressing my DISCUSS and COMMENT feedback.
Warren Kumari No Objection
Firstly, thank you for writing this - I'm really not a ROLL person, but I found it interesting... I support John and Rob's DISCUSSes, but I'll let them carry the heavy load :-) I have a few nits: 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.' I could find no 'r' in Figure 3 - did you mean 'X'? Section 6.2.1, Step 1: '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.' I was unable to parse this. More worryingly, I was also not able to figure out what it should say... Section 6.3.1: 'default to 1/4 of the time duration determined by the L bit.' - s/L bit/L value'. This says that the default of 1/4 of the time duration, but I didn't see where /why the default would change. Also, isn't 'time' in 'time duration' unnecessary? Duration implies time. Appendix A: 'The combination of Received Signal Strength Indication(downstream) (RSSI) and Expected Number of Transmissions(upstream)" (ETX) ' -- this is a random closing quote without an opening one.
Éric Vyncke (was Discuss) No Objection
***Thank you for having addressed all my points raised during the IESG ballot of 2021-04-21 with the revised I-D*** (BTW, never hesitate to nudge an AD in the absence of action, I only reacted when processing my pending DISCUSS today :-( ... ) Thank you for the work put into this document. I seems that all cases have been thought of :-) Good job! and having a shorter path between two RPL nodes can be beneficial of course. Special thanks to Peter Van der Stock for the IoT directorate review: https://datatracker.ietf.org/doc/review-ietf-roll-aodv-rpl-10-iotdir-telechat-van-der-stok-2021-04-15/ Minor regret on the age of the document shepherd's write-up dated 2 years ago and about the -06 version. Little is said about the WG consensus. But, I am trusting the responsible AD on the consensus. I hope that this helps to improve the document, Regards, -éric == PREVIOUS DISCUSS (for archive) == A very trivial to fix but I do want to have a justification of using "point-to-point" (typically used over the two sides of a single link) vs. "peer-to-peer" (typically used over multiple links). Is it intentional by the ROLL WG ? Did I fail to understand the purpose of this document ? (quite possible of course!). I am afraid that many people will interpret the "point-to-point" like me. == PREVIOUS COMMENTS (for archive) == -- Section 4.3 -- Figure 3 has a 'X' while the text has a 'r' ;) Any reason why using "Floor((7+(Prefix Length))/8) octets" rather than the simple "Ceil(Prefix Length/8)" ? -- Section 6.1 -- "Each node maintains a sequence number" does it impact constrained nodes ?
Andrew Alston No Record
Martin Duke No Record
Paul Wouters No Record
Zaheduzzaman Sarker No Record
(Benjamin Kaduk; former steering group member) (was Discuss) Abstain
Thanks for the updates in -12 and -13, they're a big help for clarity and readability. I'm abstaining because I don't think this document should be published in its current form, but cannot supply a concrete path to changes that would make it suitable. (I believe that such a path exists, but I cannot provide a proof by construction.) I'm also concerned about the level of review this document has received, with multiple errors having gone uncaught until the IESG Evaluation stage. That said, I do have some additional comments to offer in the hope that they improve the document. Section 6.4.1 (RREP handling) directs the router's processing to proceed to §6.2.2 (RREQ handling), which seems like an unfortunate copy/paste error. I continue to believe that it would be very helpful to depict the 'S bit' information associated with an RREQ-Instance as a tristate rather than a single bit. In essence, this state reflects the contract between adjacent nodes about how to process the corresponding RREP-DIO, but a given (intermediate) router needs to know what contract to use both when processing an incoming RREP-DIO and when emitting an RREP-DIOO (indeed, even to know whether to emit unicast or multicast), and it's hard to see how a single bit could cover both incoming and outgoing RREP-DIOs at the point of transition. A few other section-by-section notes follow. Section 4.1 L 2-bit unsigned integer determining the length of time that a node is able to belong to the RREQ-Instance (a temporary DAG including the OrigNode and the TargNode). Once the time is reached, a node MUST leave the RREQ-Instance and stop sending or receiving any more DIOs for the RREQ-Instance. This naturally depends on the node's ability to keep track of time. Once a node leaves an RREQ- Instance, it MUST NOT rejoin the same RREQ-Instance. L is independent from the route lifetime, which is defined in the DODAG configuration option. I assume that this "MUST NOT rejoin" would have some timeframe associated with it (at least for L != 0x00), since the instance-id could eventually be reused for a different logical instance. Section 4.2 L 2-bit unsigned integer defined as in RREQ option. The lifetime of the RREP-Instance MUST be shorter than the lifetime of the RREQ- Instance to which it is paired. Strictly shorter, or "less than or equal to"? I think, given the limited options, strictly shorter would be pretty disruptive. Section 6.2.4 Suppose a router has joined the RREQ-Instance, and H=0, and the S-bit of the RREQ-Instance is set to 1. In this case, the router MAY optionally associate to the RREQ-Instance, the Address Vector of the symmetric route back to OrigNode. This is useful if the router later receives an RREP-DIO that is paired with the RREQ. I think we should say what happens if I don't do what the MAY says. Do we just fail to find a route entirely, or only with degraded performance, or ...? Section 6.4.2 The router updates its stored value of the TargNode's sequence number according to the value provided in the ART option. The router next checks if one of its addresses is included in the ART Option. If so, this router is the OrigNode of the route discovery. [...] This seems to set up a scenario where TargNode learns about its own sequence number updates by processing the ART Option, which is rather amusing to think about :) NITS Section 6.1 RPLInstance and a DODAG rooted at itself. Then it transmits a DIO message containing exactly one RREQ option (see Section 4.1) to multicast group all-RPL-nodes. The DIO MUST contain at least one ART "the multicast group".