Skip to main content

Last Call Review of draft-ietf-roll-efficient-npdao-11

Request Review of draft-ietf-roll-efficient-npdao
Requested revision No specific revision (document currently at 18)
Type Last Call Review
Team Internet of Things Directorate (iotdir)
Deadline 2019-05-31
Requested 2019-05-07
Requested by Alvaro Retana
Authors Rahul Jadhav , Pascal Thubert , Rabi Narayan Sahoo , Zhen Cao
I-D last updated 2019-05-31
Completed reviews Iotdir Last Call review of -11 by Shwetha Bhandari (diff)
Secdir Last Call review of -10 by Brian Weis (diff)
Genart Last Call review of -10 by Francis Dupont (diff)
Rtgdir Telechat review of -12 by Eric Gray (diff)
Secdir Telechat review of -12 by Brian Weis (diff)
Assignment Reviewer Shwetha Bhandari
State Completed
Request Last Call review on draft-ietf-roll-efficient-npdao by Internet of Things Directorate Assigned
Posted at
Reviewed revision 11 (document currently at 18)
Result Ready w/issues
Completed 2019-05-31
I am an assigned IOT directorate reviewer for <draft-ietf-roll-efficient-npdao
>. These comments were written primarily for the benefit of the Internet Area
Directors. Document editors and shepherd(s) should treat these comments just
like they would treat comments from any other IETF contributors and resolve
them along with any other Last Call comments that have been received. For more
details on the IOT Directorate, see

Following sections/text need clarification as requested below:

> 2.2.  Invalidate routes of dependent nodes

I am a bit confused about what this section implies.  In the storing mode, RIB
that results in the 6LRs with the DAO received will result in the identifying
dependent nodes. See E.g and With this a NPDAO received
from a node that is the next hop for its dependent nodes should result in the
parent clean up routes to the dependent nodes as well as generate DAO to
reflect the updated RIB. If this is correct then why would invalidating routes
of dependent nodes be an issue with existing RPL + NPDAO mechanism? IMHO Route
invalidation and RIB maintenance based on RPL messaging is an implementation
decision that RPL doesnt have to specify.

> "Dependent nodes route invalidation on parent switching"
Based on response to the above this requirement may not really be called out

>4.6.1.  Dependent Nodes invalidation
For the same reasons as above it is confusing why this consideration is needed.

>NPDAO and DCO in the same network
In a network that has mix of nodes with DCO implementation how will a node is
updated with DCO implementation decide on recommended option 2? The choice of
picking option 2 largely depends on capability of the upstream nodes  rather
than the node that wants to invalidate a prefix to itself. Is there a way to
discover capability of the upstream nodes in old and new path to see if DCO is
implemented before that choice can be made?