Re: [Roll] No path DAO problem stmt draft

Cenk Gündogan <cnkgndgn@gmail.com> Wed, 02 March 2016 17:31 UTC

Return-Path: <cnkgndgn@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 A27BD1B2EA8 for <roll@ietfa.amsl.com>; Wed, 2 Mar 2016 09:31:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 FX6c093b_ND7 for <roll@ietfa.amsl.com>; Wed, 2 Mar 2016 09:31:07 -0800 (PST)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 6A4721B2E9B for <roll@ietf.org>; Wed, 2 Mar 2016 09:31:07 -0800 (PST)
Received: by mail-wm0-x233.google.com with SMTP id n186so96816229wmn.1 for <roll@ietf.org>; Wed, 02 Mar 2016 09:31:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=CAR/u8wibh1xAsoN2pb7Ojqo0BWd0na6wM9szt6ldKA=; b=QIv24lLVx/7GT+YBzsYxxUiYyVP4/CFzUZqs/i99XCKp9XjnVI2iPAQ7i59p+M+CZV sMmnfZfClQlsKr3vhB9UJ0QhNz2Gr8LnLYXV1hG/AGzYWzugUIzrFeFkA9ryX1POls2j hREmdp0pF+NYNINNadk/h7DnmeCW2kiaA3B3fyO3tLcQgbZuKjTTW6FXnFq8paev8D0j VwenYQO/vbwTbJuQatmmfAsRwSdW7uHmT7zKVD21Nzb9UjqZtiMU8CT7p8kZslTT0Sza Ia9FVpsQnnmZjET2ixLCTVuh9qQyoXH+hm/FbjEbf5snw9WvCfpyPt9LLySRo+kRV0KV LHMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=CAR/u8wibh1xAsoN2pb7Ojqo0BWd0na6wM9szt6ldKA=; b=XECVzW1K+AmhNGYgDyDe+zyoHIfj45GIJ8d3Tf9hNTT9muExkxcB4oyH7kBz4ZFdWu F/1D6Uw1NngSUHZdzBhf5Lr+VvKcC8fQ/8TRM6TTCgvYrOvuJ/rwrU4t5UVMdapuAkcf 3LsgNTQfip2bur206K4X7uROY74Q5Fb9Izl2paRPA3N29gG6DnhyBgn1pB2LVmafoXus y8XBUFtBe7dhVbEcZDN2+94ixlxCOiDE4FUUpqN1OpFyQGW9z7rFl1xC3kMuRxDNwxlO cmT5KfGaTuYgPgiKew3gJ4X+Uk2xRIarB7F5Mu7h0WXXgtpjh+cSKGFfaWtgF1sV0IPw 4fGQ==
X-Gm-Message-State: AD7BkJKsfSsa3WVBxZ1LzPDb2NjDwC9X2gXoG+ykx4iUIC6BYtU483+HW2S6wIWjBhlnAQ==
X-Received: by 10.28.68.86 with SMTP id r83mr1118452wma.73.1456939865891; Wed, 02 Mar 2016 09:31:05 -0800 (PST)
Received: from ?IPv6:2a02:8109:8680:45c:221:ccff:fe67:d847? ([2a02:8109:8680:45c:221:ccff:fe67:d847]) by smtp.googlemail.com with ESMTPSA id i5sm36795896wja.23.2016.03.02.09.31.04 for <roll@ietf.org> (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Mar 2016 09:31:04 -0800 (PST)
To: roll@ietf.org
References: <982B626E107E334DBE601D979F31785C5CEC8E5C@blreml510-mbs.china.huawei.com>
From: =?UTF-8?Q?Cenk_G=c3=bcndogan?= <cnkgndgn@gmail.com>
Message-ID: <56D72358.9040102@gmail.com>
Date: Wed, 2 Mar 2016 18:31:04 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <982B626E107E334DBE601D979F31785C5CEC8E5C@blreml510-mbs.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------020704040005080503090109"
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/3RSEA2hT1NH7FnCDB_z3_E0jwXk>
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: Wed, 02 Mar 2016 17:31:09 -0000

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