Re: [Roll] AD Review of draft-ietf-roll-efficient-npdao-09

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Rahul:

My intuition was that a node that ceases to see or ceases to want to use one of its parents P (a parent through which it sent a DAO in the past) would increment its path sequence and send a new DAO with the I flag set via the new set of selected parents. Note that if the parent is still reachable the NPDAO can also invalidate the route but 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 NPDAO would.

The result is invalidation of all the routes with the older path sequence. To answer Alvaro, the trigger is a loss of a parent, or the desire to stop getting traffic from a parent for whatever other reasons.
Also note that a common ancestor may have more than one child reaching the target and all the children with the stale path sequence should get a DCO.

DTSN will pull the routes and if a stale route shows up at the common ancestor then the common ancestor may decide to send a DCO that is not triggered by a I flag but by observing a stale route. The target cannot know that. I agree that the I flag is relatively armless since the DCO is only sent to stale paths. But how long would a target still set it? For me it is mostly a one shot thing, at least if the DAO is acked.

All the best,

Pascal

From: Rahul Arvind Jadhav <[e-mail]>
Sent: jeudi 16 mai 2019 10:38
To: Routing Over Low power and Lossy networks <[e-mail]>; Alvaro Retana <[e-mail]>
Cc: roll-chairs <[e-mail]>; [e-mail]
Subject: RE: AD Review of draft-ietf-roll-efficient-npdao-09

I missed one important point raised in Alvaro’s review:

498 4.4.1. Dependent Nodes invalidation

500 Current RPL [RFC6550] does not provide a mechanism for route
501 invalidation for dependent nodes. This document allows the dependent
502 nodes invalidation. Dependent nodes will generate their respective
503 DAOs to update their paths, and the previous route invalidation for
504 those nodes should work in the similar manner described for switching
505 node. The dependent node may set the I-bit in the transit
506 information option as part of regular DAO so as to request
507 invalidation of previous route from the common ancestor node.

[major] This part is underspecified. How do the dependent nodes know of
the switch? Is A (Figure 1) the common ancestor node mentioned above?

I found the same question being asked during WGLC, and the answer seems to
be: "the dependent nodes will always set the I-flag". Is that my correct
interpretation? The behavior needs to be reflected in the specification.

https://mailarchive.ietf.org/arch/msg/roll/LejLNET8Hk92wPWU3Xi6OaxCujg

[RJ] I have added a para to describe this more. Please check if it makes sense.

If the dependent node always sets the I bit, wouldn’t that result in constant invalidation (unless no route existed before)?  IOW, it seems like the setting of the I bit has to be conditional.  The mail archive talks about the DTSN incrementing — I’m assuming this will happen then the parent switches to a different parent…is that true?  If so, then I think that this piece of text still needs some work.

[RJ]  Actually this point has relation on how sub-dodag (rooted at 6LR switching the parent) routing state update happens in storing MOP. Unfortunately 6550 is not clear on this. We had made this observation in the rpl-observation draft.

If the sub-dodag has to be updated then there are two ways:

  1.  Incrementing DTSN by the switching 6LR. When downstream child 6LRs see a new DTSN from their preferred parent, they also increment DTSN (as well as resetting trickle timer) and thus update the sub-dodag. This has control overhead implications but most easy to implement. If the network is not too deep/mobile and the MRHOF switching threshold is high enough then this works out great.
  2.  Other option is that switching 6LR update the routing state on new path based on its own routing state. This has looping implications as Pascal mentioned in previous mail and also is not easy to implement because you can only stuff in x number of targets/transit options in a given DAO and then managing multiple DAOs is painful.

My implementation currently uses option 1. Thus I am tempted to follow option 1 and let I-flag be enabled only on identifying DTSN increment. But then I didn’t see any loss in keeping I-flag enabled always if target is interested in its invalidation. The invalidation only happens if the route entry is with different nexthop and the path sequence criteria is fulfilled on the ancestor node. In my implementation, I currently enable I-flag always (even though I could have enabled it on the basis of DTSN value). Having said that, if anyone else has any other opinion, I am open to changing the text and setting I-flag conditionally based on DTSN increment.

Or I could point out these possibilities as it is in the draft and let the implementers decide?