Re: [Roll] No path DAO problem stmt draft

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

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