My 2 cents > > > > > 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. > 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. > 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. 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
