Last Call Review of draft-ietf-roll-aodv-rpl-16
review-ietf-roll-aodv-rpl-16-rtgdir-lc-przygienda-2023-04-02-00

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