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

["Pascal Thubert (pthubert)" <[e-mail]>]

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