Re: [Roll] Review of draft-ietf-roll-aodv-rpl-13

[Charles Perkins <[e-mail]>]

Hello Pascal,

Thanks for your many helpful observations and suggestions.



On 3/17/2022 7:56 AM, Pascal Thubert (pthubert) wrote:
 > Dear authors and all;
 >
 > Please find my comments on draft-ietf-roll-aodv-rpl-13 below:
        ...........
 > ------------------------------------------------------------------------
 >
 >                                            " Consequently, for traffic
 >     between routers within the DODAG (i.e., Peer-to-Peer (P2P) traffic)
 >     data packets either have to traverse the root in non-storing mode, or
 >     traverse a common ancestor in storing mode."
 >
 > => Suggest to add references to RFC 6687 for the route stretch and to 
RFC 9010 for the detailed impacts.

Will do.  Thanks for the suggestion.

 >
 > ------------------------------------------------------------------------
 >
 >                The on-demand nature of AODV
 >     route discovery is natural for the needs of peer-to-peer routing in
 >     RPL-based LLNs.
 >
 > => because ? "natural" lacks substanciation. One could argue the 
exact same for projected DAO, and all the DetNet / RAW work would 
support it. I'd remove that sentence. Instead, it would be nice to 
qualify the properties of on demand that fits which needs so we can 
derive applicability.
 >
 >     I'd say that all RPL variations have in common that they avoid 
building optimized routes between every all pairs of nodes, to save 
constrained resources and control protocol exchanges. On-demand enables 
an optimization for specific pairs where a larger main RPL DODAG will 
allow stretched but any-to-any connectivity.



On demand is better when routes are needed but aren't yet established.
Peer-to-peer routing is better when shorter routes are desired and 
especially
when it is desired to avoid heavier traffic through a root or gateway 
node of
the network. This seems natural to me.  However, some peer-to-peer routing
should be done proactively, and so the sentence needs work.  Thanks for
pointing this out.



 > ------------------------------------------------------------------------
 >
 >     " AODV-RPL can be operated whether or not P2P-RPL or native RPL 
is running otherwise."
 >
 >     I do not believe that is generally true, please remove the text. 
MOP 4 in DIOs could create a confusion between the reactive methods and  
a P2P RPL implementation will not recognize the RREQ option and may 
process the DIO or enter an error state.

 >From RFC 6550:

[A] As per 6.7.1 " RPL Control Message Option Generic Format" of RFC6550,

    "When processing a RPL message containing an option for which the
     Option Type value is not recognized by the receiver, the receiver
     MUST silently ignore the unrecognized option and continue to process
     the following option, correctly handling any remaining options in the
     message."

The above clause causes DIO message to be processed by any other reactive
protocol (e.g., P2P-RPL) that uses MOP 4 even if it does not understand the
RREQ option.  Since the DIO message is not dropped but the AODV option 
is not
processed, I don't know how to predict the behavior if more than one P2P
protocol with same MOP operate in the network.

In order to remove the possible ambiguity when other protocols are using the
same MOP, and as you suggest below, I agree that AODV-RPL should use a 
new multicast group.


 > ------------------------------------------------------------------------
 >
 >     " For many networks AODV-RPL could be a
 >     replacement for RPL, since it can find better routes at very moderate
 >     extra cost.  Consequently, it is unlikely that RPL would be needed in
 >     a network that is running AODV-RPL, even though it would be possible
 >     to run both protocols at the same time."
 >
 > => "better" is unsubstanciated.

Better because shorter paths, etc.

 > I suggest to remove that text altogether. I believe that it suffices 
to say what I pointed above, that RPL and AODV RPL must be operated in 
different instances, which is unavoidablme since they are running with 
different MOPs, so they just cannot interfere. Which one is used is a 
policy decision, out of scope.

Do you think there are times when RPL discovers better routes than AODV-RPL?


 > -------------------------------------------------------------------------
 >
 > "
 >
 >     DIO
 >        DODAG Information Object
 > "
 >
 > => Remove, this is already defined in RFC 6550

How about adding "(as defined in RFC6550)"?  There ought to be
something to help the reader.

 >
 > -----------------------------------------------------------------------
 >
 > "
 >     Source routing
 >        A mechanism by which the source supplies the complete route
 >        towards the target node along with each data packet [RFC6550]
 > "
 >
 > => if it is "complete" then this is *strict* source routing.

