Re: [Roll] DCO Invalidation triggered from ancestor node

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

Hello Rahul:



  *   It is possible for a 6LR to initiate a NPDAO using existing route state. Similarly it is possible for DCO to be initiated by ancestor 6lr.

Probably but in case of lifetime out the expectation is that the children also timed out so it has to be a different case. I noted text in the current spec “


   In this case, Node A

   which is the common ancestor node for node D along the two paths

   (previous and new), should generate a DCO which traverses downwards

   in the network.

I do not think the “should” here is really what we wanted. You now that BCP 14 is kinda optional and that “should” will be interpreted as a SHOULD. Which is unwanted because sending a DCO is an option to be used wisely. There is a whole history in routing protocols of pruning routes based on second hand information and that history is not generally good. Protocols, the original RPL included, tend to prefer to let a route die of old age than all the race conditions that happen when a misinformed third party tells you a route is gone. DCO has protections with the path sequence but there might still be cases where it is unwanted. For instance, cleaning a route that is not used can be a waste of energy. People might still prefer the reactive cleanup with the RPI flags. I suggest we change the sentence above with a “could” instead of “should”.


  *   Now why any 6LR would unilaterally generate an NPDAO or DCO .. This remains to be seem.


We avoided to cover the case of a routing table full because it has many implications, and should be designed globally. Instead we always considered that the networks are designed in accordance with the capability of the devices deployed there, which basically pushed many to implement only non-storing.

The unsolicited DCO can be triggered by an external process. E.g.,  it is very useful in the case of a 6BBR when a node moves to a different DODAG. The root of the old DODAG (as registering node) is notified by the 6BBR with a ND (EARO status code 4, removed, see RFC 8505). In turn it should send a DCO down to remove all state in the old DODAG.

I’m not sure where to specify that. I was asked to remove pretty much all RPL related text from the 6lo docs. We have the RPL unaware leaf draft that is doing the missing link so maybe I could write that there.

All the best,

Pascal

From: Roll <[e-mail]> On Behalf Of Rahul Arvind Jadhav
Sent: jeudi 16 mai 2019 07:29
To: Routing Over Low power and Lossy networks <[e-mail]>
Subject: Re: [Roll] DCO Invalidation triggered from ancestor node

Thanks Pascal for the clarification.

I can draw a parallel here between what is possible with DAO and DCO.
It is possible for a 6LR to initiate a NPDAO using existing route state. Similarly it is possible for DCO to be initiated by ancestor 6lr.

One advantage with unsolicited DCO is that the target node would eventually be notified that some 6LR had initiated a route invalidation on its behalf. This is because unlike NPDAO, the DCO would eventually reach the target node downstream (ofcourse only if the path is intact).

Now why any 6LR would unilaterally generate an NPDAO or DCO .. This remains to be seem.
One reason could be that 6LR sees that its routing table is full and it needs to evict existing route entries to make way for new “higher priority” routing entry. This can be initiated in a more gracious way using DCO that with NPDAO (because with DCO, target node eventually would be notified). Having said that, this scenario is just a figment of imagination. I haven’t come across this problem/scenario in my implementation.

Thanks,
Rahul
From: Roll [mailto:[e-mail]] On Behalf Of Pascal Thubert (pthubert)
Sent: 14 May 2019 17:22
To: Routing Over Low power and Lossy networks <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Roll] DCO Invalidation triggered from ancestor node

You right Rahul.

I guess nothing prevents it though. Just that you should only report direct parent - child relationships otherwise you may create loops...

Regards,

Pascal

Le 14 mai 2019 à 09:01, Rahul Arvind Jadhav <[e-mail]<mailto:[e-mail]>> a écrit :

I understand that you describe a route redistribution. RPL allows it at your own risk, you need to set the E bit to indicate external.

[RJ] E-bit in 6550 says, “The 'E' flag is set to indicate that the parent router redistributes external targets into the RPL network.  An external Target is a Target that has been learned through an alternate protocol.”
I thought E-bit is used to advertise external prefixes or routes known to 6LR outside RPL domain. Unaware leaves looks like a valid scenario for this but within RPL domain and within the DODAG can a 6LR redistribute routes using this flag?

We use it in the case of unaware leaves. The leaf uses RFC 8505 to talk to the RPL router and the router turns that into a DAO.

Btw the call for adoption for the RPL unaware leaves is out. All support is welcome !
All the best,

Pascal

Le 14 mai 2019 à 07:02, Rahul Arvind Jadhav <[e-mail]<mailto:[e-mail]>> a écrit :
Hello ROLL,

Does RPL allow DAO to be sent unsolicited from a non-target node ? For e.g., can a 6LR node on parent switching use the existing routing state to send DAO on behalf of the childs in sub-dodag to update the routing states on new path ?

This topic came up during rpl-observations discussion in IETF102/103 and it was discussed that it is possible. But I couldn’t find any explicit statements in 6550 allowing this.

I am trying to relate unsolicited DCO proposition with this behavior to understand more.

Thanks,
Rahul


From: Roll [mailto:[e-mail]] On Behalf Of Rahul Arvind Jadhav
Sent: 09 May 2019 17:19
To: Routing Over Low power and Lossy networks <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Roll] DCO Invalidation triggered from ancestor node

Thanks Pascal for the feedback.

The race condition and the associated timer in case of multiple preferred parents is a valid scenario. This scenario needs to be handled regardless of unilateral DCO and is explained explicitly in the draft (Section 4.5.3).

Thanks,
Rahul

From: Roll [mailto:[e-mail]] On Behalf Of Pascal Thubert (pthubert)
Sent: 09 May 2019 17:09
To: Routing Over Low power and Lossy networks <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Roll] DCO Invalidation triggered from ancestor node

Hello Rahul:

It is possible that node D in your picture sends a same DAO (same path seq) via both B and C. An unsolicited DCO sent to upon the first DAO received by B could collision with the DAO via C and create race conditions. E.g. a node destroys a route upon DCO seq 5 and recreates it right after when the DAO same seq 5 comes in. Packets in flight will be sent back with a flag in the RPI or destroyed. Not good.

Note: RPL has a datapath detection for broken routes so if it is effectively being used, the path via C would eventually go away based on the flag above.

So I do not favor unsolicited DCOs, and if done, there should be a timer associated to it to make sure that no DAO comes via C. The duration of that timer is hard to fathom…

All the best,

Pascal

From: Roll <[e-mail]<mailto:[e-mail]>> On Behalf Of Rahul Arvind Jadhav
Sent: mercredi 8 mai 2019 07:07
To: roll <[e-mail]<mailto:[e-mail]>>
Subject: [Roll] DCO Invalidation triggered from ancestor node

Hello ROLL,

During the review of draft-ietf-roll-efficient-npdao-10, there was a point raised by Alvaro which we would like to bring to the WG.

The draft adds DCO msg which allows route invalidation by the common ancestor node. The DCO message is generated by the ancestor node in response to DAO with I-flag (invalidate previous route flag) set in context to the corresponding target. The I-flag is used as a mechanism so that the target is in-charge of its own invalidation. Having said that, the ancestor node has all the state information needed to generate the DCO __unilaterally__.

We would like to understand WG thoughts on “whether this unilateral invalidation from ancestor can be allowed or we should strictly let the ancestor node generate DCO in response to DAO with I-flag set.”

Am not quoting pros/cons of the approaches, because this might bias the thinking and it would be nice to have different perspectives.

A diagram to aid understanding: https://github.com/roll-wg/efficient-route-invalidation/blob/master/unilateral-dco.md

Any feedback will be very useful and appreciated.

Thanks,
Rahul
_______________________________________________
Roll mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/roll