Re: [Roll] Last calls extension - AODV-RPL Review

[Rahul Arvind Jadhav <[e-mail]>]

Hello All,

Following are my review comments for AODV-RPL:


1.       RREP option does not echo-back the “Orig Seq number” from the RREQ. How would a 6LR differentiate between fresh/stale RREPs from the same TargNode/Instance?



2.       The L bits in RREP option are echoed from RREQ-option ? The text gives me that feeling, but I guess that’s not how it’s supposed to be. The text referred to is “L: 2-bit unsigned integer defined as in RREQ option”.


3.       The document introduces new sequence numbers, but the handling is not described in the step-by-step processing of RREQ/RREP. I feel it is important to describe in those sections.


4.       All the newly introduced sequence (Orig Seq, Dest Seq) numbers got to be lollipop counters. But there is no text to suggest so.


5.       The explanation of ‘L’ bits in 6997 and the draft does not match. 6997 introduced ‘L’ bits so as to clear off the state created by the P2P-RPL instances in a much quicker way without depending on route-lifetime. The drafts intended purpose of ‘L’ bits also seems similar but the text in the draft says, “Once the time is reached, a node MUST leave the DAG and stop sending or receiving any more DIOs for the temporary DODAG.” If the states are cleared, how would a node stop sending/receiving the DIOs in the context?



6.       ‘L’ bits allow the RREQ/RREPs to float in the network for max 64 seconds. This is the same upper limit as defined in 6997. Our experiments suggests that this upper bound is too low. Please note that DIO is transmitted using trickle timer and as such the DIOs might float in the network for much higher timer. There are major issues with this upper bound been low. For e.g. the states might get cleared because of ‘L’ bits and the nodes might consider the floating RREQs/RREPs as new thus recreating the states and the RREQs/RREPs might result in loops. I suggest to change definition of ‘L’ bits to be: (0=infinite, 1=16secs, 2=64sec, 3=256sec). 2sec, imo, is unrealistic in any size network and does not help.



7.       The target option defined in this draft and in 6550 differ significantly both syntactically & semantically. This terminology will lead to confusion. I feel a new term should be defined which specifies this target option (example could be ART-option which stands for AODV-RPL Target Option)



8.       Route-entry invalidation is not described in the draft at all. What happens to the old path when the TargNode sends a RREP through a new path for a new “Orig Seq” from the OrigNode RREQ? Should the old path wait for route lifetime expiry ? There should be a way to invalidate previous path route-entries by having the TargNode send a RREP-DIO with corresponding “Orig Seq” with route-lifetime=0 on the old path to invalidate it.



9.       Previously accepted review comment regarding incorrect values of RSSI in Appendix A is not incorporated. Please check https://mailarchive.ietf.org/arch/msg/roll/jSJ5Hg1e8pCXmmWUCjkNwvhyr44


Regards,
Rahul


From: Roll [mailto:[e-mail]] On Behalf Of Ines Robles
Sent: 30 July 2018 15:55
To: roll <[e-mail]>
Subject: [Roll] Last calls extension - review request

Dear all,

We extend these calls until 10-08-2018:

- WGLC for draft-ietf-roll-efficient-npdao-03
- WGLC for draft-ietf-roll-aodv-rpl-04
- Call for adoption for draft-rahul-roll-rpl-observations

During the IETF 102 we got some reviewers for these documents. Please, It would be nice if you could do the review before 10-08.

Thank you,

Ines and Peter.