[Roll] RtgDir of draft-ietf-roll-aodv-rpl

[Ines Robles <[e-mail]>]

Dear Authors,

Please find below, the routing directorate review of adov-rpl  made by Tony
(Cc'),

Many thanks Tony!!!

Ticket open for this review: https://github.com/roll-wg/aodv-rpl/issues/6

BR,
Ines.

---------- Forwarded message ---------
From: Tony Przygienda <[e-mail]>
Date: Fri, Mar 17, 2023 at 11:46 PM
Subject: Re: rtgdir Last Call Review requested: draft-ietf-roll-aodv-rpl
To: Ines Robles <[e-mail]>
Cc: Luc André Burdet <[e-mail]>, [e-mail] <
[e-mail]>, dominique barthel <[e-mail]>


Pls forward the review ...



I have been selected to do a routing directorate “early” review of this
draft.

https://datatracker.ietf.org/doc/html/draft-ietf-roll-aodv-rpl-16

Document: https://datatracker.ietf.org/doc/html/draft-ietf-roll-aodv-rpl-16
Reviewer: Tony Przygienda
Review Date: 03/23
Intended Status: Standards

*Summary:*

I have good amount of readability suggestions and some minor doubts on
correctness/robustness.

*Comments*

The draft made for quite a lot of reading for me since it  relies on so
many other RFCs & drafts I was only superficially familiar with. No
complaint, just observation.

Overall readability is pretty good but because it's a dense spec bits of
indication of reason/logic for certain parts of the spec would help a lot
as well examples in places pointed out below.

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.

*_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).

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

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


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

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

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

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

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

* 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? 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?  What happens if different RREQs come in with different values
for S bit? how is the S-bit joined (maybe I missed it reading)

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

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

* 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

* 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

*Omissions:*

* what about multicast? is it specifically excluded?


thanks


-- tony

>