Hi Rahul,
Thanks for the response.
I see the usefulness of the draft to meet Req#1: Remove messaging dependency on link to the previous parent.
>From what you explain it is hard to meet "Req#3: Route invalidation should not impact data traffic" as long as both methods of clean up exist. I have no further comments.
Thanks,
Shwetha
On 6/13/19, 10:08 PM, "IoT-DIR on behalf of Rahul Arvind Jadhav" <iot-dir-bounces@xxxxxxxx on behalf of rahul.jadhav@xxxxxxxxxx> wrote:
Thank you Shwetha for your review and please find my responses inline.
Regards,
Rahul
> -----Original Message-----
> From: Shwetha Bhandari via Datatracker [mailto:noreply@xxxxxxxx]
> Sent: 31 May 2019 17:50
> To: Iot-dir@xxxxxxxx
> Cc: draft-ietf-roll-efficient-npdao.all@xxxxxxxx; roll@xxxxxxxx; ietf@xxxxxxxx
> 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.
_______________________________________________
IoT-DIR mailing list
IoT-DIR@xxxxxxxx
https://www.ietf.org/mailman/listinfo/iot-dir
