Re: [Roll] Rtgdir last call review of draft-ietf-roll-aodv-rpl-16

[Charles Perkins <[e-mail]>]

Hello Tony (and Luc André),

Many thanks for your careful review.  Please find our follow-up comments 
interspersed below.

On 4/2/2023 5:11 PM, Luc André Burdet via Datatracker wrote:
> Generally, introduction section would benefit from 1-2 figures showing the
> flows of RREQ etc. with flags resulting for symmetric/assymetric case and
> collisions/multiple downstream RREQ sends & such anomalous cases.

We made some more diagrams showing some message flows, but it seemed 
more appropriate to put them in an appendix.

> _Heavy_ readability suggestions:
>
> * Terminology
>
>     ** "The RPLInstanceID in the RREP message along with the Delta value
>     indicates the associated RREQ-InstanceID." is heavily cryptic and leaves one
>     guessing whether the Orig & Trg RPL Instance IDs are related somehow to
>     'pair' ? It becomes clear later but either explain in terminology or just
>     say that both InstanceIDs are matched by mechanism explained in "section
>     6.3.3" to correlate them (or define the term "pair" precisely in
>     terminology).

Yes, the point is to enable the two instance IDs to be associated. I 
added the suggested cross-reference to section 6.3.3.  I don't think a 
new terminology item is needed for this.

>
> * section 3: "the proper OF" "with 'D' == 0" is _heavily_ cryptic until one
> -really- knows 6550 intimately. Expand the acronym, flag semantics

I modified the text as follows:

                                          The 'D' bit of the 
RPLInstanceID field is set to
                 0 to indicate that the source address of the IPv6 
packet is the
                 DODAGID.


>
> * "The route discovery process is initiated when an application at the OrigNode
> has data to be transmitted to the TargNode, but does not have a route that
> satisfies the Objective Function for the target of the application's data." How
> is taht possible if e.g. a global grounded DAG that can reach the destination
> is already in place which would be kind of default 6550 behavior?

The route from the global grounded DAG might not satisfy the needed OF 
between OrigNode and TargNode as discoverable via AODV-RPL.  For 
example, AODV-RPL may often find a more direct route, or a route with 
reduced cost that does not traverse the root node.

>
> Readability suggestions:
>
> * include RRPE and RREQ in terminology for easier reading. yes, it's in intro &
> it's really ROLL but nevertheless, I had to go and search for it.

Done.

>
> * "This reduces the cost to building only one DODAG." Not clear what that
> means. I think it's "with that the node can build one DODAG for multiple
> targets" ?

Yes, that's right.  We've inserted the suggested clarification.

>
> * "The upstream neighbor router that transmitted the received RREQ-DIO is
> selected as the preferred parent." would benefit from clarifying that it's
> parent only for this DAG

Done.

>
> Robusntess/Correctness suggestions:
>
> * 'H' flag is redundant as information (either vector is there or not and that
> basically indicates H). This will lead to semantically unclear packets. In case
> H is set but a vector is sent what to do? what is semantic of H not set and no
> vector?

The H flag essentially signifies whether or not the address vector field 
is present.  If it is set incorrectly, the message fields will likely be 
misinterpreted.  I don't know of a straightforward way to detect whether 
or not the H flag is set incorrectly.

>
> * L: 2-bit unsigned integer defined as in RREQ option. The lifetime of the
> RREP-Instance MUST be no greater than the lifetime of the RREQ-Instance to
> which it is paired.   and what if not?


We added language to the draft explaining that, otherwise, resources 
(e.g., memory) that could be released will remain unavailable. Since 
consuming extra resources might not be fatal, the "MUST" was reduced to 
"SHOULD".

>
> * Logic behind Intersection instaed of union in section 6.2.2 is a mystery. Why
> not only take the newest RREQ based on sequence etc ... Is it because 2 routers
> can receive 2 RREQ on all-AODV-RPL-nodes in different sequence and the result
> should be same no matter the order?


When two or more RREQs are received with the same Orig SeqNo, they were 
transmitted by OrigNode with the same destinations and OF. When an 
intermediate node receives two RREQs with the same Orig SeqNo but 
different lists of destinations, that means that some intermediate nodes 
retransmitting the RREQs have already deleted themselves from the list 
of destinations before they retransmitted the RREQ.  We don't want to 
re-insert those deleted nodes back into the list of destinations.

> Also, it would be good to spell out how
> long all those RREQs have to be kept by a node ? for duration of the DAG?

For any particular Orig SeqNo, only one RREQ-InstanceID is maintained.  
The L field limits how long the RREQ-Instance can be maintained.

>   What
> happens if different RREQs come in with different values for S bit? how is the
> S-bit joined (maybe I missed it reading)

AODV-RPL does not specify how to use the S bit when selecting RREQ 
information for the return route to OrigNode.  It could be that the 
symmetric route is not preferable because an asymmetric route would have 
better Rank evaluation from the Objective Function.



>
> * "stale sequence number" needs defintion earlier instead of popping up in
> 6.4.3 after being already used

Done.

>
> * " In this case, the router MAY optionally associate". What does "associate"
> mean here? Same as "pair"? or simply "it received it before and was in path"


New wording not using "associate":

"In other words, the router MAY optionally include the Address Vector of 
the symmetric route back to OrigNode as part of the RREQ-Instance data."

>
> * 6.3.3. is cryptic, it is unclear why the Targ cannot just send the delta and
> still sends its own RPLInstanceID. Examples of collision/no collicion would go
> a long way here


Suppose TargNode receives the RREQ with value of Orig_RPLInstanceID = 
0x3A.  If TargNode had already used the value of 0x3A for an unrelated 
Targ_RPLInstanceID, then TargNode cannot use that same value in the RREP 
to be transmitted back to OrigNode.  It would have to pick another 
RPLInstanceID and then supply the Delta value that allows OrigNode to 
figure out which of its Orig_RPLInstanceIDs is associated with the 
received RPLInstanceID from the RREP.

>
> * Secton 7: a sentence is probably missing that a intermediate router MUST
> generate a G-RREP and send it further upstream after processing a received
> G-RREP


Done:

    "An upstream intermediate router that receives such a G-RREP MUST
     also generate a G-RREP and send it further upstream towards OrigNode."

>
> Omissions:
>
> * what about multicast? is it specifically excluded?


It is excluded (along with other schemes modifying the semantics of an 
IP address, etc.).  We could re-tool AODV-RPL for multicast but it would 
take a bit of work.  It would be a different protocol document with new 
message formats.  This has been done in several ways for AODV, and any 
one of those methods could be adapted for AODV-RPL.  Most likely the 
same multicast group all-AODV-RPL-nodes could be used for disseminating 
the new multicast messages.

We will watch to see if there is a desire for a multicast routing protocol.

Regards,
Charlie P.