Subject: Re: [Roll] Iotdir last call review of draft-ietf-roll-efficient-npdao-11

From: Rahul Arvind Jadhav <[email-masked]>
Date: Mon, 3 Jun 2019 00:32:40 +0000

Thank you Shwetha for your review and please find my responses inline.

Regards,
Rahul

> -----Original Message-----
> From: Shwetha Bhandari via Datatracker [mailto:[email-masked]]
> Sent: 31 May 2019 17:50
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Iotdir last call review of draft-ietf-roll-efficient-npdao-11
> 
> Reviewer: Shwetha Bhandari
> Review result: Ready with Issues
> 
> 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
> https://datatracker.ietf.org/group/iotdir/about/
> 
> 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 https://tools.ietf.org/html/rfc6550#appendix-
> A.2.2 and https://tools.ietf.org/html/rfc6550#appendix-A.2.3. 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?

[RJ] Yes, this is correct to the point that _if_ NPDAO is received from the (sub)child node then it will result in the subsequent cleanup of its path. 
The problem with storing MOP is that there is absolutely no way for a sub-child node to trigger this NPDAO (since its parent adjacencies may not have changed). What DCO achieves is independence from this trigger of NPDAO by triggering DCO from ancestor on the basis of regular DAO (whenever it flows) from the (sub)child node. Thus even if (sub)child's parent adjacencies have not changed the ancestor knows that paths for that (sub)child node has changed.

 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"
> https://tools.ietf.org/html/draft-ietf-roll-efficient-npdao-11#section-3.2
> Based on response to the above this requirement may not really be called
> out here?
> 
> >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?
> 

[RJ] There is currently no way for downstream nodes to know whether the upstream nodes en-route support DCO. Note that if DCO is not implemented in ancestor node then the invalidation of the previous path won't happen (which means cleanup only on route-lifetime expiry). Also note that current NPDAO also depends on the node's connectivity to its previous parent been intact. Thus if NPDAO that would have been generated (on loss of connectivity) would still not have worked anyways (which means cleanup on route-lifetime expiry). Note that network with partial nodes supporting DCOs is not fatal at all. The only point is route cleanup may be sub-optimal till the point the network is completely upgraded.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 3 Jun 2019 11:29:35 +0000

My 2 cents

> > 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
> > https://tools.ietf.org/html/rfc6550#appendix-
> > A.2.2 and https://tools.ietf.org/html/rfc6550#appendix-A.2.3. 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?
> 
> [RJ] Yes, this is correct to the point that _if_ NPDAO is received from the
> (sub)child node then it will result in the subsequent cleanup of its path.
> The problem with storing MOP is that there is absolutely no way for a sub-child
> node to trigger this NPDAO (since its parent adjacencies may not have
> changed). What DCO achieves is independence from this trigger of NPDAO by
> triggering DCO from ancestor on the basis of regular DAO (whenever it flows)
> from the (sub)child node. Thus even if (sub)child's parent adjacencies have not
> changed the ancestor knows that paths for that (sub)child node has changed.
> 

PT > The DCO has a number of advantages. In particular it only kills the old route when the new route is available, and it follows the traffic on the way down to it does not kill it as the cross like a legacy NPDAO would.

> > https://tools.ietf.org/html/draft-ietf-roll-efficient-npdao-11#section
> > -3.2 Based on response to the above this requirement may not really be
> > called out here?
> >
> > For the same reasons as above it is confusing why this consideration
> > is needed.
> >
> > 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?
> >
> 
> [RJ] There is currently no way for downstream nodes to know whether the
> upstream nodes en-route support DCO. Note that if DCO is not implemented in
> ancestor node then the invalidation of the previous path won't happen (which
> means cleanup only on route-lifetime expiry). Also note that current NPDAO
> also depends on the node's connectivity to its previous parent been intact.
> Thus if NPDAO that would have been generated (on loss of connectivity) would
> still not have worked anyways (which means cleanup on route-lifetime expiry).
> Note that network with partial nodes supporting DCOs is not fatal at all. The
> only point is route cleanup may be sub-optimal till the point the network is
> completely upgraded.

PT > When both methods are active at the same time the broken path is cleaned from both ends till the node where the control messages meet.
PT > It might be that the knowledge that the node left the DODAG comes from the outside to the root, e.g. a routing protocol or a backbone router. 
PT> In that case only the root can clean up, and DCO is the way to do it.

All the best,

Pascal