Maybe complete isn't best.  We can just say "supplies a vector of 
addresses".

 > ------------------------------------------------------------------------
 >
 > "
 > OrigNode selects one of its IPv6 addresses and sets it in the DODAGID
 >     field of the RREQ-DIO message.
 > "
 >
 > =>The address scope must encompass the domain where the route is 
built. E.G, not link-local.

That is a good point, thanks!


 > ------------------------------------------------------------------------
 >
 > "
 >    H
 >        Set to one for a hop-by-hop route
 > "
 >
 > => In the RPL culture we call that Storing Mode (I did not choose 
that term!!!). Source route is Non-Storing Mode.
 >    Ideally we'd align terminology. Alse, it should at least be 
indicated in the terminology and the introduction.

O.K.  A new Terminology item is a good idea.


 > ------------------------------------------------------------------------
 >
 >
 > "   L
 >        2-bit unsigned integer determining the length of time that a node
 >        is able to belong to the RREQ-Instance
 > "
 >   length of time => duration?

O.K.


 >   Also, 256 s might be very short for energy scavenging devices.
 >
 >   Could that be based on the " Lifetime Unit " in 
https://www.rfc-editor.org/rfc/rfc6550.html#section-6.7.6  so 
deployments could use very different ranges?

That's a lot more bits.  It seems like a pretty big change at this point 
of time during Last Call.  We could instead define a new Option to 
override the L field value in the Option header.  Would that suffice?  
Maybe it should be done later after the base document is published.


 > ------------------------------------------------------------------------
 >
 >    "In Figure 4 and Figure 5, BR is the Border Router, O is
 >     the OrigNode, "
 >
 > => This seems to indicate that there's a need for a main RPL 
instance. But the text clearly said it is not the case.
 > So maybe indicate that this is an example where you have connectivity 
to the outside (which is not needed) and a main RPL Instance rooted at 
the BR (which is not needed either).

We could change it so that BR has a different name, or we could make it 
clear that the use of BR is for illustrative purposes only and not 
necessary to run AODV-RPL.

 > ------------------------------------------------------------------------
 >
 > " criteria used
 >     when determining whether or not each link is symmetric. "
 >
 > => maybe mention DLEP ? No pressure

The criteria used do not have to conform to any standardized protocol.


 > ------------------------------------------------------------------------
 >
 > "
 > Figure 5:
 > "
 > => The propagation of both DIOs appears to be along a sequence of 
nodes though it is really flooded in a Rank Diameter around O. I believe 
it is worth explaining. Also, what happens when the S flag arrives at T 
with both flavors?

The evaluation of the rank seems preferable for picking among several
possible routes, not the setting of the S bit.


 > ------------------------------------------------------------------------
 >
 > "to multicast group all-RPL-nodes".
 >
 > => could we have a all-AODV-RPL-nodes group? The all-RPL-nodes is for 
normal DIOs.

Agreed.


 > ------------------------------------------------------------------------
 >
 > "The address in the ART Option can be a unicast IPv6 address or a"
 >
 > =>  The Target Prefix / Address in the ART option ...

Will do.


 > ------------------------------------------------------------------------
 >
 > Section 6.2.1 is pseudo code with no indentation.

This is the first time I can remember having such a paragraph described 
as pseudo code.


 >   This results in ambiguity. For instance,
 >
 >
 > "
 > The upstream neighbor router
 >     that transmitted the received RREQ-DIO is selected as the preferred
 >     parent.
 > "
 >
 > This is true only in the case where the received DIO is the best.

A previous sentence specifies "... the following steps are not processed."

Perhaps a new paragraph after that statement would clarify so that the 
intended meaning is more evident.


 > ------------------------------------------------------------------------
 >
 > Section 6.2.2 :
 > "
 > After determining that a received RREQ provides a usable route
 > "
 >
 > Does that determination impact the operation of this section? What if 
S=0?

If S=0, the determination of Target Node status and determination of a 
usable route to OrigNode is still the same.


 > ------------------------------------------------------------------------
 >
 > Section 6.2.3 :
 >
 > "
 > then the router MUST build or update its upward route
 >     entry towards OrigNode,
 > "
 >
 > Even if S=0 ? Even if not the newest sequence? Even if RREQ not from 
