Re: [Roll] No path DAO problem stmt draft

Thanks Cenk,

Yes the DAO-ACK scenario you mentioned is relevant and IMO should be explained in the draft.
And as you mentioned, using DAO-ACK, even though a node is aware that its NPDAO (No-Path DAO) didn’t work out, there is nothing it can do about it. The behavior is implementation-defined and may cause interop issues.

Just to restate your scenario:
A node sends an NP-DAO with ACK flag enabled. If the previous parent is unavailable then the DAO-ACK won’t be rcvd and thus the target node is now aware that NPDAO didn’t work out. Having learnt that, there is nothing the node could do about it, and it would still result in stale/unwanted entries along the previous path.

Also there is one more problem statement that needs to be added to the draft, regarding impact on P2P traffic if route invalidation using NPDAO does not work. Stale/Unwanted routing entries may impact P2P traffic since the routing entries are not flushed from previous parent set and they would still consider that the target node is reachable via them for any p2p traffic.

Thanks,
Rahul

From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Cenk Gündogan
Sent: 02 March 2016 PM 11:01
To: roll@ietf.org
Subject: Re: [Roll] No path DAO problem stmt draft

Dear Rahul,

I find the problems outlined in your draft very interesting and thought-provoking.

My two cents..

Usually, an implementation has the choice to request acknowledgements for DAOs
and I would expect some sort of retry mechanism taking place in case of a lost DAO.
I couldn't find any reference to DAO-ACKs in your draft, but I am sure that the
stated problems still hold for the DAO <-> DAO-ACK case.
One advantage of having the DAO <-> DAO-ACK case is however, that the implementation
*knows* whether the NP-DAO reached a previous parent or not.
Unfortunately, there's still the question of how the implementation should respond
to such knowledge? Without specifying this somewhere (and I couldn't find a reference
in RFC 6550, but I could be wrong), the behaviour is implementation-defined.
This can in turn make the interoperability between different implementations
more difficult.

Would it make sense to widen your proposed draft to also include the
DAO <-> DAO-ACK scenario? And maybe some suggestions about how to
react in such cases?

Best,
Cenk
On 02.03.2016 15:04, Rahul Arvind Jadhav (Rahul Arvind Jadhav, 2012 Labs) wrote:
Dear All,

We recently submitted a draft (https://tools.ietf.org/html/draft-jadhav-roll-no-path-dao-ps-00) stating problem statements pertaining to No Path DAO messaging in RPL spec.

The primary pain point that is highlighted is that the No-Path DAO messaging takes a path which has a higher probability of not been available. For e.g. when the node switches its parent, a No-Path DAO is usually generated along the path through the previous parent and the No-Path DAO traverses upwards always along that path. A path which is no longer a preferred path is used for No-Path DAO messaging and thus the probability of No-Path DAO messaging failure is high, resulting in stale routing entries.

Also there are other negative implications mentioned in the document because of this messaging mode.

The work drafts the problem statement and explains requirements from solution point of view.

Kindly feedback if the problem statement impacts you.

Thanks,
Rahul

***************************************************************************************
This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

_______________________________________________

Roll mailing list

Roll@ietf.org<mailto:Roll@ietf.org>

https://www.ietf.org/mailman/listinfo/roll