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

[John Scudder <[e-mail]>]

Hi Charlie,

Thanks for your reply and I apologize in turn for my own delay. My comments below.  

> On May 6, 2021, at 9:58 PM, Charlie Perkins <[e-mail]> 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:

[…]

>> ----------------------------------------------------------------------
>> 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].

That works, I’ll clear the discuss when you push out your next version.

>> ----------------------------------------------------------------------
>> 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.

That works for me.

> If there is an official list of terms to search for please let us know.

It’s not quite an “official list of terms to search for” but we do now have a statement on this, https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/

FWIW during my review I didn’t notice anything else that seemed like it needed to be addressed.

>> 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.

It’s probably worth saying this explicitly.

>> 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.

The latter wording is fine. I pointed out that 6550 already says this because presumably you don’t need to re-specify what’s already been specified there. If it’s just there for narrative clarity, that’s fine of course.

>> 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.

OK.

>> 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.

Presumably to receive the same change.

>> 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.

So “… represents IPv6 addresses of the path through the network the RREP-DIO has traversed.” Check.

[…]

>> 
>> 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.

That’s clear. Thanks.

>> 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.

Although this is clear enough in context, I suggest spending just a few more words on it: “… if the S bit in the received RREQ-DIO is set to 0, the router MUST determine whether the upward direction (towards the OrigNode) of the link satisfies the Objective Function."

I don’t insist but this wouldn’t have tripped me up the way the other text did.

>> 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.

OK. I guess there will be text forthcoming for this.

>> 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.

OK. Possibly something like “… before re-sending the RREQ-DIO according to Section X.Y.Z” might work?

>> 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.

Clearer, thanks.

>> 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?

Seems better than letting implementors take their best guess at it.

>> 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.

OK. Again, I assume there will be text forthcoming.

>> 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"

Probably make that substitution then. But isn’t this potentially true in anything other than a small lab? (And some of you probably think I’m being naïve for thinking none of my lab routers are rooted.)

[…]

Regards,

—John