preferred parent to orig?
 > Suggest to list all the checks first and then if OK the action. Here 
the last sentence is only one of the checks and appears too late to 
follow the logic.

That would seem to duplicate specification text in previous sections.  
Usually
such duplication is a bad idea, because duplication of text leads to errors
when one of the duplicated texts is edited but the other is not.

Even for S=0, the RREQ advertises a route to OrigNode.  If the RREQ is 
not from a preferred parent, it should not be propagated.  If the RREQ 
is not the newest sequence it should not be propagated.  These are all 
specified earlier.

There are too many things in the preceding sections of the document to 
repeat
them here.


 > ------------------------------------------------------------------------
 >
 > Section 6.2.5 :
 >
 > What if the interface up is not the interface down, and the addresses are
 > different? The result is that the address list is not reversible. In
 > particular, in the case where S = 1?

In this case, the route is not symmetric and S = 0.

Each radio interface/link and the associated address should be treated s an
independent intermediate router.  The two routers have different links and
the rules for the link symmetry apply independently for each of these.


 > ------------------------------------------------------------------------
 >
 > Section 6.2.5 :
 >
 > "
 >     If the router is a TargNode and was already associated with the RREQ-
 >     Instance, it takes no further action and does not send an RREP-DIO
 > "
 > In 6.3.1 it says
 > "
 >     For a symmetric route, the RREP-DIO message is unicast to the next
 >     hop according to the Address Vector (H=0) or the route entry (H=1);
 > "
 >
 > This means that if an RREP-DIO was sent on a bad path received fast, 
it will not be updated when a better path shows?

The RREP advertises a route to TargNode.  If the TargNode already sent 
an RREP, and then receives a better RREQ, it does not have to re-send 
the RREP.


 > ------------------------------------------------------------------------
 >
 > Section 6.3.3 :
 >
 > This all idea of delta is complicated. Why not just place in that 
field the RPL instance ID of the RREQ instance? It's also 6 bits since 
it is a local RPL Instance ID.

Delta is needed to associate the RREQ_InstanceID to the RREP_InstanceID.  It
is possible that TargNode might have used OrigNode's choice of 
RPLInstanceID for
some other unrelated route discovery.  It is even possible that OrigNode's
choice of RPLInstanceID was previously used by TargNode for a route 
discovery
for OrigNode with a different OF.  Using Delta to effect the association is
a good technique which is very simple to manage.


 > ------------------------------------------------------------------------
 >
 > Section 6.4.1 :
 > "
 > The router that
 >     transmitted the received RREP-DIO is selected as the preferred
 >     parent.  Afterwards, other RREP-DIO messages can be received.
 > "
 >
 > What if more than one RREP-DIO are received?

This just means that the receiving node is getting multiple 
advertisements for
routes to TargNode.   In such a case the router might already be in the 
DODAG.
AODV-RPL does not specify any action to be taken in such cases.


 > ------------------------------------------------------------------------
 > Section 6.4.4 :
 > "
 > If H=0, the
 >     intermediate router MUST include the address of the interface
 >     receiving the RREP-DIO into the address vector.
 > "
 >
 > Same as the other direction. The address on the receive interface of 
the RREQ-DIO may not be visible on the interface from which traffic to 
target is received. It would make sense to place the address of the 
previous hop from which the RREP-DIO is received.

If a node transmits a RREQ over an interface which is different than the
interface from which it was received, both interface addresses should be in
the address vector.


 > ------------------------------------------------------------------------
 > Section 7
 >
 > "
 > an Intermediate router that receives a RREQ-DIO
 >     message MAY transmit a "Gratuitous" RREP-DIO message
 > "
 >
 > How does it select the RPL Instance ID? I believe only the target can 
do that so only the target should send the RREP-DIO

Regardless of TargNode's choice of RREP_InstanceID and Delta, an 
intermediate
node can unambiguously identify the DODAG by using RREQ_InstanceID in the
returned Gratuitous unicast RREP to OrigNode.  Then, when the intermediate
node later receives TargNode's unicast RREP, the intermediate node will be
able to make the association between RREQ_InstanceID and RREP_InstanceID.

Naturally Yours,
Charlie P.




Naturally Yours,
Charlie P.

============================ Original email follows ======================


