Re: [Roll] No path DAO problem stmt draft

"Rahul Arvind Jadhav (Rahul Arvind Jadhav, 2012 Labs)" <rahul.jadhav@huawei.com> Thu, 03 March 2016 04:17 UTC

Return-Path: <rahul.jadhav@huawei.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F421B3BC6 for <roll@ietfa.amsl.com>; Wed, 2 Mar 2016 20:17:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.206
X-Spam-Level:
X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIX8B1w_bi2I for <roll@ietfa.amsl.com>; Wed, 2 Mar 2016 20:17:53 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC2261B3BC4 for <roll@ietf.org>; Wed, 2 Mar 2016 20:17:52 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFG33878; Thu, 03 Mar 2016 04:17:50 +0000 (GMT)
Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Mar 2016 04:17:47 +0000
Received: from BLREML510-MBS.china.huawei.com ([169.254.2.93]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0235.001; Thu, 3 Mar 2016 09:47:39 +0530
From: "Rahul Arvind Jadhav (Rahul Arvind Jadhav, 2012 Labs)" <rahul.jadhav@huawei.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] No path DAO problem stmt draft
Thread-Index: AdF0jF/v4O3xW+LCQPupRYViUwm4pP//3aQA//77uhA=
Date: Thu, 3 Mar 2016 04:17:39 +0000
Message-ID: <982B626E107E334DBE601D979F31785C5CEC8F25@blreml510-mbs.china.huawei.com>
References: <982B626E107E334DBE601D979F31785C5CEC8E5C@blreml510-mbs.china.huawei.com> <56D72358.9040102@gmail.com>
In-Reply-To: <56D72358.9040102@gmail.com>
Accept-Language: en-IN, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.214.70]
Content-Type: multipart/alternative; boundary="_000_982B626E107E334DBE601D979F31785C5CEC8F25blreml510mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.56D7BAEE.0113, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.93, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 9a037dd0b086e108ea78cd0cd6716c35
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/u3_BNWM8xeD8zF57dQg0BzGL3-U>
Subject: Re: [Roll] No path DAO problem stmt draft
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Mar 2016 04:17:56 -0000

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