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

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

Hello Charlie

I hope you're doing well, it's been a while.

In the below I skipped the things for which you agreed directly and used WFM to accept your proposals:

> Thanks for your many helpful observations and suggestions.

:) 


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

I'm sure you saw that I did not mention it for the sake of a chat but with the hope that you'd place such text as this exchange in the document 😊
This would certainly help a rpl-junior reader.


> 
>> ------------------------------------------------------------------------
>>      " AODV-RPL can be operated whether or not P2P-RPL or native RPL is
> running otherwise."
> 
> 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.

And that we MUST a specific instance ID so it operates as ship in the night.

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

Yes. It's hard to qualify shortest or best in radios. Depends on what you care for, and things keep changing anyway.
When the "shortest" paths are busy and dropping packets (including RR), it might be that a reactive protocol finds a "longer path".
This is the sort of things that the reader should understand to position the usability of the protocol. It is distributed, autonomic, but provides no optimality guarantees. The best option for a demanding application is probably to max out the Rank Diameter that the RR probe can reach, to avoid using a path that is not usable by the application. 

In contrast, a real optimization requires a global view of all flows. This is what a PCE does in TE space, and this is why we have DAO projection in RPL.

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

When DAO projection is implemented. Applications like industrial automation require full control and visibility, e.g., which path is used by which flow. They'll want to dispatch the flows to optimize globally the latency and reliability. They'll do DetNet PREOF / RAW PAREO things. The cost is significant - a controller -, but for them the routes that can guarantee no link or node congruence, time and space diversity, max latency, global load balancing, etc... are indeed "better". 

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

WFM

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

WFM

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

WFM


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

WFM


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

WFM

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

Good to clarify that I the text.



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

OK I was unclear. I mean that the text has a lot of logical steps, but is unclear what and otherwise is for there are multiple steps and conditions before.
In the end it looks like a python code that would not have been indented and it could be misunderstood. I'm asking to ensure that it can be read and coded without ambiguity. The form is yours to choose.


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

This is an example of what I'm asking above, yes.

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

Better safe than sorry. Please add the words.

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

the position of the reader, I need to find the full story at one and not scattered. I agree that the normative text must not be duplicated. You're better at this game than I am.


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

Maybe think of it as a function. Detail the common steps above in a section and then refer to it everywhere you need. As is, I, as a reader, was confused.

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

Please add clarifying text in the spec.

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

Which means that a "bad path" will be used if the RREQ was received first? 
Note that latency might not be the criteria to optimize for. 
E.g., a more reliable path may be slower / more hops.


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

I did not challenge the idea, just the use of a new field

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

But then, what is the developer to do? Select the best one? Ignore ? keep some, or them all, for NECMP? do what he likes?


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

I did not read that in the spec. Did I miss it?
Optimization question: Is that useful, e.g., in non-symmetrical paths?
In traditional RPL, the (source) route only indicates to the previous hop the address of the next hop that it can see. 

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

This is assuming that there is a RREP Instance ID, meaning that the RREQ reaches the Target.

I guess that my confusion is that I thought that the Intermediate routers absorbs the RREQ, so we do not look for the rest of the path.
Apparently, the Intermediate router that does the gratuitous thingy still must pass the RREQ on. If it does, then the gratuitous thing is useless till the RREP from Target comes in. But then if so, what's the use of the gratuitous? 

Charlie, I'm sorry if I missed something that is already explained; but if not, please clarify.

Keep safe;

Pascal


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