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

["Liubing (Remy)" <[e-mail]>]

Hello Rahul,

Thank you for your comments. Please find my response inline.

Best regards,
Remy

From: Roll [mailto:[e-mail]] On Behalf Of Rahul Arvind Jadhav
Sent: Friday, August 03, 2018 12:08 PM
To: Routing Over Low power and Lossy networks <[e-mail]>
Subject: Re: [Roll] Last calls extension - AODV-RPL Review

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?
[Remy]: The freshness of RREPs is not done by the Orig Seq number, the Destination sequence number of the TargNodes does this job. This mechanism is inherited from AODV.



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”.
[Remy]: The L bits is also carried in RREP, because for asymmetric route, there are two separated  DODAGs for RREQ and RREP instances, if the L bits is not carried in the RREP-DIO, the intermediate nodes won’t know how long they will stay in the RREP DODAG.


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.
[Remy] Good point, will add related descriptions.


4.       All the newly introduced sequence (Orig Seq, Dest Seq) numbers got to be lollipop counters. But there is no text to suggest so.
[Remy] The maintenance of sequence numbers follows the section 6.1 of AODV RFC 3561.


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?
[Remy] Yes, the termination of sending/processing DIOs should happen before the removal of the states. RFC 6997 says that: “A router MUST detach from the temporary DAG discovery once the duration of its membership in the DAG has reached the value indicated by the L field.” In my opinion, there is no removal of states in this phrase. 6997 also says, it is usually sufficient that the Origin wait for twice the duration indicated by the L field inside the P2P-RDO used for the previous route discovery before reusing the RPLInstanceID for a new route discovery. I guess this is what you mean by “clear off the state”.


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.
[Remy] Good point, will update the definition.



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)
[Remy] Indeed, the definitions of these two are different in terms of the flags. “AODV-RPL Target Option” is too long… Maybe ART-option is better.



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.
[Remy] Currently there is no active route invalidation in the draft. The unused path wait for route entry lifetime expiry. The default route lifetime in the DIO can be set to a small value,  while the lifetime is extended each time when the TargNode uses the path (a relatively big value can be given).  Therefore the unused path can be cleaned up quickly. The old path can be dealt in the same way. As the sequence number in the RREQ-DIO is increased, a node on the old path will update the route entry (sequence number, lifetime, the other items stay the same), and the lifetime is shortened to the small value. This route entry will be deleted after it expires in a short time. Active path invalidation is more complicated in this case, because we need to find the node whose parent has been changed (like in efficient no-path DAO), and this node may not be the TargNode.

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
[Remy] Thank you for reminding that. The table should be updated as follows.
   +-------------------------+----------------------------------------+
   | RSSI at NodeA for NodeB | Expected ETX at NodeA for NodeB->NodeA |
   +-------------------------+----------------------------------------+
   |          > -60          |                  150                   |
   |        -70 to -60       |                  192                   |
   |        -80 to -70       |                  226                   |
   |        -90 to -80       |                  662                   |
   |       -100 to -90       |                  993                   |
   +-------------------------+----------------------------------------+



Regards,
Rahul


From: Roll [mailto:[e-mail]] On Behalf Of Ines Robles
Sent: 30 July 2018 15:55
To: roll <[e-mail]<mailto:[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.