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

[Rahul Arvind Jadhav <[e-mail]>]

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?