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

[John Scudder <[e-mail]>]

Hi Alvaro,

After our call I feel like we’ve made progress but there are still some things I’d like to finish hashing out.

> On Apr 20, 2021, at 10:55 AM, Alvaro Retana <[e-mail]> wrote:
> 
> On April 19, 2021 at 4:32:03 PM, John Scudder wrote:
> 
> 
> John:
> 
> Hi!  Thanks for the review!
> 
> I'm just replying to your DISCUSS -- I will let the authors address
> the rest of the comments.
> 
> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
> ...
>> 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.
> 
> AODV-RPL is an extension of RPL -- the same types of networks that RPL
> targets are appropriate for AODV-RPL.  The one differentiator is the
> ability of AODV-RPL to discover p2p routes that may not need to
> traverse the root (more below).  IOW, networks that have significant
> p2p traffic would benefit the most.

As we discussed on our call, I think the “expected network environment” thing was largely a red herring I was led to by imprecision in the use of “multicast”, see for example my comment #15. I think we can consider the “network environment” point put to rest.

>> 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.
> 
> Now that I look at the figures again, I can see how they might look
> like a segment of a traditional access-distribution-core network. :-)
> 
> RPL forms a Destination-Oriented Directed Acyclic Graph (DODAG), which
> results in a tree-like structure with a Border Router (BR) at the top.
> In general, instead of access-distribution-core, the whole RPL
> instance is made up of leaves-transit routers-border router.  In some
> cases the leaves are RPL-aware, but not always.

A key observation is that the figure depicts a control plane topology, not a physical topology, right?

>> 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.
> 
> AODV-RPL uses a new Mode of Operation (MOP) dedicated to the discovery
> of p2p routes.  This means that it runs in a separate instance from
> the "base RPL".  Also, it can be used whether or not a "base RPL"
> instance is used.  IOW, it is RPL using MOP 5.

The use of the term “base RPL”, or “native RPL” as the introduction calls it, is problematic, if I’ve understood you right. It’s a case of “the exception that proves the rule”, i.e. by referencing “native RPL” that implies the AODV-RPL is *not* RPL, which is a contradiction to what you’ve written above and explained to me.

So I think some work on that language is in order.

> Most of what I wrote above, which I hope helps clarify, is in the
> Introduction (pasted below).  I think that the text could have been a
> little more explicit in tying p2p traffic to AODV-RPL -- everything
> else seems to be there.  Yes, there is a strong assumption that the
> reader knows RPL.
> 
> Do you have specific suggestion on what can be added to the Introduction?

See below.

> Thanks!
> 
> Alvaro.
> 
> 
> 
> 
> 1.  Introduction
> 
>   RPL (Routing Protocol for Low-Power and Lossy Networks) [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 route discovery process in AODV-RPL is modeled on the analogous
>   procedure specified in AODV [RFC3561].  The on-demand nature of AODV
>   route discovery is natural for the needs of peer-to-peer routing in
>   RPL-based LLNs.  AODV terminology has been adapted for use with AODV-
>   RPL messages, namely RREQ for Route Request, and RREP for Route
>   Reply.  AODV-RPL currently omits some features compared to AODV -- in
>   particular, flagging Route Errors, blacklisting unidirectional links,
>   multihoming, and handling unnumbered interfaces.
> 
>   AODV-RPL reuses and provides a natural extension to the core RPL
>   functionality to support routes with birectional asymmetric links.
>   It retains RPL's DODAG formation, RPL Instance and the associated
>   Objective Function (defined in [RFC6551]), trickle timers, and
>   support for storing and non-storing modes.  AODV adds basic messages
>   RREQ and RREP as part of RPL DIO (DODAG Information Object) control
>   messages, and does not utilize the Destination Advertisement Object
>   (DAO) message of RPL.  AODV-RPL specifies a new MOP (Mode of
>   Operation) running in a separate instance dedicated to discover P2P
>   routes, which may differ from the point-to-multipoint routes
>   discoverable by native RPL.  AODV-RPL can be operated whether or not
>   native RPL is running otherwise.

The final paragraph is the one that led me astray. Is this rewrite on target?

AODV-RPL is a new RPL Mode of Operation (MOP) that extends RFC 6550 to support routes with bidirectional asymmetric links. It makes use of RFC 6550’s DODAG formation, RPL Instance, and the associated Objective Function (defined in [rfc6551]), trickle timers, and support for storing and non-storing modes. AODV-RPL adds basic messages RREQ and RREP as part of the RPL DIO (DODAG Information Object) control messages, and does not utilize the Destination Advertisement Object (DAO). The AODV-RPL MOP runs in a separate instance dedicated to discovering P2P [*] routes, which may differ from the point-to-multipoint routes discoverable by RPL’s other modes of operation. AODV-RPL can be operated whether or not other RPL modes of operation are running otherwise.

[*] Although, I do agree with Éric’s DISCUSS about use of this terminology. I understand from Alvaro that it’s water under the bridge, but some kind of warning to the unwary traveler is in order: ‘hey, be aware we use “p2p" in a way you may find unusual!’

Thanks,

—John