Re: [Roll] No path DAO problem stmt draft

[Cenk Gündogan <[e-mail]>]

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.

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



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.

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]
> *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]
> https://www.ietf.org/mailman/listinfo/roll