Re: [Roll] No path DAO problem stmt draft

Simon Duquennoy <simonduq@sics.se> Thu, 03 March 2016 07:57 UTC

Return-Path: <simon.duquennoy@gmail.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 E72721A014C for <roll@ietfa.amsl.com>; Wed, 2 Mar 2016 23:57:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 rRavbuEKWqZ6 for <roll@ietfa.amsl.com>; Wed, 2 Mar 2016 23:57:17 -0800 (PST)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E76F21A013F for <roll@ietf.org>; Wed, 2 Mar 2016 23:57:16 -0800 (PST)
Received: by mail-wm0-x230.google.com with SMTP id l68so118850923wml.0 for <roll@ietf.org>; Wed, 02 Mar 2016 23:57:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to; bh=8M6gQwzsmgjEppZDhH1I5lvAV4N4ZF6/Olwho8zEUyk=; b=eZrS+Wp2k1LHBz4h8vq+nX6OMGFt9BkT4jrO9GITfRZ+cn5YbSMw7Bd/Z4ZWVKwqgC 9W4W/lGP6KEhVST0bmdr97MtCr0xHvGDZTEmbmc3AfKHof7ceK3K4uPcZPzAZ4dcAH7j 9mm34f8y0sbmUV4QWDBc1fi64t0V3Wq1UKXECzm/U9P1MEbPTw7qnc+Z5UnoR1hJ0Sxc AovowGcmHgna9OzKyDzxmHAkBU4lAxWTSSQwlTwSYzYJeVsbDgvjZZijNa8iU+JR2HvC dj9p+rNayreBWJk3Lh7przOzTGGPWmboc4FxXfQTX/jcGWzhrYUuET+3aEtgAnUW4N3S M11g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to; bh=8M6gQwzsmgjEppZDhH1I5lvAV4N4ZF6/Olwho8zEUyk=; b=uFYMc5XXvNNrcptgu9ivr/7B+5lm2GULBfbtvG6qD8J8KiWDAR1SgXBOFX05DPHXiy IHifsgK3QFLoy0VSuYfjEkauHjuoU6r07DgXMYnlzcPQkMwxQdKCEaaZbmHzZdvSbukA h/Uv1SHsq3ADSZ6NUvC8aR1P1T6zRXyEfku45NSDKD5MLWYEJFPyb+9xMpsuXTfzC7hb 2gVC4Iz/azmtviJ3zsCIH4zk/iUAoAdkyOq2sB0GhGzL/XcFvDZCVNEnAa+lcajAcl34 LHG+1EK+p4+HRXA+pFxc676s65ABgj2YMJNKkhYTOdzmfdQIUU7w1YH2ZBFPOAS6tGOM oScA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to; bh=8M6gQwzsmgjEppZDhH1I5lvAV4N4ZF6/Olwho8zEUyk=; b=FgQ8lmQdowuFM3J41YFbjphFj/+FOCSfL1o7Qpf8IqFAQoO+wOVogr148ejD6eCXy5 DgiTCyDFD2vDHOquNHQbb7jiwvV9jkpj0nTX2gss3MGlq099IBKYAwjQMPkakl2i/Kz9 jRLRBgLBaA07A0bRB1TFmwivjEk/wGEgCwCM4dvEky8ELc5uK2t+0lihJ+e8rDL4i8ga o9cX3lV40Cu9pLTZBRzAczCOadmMAeZ9DSlKPGaCTJSYSQCLbrXcjCumAos53wSxPvX3 h/7nxQ6e9RZlfqyvNdLU2CLi9nIkhRinflui5Gr5Kun9cjOHcvrnDilUJNnmjM4svMsV 8zyw==
X-Gm-Message-State: AD7BkJJOBQO8WbJuXMqUGlYwXBoR6hq2RdVubFLOE2SLA6lcavBex8V5as7Aw0CRKiNBmss2/GNuW+oS6IvX3A==
MIME-Version: 1.0
X-Received: by 10.28.212.85 with SMTP id l82mr1840843wmg.82.1456991835472; Wed, 02 Mar 2016 23:57:15 -0800 (PST)
Sender: simon.duquennoy@gmail.com
Received: by 10.194.164.130 with HTTP; Wed, 2 Mar 2016 23:57:15 -0800 (PST)
In-Reply-To: <982B626E107E334DBE601D979F31785C5CEC8F25@blreml510-mbs.china.huawei.com>
References: <982B626E107E334DBE601D979F31785C5CEC8E5C@blreml510-mbs.china.huawei.com> <56D72358.9040102@gmail.com> <982B626E107E334DBE601D979F31785C5CEC8F25@blreml510-mbs.china.huawei.com>
Date: Thu, 3 Mar 2016 08:57:15 +0100
X-Google-Sender-Auth: E67P_fywz8cilwApPFKWJfhs2sY
Message-ID: <CAMxvJtK-ACaW3sS7_Yqs+_CKV3fTzoJ6Qaj=if838CSpQWrvXA@mail.gmail.com>
From: Simon Duquennoy <simonduq@sics.se>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/alternative; boundary=001a1146ed8ccb4a49052d205861
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/6NR9MpdQ3hwEQUMclBcVlFL_eHM>
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 07:57:20 -0000

Dear Rahul,

Simply wanted to add that this is a problem we also encountered. This is an
important draft IMO (and nicely-written one).
One additional comment regarding DAO-ACK: if the node does not receive the
ACK it may decide to resend the NP-DAO some time in the future. May help if
the link failure to the old parent was transient.

Best,
Simon


On Thu, Mar 3, 2016 at 5:17 AM, Rahul Arvind Jadhav (Rahul Arvind Jadhav,
2012 Labs) <rahul.jadhav@huawei.com> 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.
>
>
>
> 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
>
> https://www.ietf.org/mailman/listinfo/roll
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>