On 3/17/2022 7:56 AM, Pascal Thubert (pthubert) wrote:
> Dear authors and all;
>
> Please find my comments on draft-ietf-roll-aodv-rpl-13 below:
>
> Bottom line is that we're not there yet. I believe a number of mechanism are either underspecified or broken as described, e.g., the way a source route is constructed does not seem to work for nodes with different interfaces up and down.
>
> ------------------------------------------------------------------------------------------------
>
>                                            " Consequently, for traffic
>     between routers within the DODAG (i.e., Peer-to-Peer (P2P) traffic)
>     data packets either have to traverse the root in non-storing mode, or
>     traverse a common ancestor in storing mode."
>
> => Suggest to add references to RFC 6687 for the route stretch and to RFC 9010 for the detailed impacts.
>
> ------------------------------------------------------------------------------------------------
>
>                The on-demand nature of AODV
>     route discovery is natural for the needs of peer-to-peer routing in
>     RPL-based LLNs.
>
> => because ? "natural" lacks substanciation. One could argue the exact same for projected DAO, and all the DetNet / RAW work would support it. I'd remove that sentence. Instead, it would be nice to qualify the properties of on demand that fits which needs so we can derive applicability.
>
>     I'd say that all RPL variations have in common that they avoid building optimized routes between every all pairs of nodes, to save constrained resources and control protocol exchanges. On-demand enables an optimization for specific pairs where a larger main RPL DODAG will allow stretched but any-to-any connectivity.
>
> ------------------------------------------------------------------------------------------------
>
>     " AODV-RPL can be operated whether or not P2P-RPL or native RPL is running otherwise."
>
>     I do not believe that is generally true, please remove the text. MOP 4 in DIOs could create a confusion between the reactive methods and  a P2P RPL implementation will not recognize the RREQ option and may process the DIO or enter an error state. But it does not matter. I'd indicate that if ever RPL, P2P RPL, and/or AODV RPL run between the same nodes (so unlikely!) then they operate as different RPL instances anyway (since " the OrigNode builds a local RPLInstance and a DODAG rooted at itself."). Instances do not mix, by definition.
> 	
> ------------------------------------------------------------------------------------------------
>
>     " For many networks AODV-RPL could be a
>     replacement for RPL, since it can find better routes at very moderate
>     extra cost.  Consequently, it is unlikely that RPL would be needed in
>     a network that is running AODV-RPL, even though it would be possible
>     to run both protocols at the same time."
>
> => "better" is unsubstanciated.
>
> I suggest to remove that text altogether. I believe that it suffices to say what I pointed above, that RPL and AODV RPL must be operated in different instances, which is unavoidablme since they are running with different MOPs, so they just cannot interfere. Which one is used is a policy decision, out of scope.
>
>
> ------------------------------------------------------------------------------------------------
>
> "
>
>     DIO
>        DODAG Information Object
> "
>
> => Remove, this is already defined in RFC 6550
>
> ------------------------------------------------------------------------------------------------
>
> "
>     Source routing
>        A mechanism by which the source supplies the complete route
>        towards the target node along with each data packet [RFC6550]
> "
>
> => if it is "complete" then this is *strict* source routing.
>
>
> ------------------------------------------------------------------------------------------------
>
> "
> OrigNode selects one of its IPv6 addresses and sets it in the DODAGID
>     field of the RREQ-DIO message.
> "
>
> =>The address scope must encompass the domain where the route is built. E.G, not link-local.
>
> ------------------------------------------------------------------------------------------------
>
> "
>    H
>        Set to one for a hop-by-hop route
> "
>
> => In the RPL culture we call that Storing Mode (I did not choose that term!!!). Source route is Non-Storing Mode.
>    Ideally we'd align terminology. Alse, it should at least be indicated in the terminology and the introduction.
>
>
> ------------------------------------------------------------------------------------------------
>
>
>
> "   L
>        2-bit unsigned integer determining the length of time that a node
>        is able to belong to the RREQ-Instance
> "
>   length of time => duration?
>
>   Also, 256 s might be very short for energy scavenging devices.
>
>   Could that be based on the " Lifetime Unit " in https://www.rfc-editor.org/rfc/rfc6550.html#section-6.7.6  so deployments could use very different ranges?
>
> ------------------------------------------------------------------------------------------------
>
>    "In Figure 4 and Figure 5, BR is the Border Router, O is
>     the OrigNode, "
>
> => This seems to indicate that there's a need for a main RPL instance. But the text clearly said it is not the case.
> So maybe indicate that this is an example where you have connectivity to the outside (which is not needed) and a main RPL Instance rooted at the BR (which is not needed either).
>
>
>
>
> ------------------------------------------------------------------------------------------------
>
> " criteria used
>     when determining whether or not each link is symmetric. "
>
> => maybe mention DLEP ? No pressure
>
> ------------------------------------------------------------------------------------------------
>
> "
> Figure 5:
> "
> => The propagation of both DIOs appears to be along a sequence of nodes though it is really flooded in a Rank Diameter around O. I believe it is worth explaining. Also, what happens when the S flag arrives at T with both flavors?
>
>
> ------------------------------------------------------------------------------------------------
>
> "to multicast group all-RPL-nodes".
>
> => could we have a all-AODV-RPL-nodes group? The all-RPL-nodes is for normal DIOs.
>
>
>
> ------------------------------------------------------------------------------------------------
>
> "The address in the ART Option can be a unicast IPv6 address or a"
>
> =>  The Target Prefix / Address in the ART option ...
>
> ------------------------------------------------------------------------------------------------
>
> Section 6.2.1 is pseudo code with no indentation. This results in ambiguity. For instance,
>
>
> "
> The upstream neighbor router
>     that transmitted the received RREQ-DIO is selected as the preferred
>     parent.
> "
>
> This is true only in the case where the received DIO is the best.
>
> ------------------------------------------------------------------------------------------------
>
> Section 6.2.2 :
> "
> After determining that a received RREQ provides a usable route
> "
>
> Does that determination impact the operation of this section? What if S=0?
>
>
> ------------------------------------------------------------------------------------------------
>
> Section 6.2.3 :
>
> "
> then the router MUST build or update its upward route
>     entry towards OrigNode,
> "
>
> Even if S=0 ? Even if not the newest sequence? Even if RREQ not from preferred parent to orig?
> Suggest to list all the checks first and then if OK the action. Here the last sentence is only one of the checks and appears too late to follow the logic.
>
> ------------------------------------------------------------------------------------------------
>
> Section 6.2.5 :
>
> What is the interface up is not the interface down, and the addresses are different?
> The result is that the address list is not reversible. In particular, in the case where S = 1?
>
> ------------------------------------------------------------------------------------------------
>
> Section 6.2.5 :
>
> "
>     If the router is a TargNode and was already associated with the RREQ-
>     Instance, it takes no further action and does not send an RREP-DIO
> "
> In 6.3.1 it says
> "
>     For a symmetric route, the RREP-DIO message is unicast to the next
>     hop according to the Address Vector (H=0) or the route entry (H=1);
> "
>
> This means that if an RREP-DIO was sent on a bad path received fast, it will not be updated when a better path shows?
>
> ------------------------------------------------------------------------------------------------
>
> Section 6.3.3 :
>
> This all idea of delta is complicated. Why not just place in that field the RPL instance ID of the RREQ instance? It's also 6 bits since it is a local RPL Instance ID.
>
>
> ------------------------------------------------------------------------------------------------
>
> Section 6.4.1 :
> "
> The router that
>     transmitted the received RREP-DIO is selected as the preferred
>     parent.  Afterwards, other RREP-DIO messages can be received.
> "
>
> What if more than one RREP-DIO are received?
>
> ------------------------------------------------------------------------------------------------
> Section 6.4.4 :
> "
> If H=0, the
>     intermediate router MUST include the address of the interface
>     receiving the RREP-DIO into the address vector.
> "
>
> Same as the other direction. The address on the receive interface of the RREQ-DIO may not be visible on the interface from which traffic to target is received. It would make sense to place the address of the previous hop from which the RREP-DIO is received.
>
> ------------------------------------------------------------------------------------------------
> Section 7
>
> "
> an Intermediate router that receives a RREQ-DIO
>     message MAY transmit a "Gratuitous" RREP-DIO message
> "
>
> How does it select the RPL Instance ID? I believe only the target can do that so only the target should send the RREP-DIO
>
>
> ------------------------------------------------------------------------------------------------
> Keep safe,
>
> Pascal
>