[Roll] No path DAO problem stmt draft

["Rahul Arvind Jadhav (Rahul Arvind Jadhav, 2012 Labs)" <[e-mail]>]

Not sure if the below msg actually reached mailing list … resending it …

From: Rahul Arvind Jadhav (Rahul Arvind Jadhav, 2012 Labs)
Sent: 03 March 2016 PM 07:34
To: [e-mail]
Subject: RE: [Roll] No path DAO problem stmt draft

Hi Cenk,

Please find comments inline …

Thanks,
Rahul

From: Roll [mailto:[e-mail]] On Behalf Of Cenk Gündogan
Sent: 03 March 2016 PM 01:46
To: [e-mail]<mailto:[e-mail]>
Subject: Re: [Roll] No path DAO problem stmt draft

Hello Rahul,
On 03.03.2016 05:17, Rahul Arvind Jadhav (Rahul Arvind Jadhav, 2012 Labs) wrote:
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.
I think this statement can/should be broken down.
If node D changes its parent from B to C it still could be able to receive traffic from B.
This is however highly dependent on the underlying metric that is used
to drive the parent selection.
From the picture in your draft: I would expect that p2p traffic traversing
from G -> B -> D should still work (when we have stale entries and still connectivity)
And p2p traffic from D to G would traverse through D -> C -> H -> A -> G.
But I understand your point and I completely agree with you, in case of a complete
link loss B -> D wouldn't work anymore.

So to summarize, I see two cases here:

1) D changed from B to C, but the link B <-> D still has *some* connectivity:

p2p traffic in the storing-mode must include a RPL Hop-by-Hop option (RFC6553),
which could detect this dilemma by inspecting the SenderRank within that option.
As a reaction, node D would try to send that packet back to D with the Forwarding-Error bit set.
In the best case, B would receive this and delete its DAO state to this former child.
Well, .. this only works if the new rank of D changed when accepting C as a preferred parent.

[RJ]: In the above stmt, I didn’t understand, “As a reaction, Node D would try to send that packet back to D with …”. I think you meant “packet back to B with…”. Why should in this case D send the packet back to B? There are scenarios when forwarding-error bit could be set and still the traffic flows as usual and may work (until another fwd-error is detected). The change will impact that functionality.
Anyways, imo (and like you observed) this won’t be a generic solution because of its dependency on D’s rank post switching to detect forwarding error.


As a side note:
I just ran into [1] which addresses the cleanup of old DAO entries for ancestors, recursively.

[RJ]: I think the stmt in 6550 you are pointing towards is…
        “With DAO inconsistency loop recovery, a packet can be used to recursively
        explore and clean up the obsolete DAO states along a sub-DODAG.”
It is not clear what packet can be generated!!! Assuming an NPDAO could be generated …. But then an NPDAO cannot be generated by any other node on behalf of the target. To clarify, any other node does not know the Target’s DAOSequence and Path Sequence to generate an NPDAO. There are race-conditions if any other node generates NPDAO on behalf of the target and does not obey the DAOSequence and Path Sequence fields of the target.


2) D changed from B to C, but the link B <-> D has *no* connectivity:

I would assume the (6Lo-)Neighbor Discovery would resolve this
issue by detecting that the neighbour is not reachable anymore.
If there is enough p2p traffic going on, then the Neighbour Unreachability Detection
(NUD) might kick in fairly quick. Once the neighbour was detected as unreachable,
this information needs to be synchronized with RPL's routing table, of course.
RPL shouldn't keep routing entries where the next-hop part is known to be unreachable.
Afterwards, as a consequence of p2p traffic from any previous ancestor to D, ICMPv6
error messages (Destination Unreachable) could clear up the states in their routing tables as well.

[RJ]: There are foll problems with this approach:

1.       Destination Unreachable will be able to clear up the states only in the source node which originated the P2P traffic, since icmp dest unreachable would be directly sent to it. All the intermediate 6LRs will continue to maintain the states.

2.       The time factor for NUD could be substantially higher impacting P2P traffic significantly.

3.       Coupling of RPL states with NUD. It is not desired that RPL assumes ND.


Best,
Cenk

[1] https://tools.ietf.org/html/rfc6550#section-11.2.2.3


Thanks,
Rahul


From: Roll [mailto:[e-mail]] On Behalf Of Cenk Gündogan
Sent: 02 March 2016 PM 11:01
To: [e-mail]<mailto:[e-mail]>
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

[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