Re: [Roll] FW: New Version Notification for draft-zhong-roll-dis-modifications-00.txt

Cenk Gündogan <cnkgndgn@gmail.com> Wed, 11 November 2015 10:24 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 BF2861A886F for <roll@ietfa.amsl.com>; Wed, 11 Nov 2015 02:24:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 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=1, 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 ZESdztchHmUm for <roll@ietfa.amsl.com>; Wed, 11 Nov 2015 02:24:23 -0800 (PST)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 58C491A886C for <roll@ietf.org>; Wed, 11 Nov 2015 02:24:22 -0800 (PST)
Received: by wmww144 with SMTP id w144so153370989wmw.1 for <roll@ietf.org>; Wed, 11 Nov 2015 02:24:21 -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:content-type; bh=7M5IQ0//NSdkq9mfsQzTP2a6h5ZR1oETWepWX1IB1+M=; b=0u6kYobuj7VcPp972Hw4Vu/OYKHgT7CW6HRH4PBpRJZJLagUjsNkuO34dxyfXQJOfu 7b2/8K3HIt392mS/73KhdhwmdXFNb9vrJYjj/9bBQZeRi10gu5TYMpqObMisUFiygaVx pebMdXdXY+ZmFKzyE6opMqb3tPIt33no1Aj4ZaIih6hMxCzwe24NIGmpeDoHGWvuFZzf RRDof9jd+fGM4gPabPKqDCpkhLZoYemM/KynQVAemV/DLl1yZGJZkLMKOmvnh6kbrB88 Iu9YU6GFu2WwxSoeStLp4PodvoaiBeP2yhkTrd9c7o6HwtHr8VXXWC2G+u9uED9nKwVz 8+hQ==
X-Received: by 10.194.133.233 with SMTP id pf9mr8829587wjb.71.1447237460966; Wed, 11 Nov 2015 02:24:20 -0800 (PST)
Received: from [10.92.124.3] (z5c7c.pia.fu-berlin.de. [87.77.92.124]) by smtp.googlemail.com with ESMTPSA id l1sm8811034wmg.21.2015.11.11.02.24.19 for <roll@ietf.org> (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Nov 2015 02:24:20 -0800 (PST)
To: roll@ietf.org
References: <20151104212059.11204.14401.idtracker@ietfa.amsl.com> <27411_1446673159_563A7B07_27411_6572_1_D260A719.2A380%dominique.barthel@orange.com> <5640FD20.9090000@gmail.com>
From: Cenk Gündogan <cnkgndgn@gmail.com>
Message-ID: <56431753.2020403@gmail.com>
Date: Wed, 11 Nov 2015 11:24:19 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <5640FD20.9090000@gmail.com>
Content-Type: multipart/alternative; boundary="------------030709070608050609050905"
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/KyugjwZJ2KXe1S2BnTbXq2f8Mc4>
Subject: Re: [Roll] FW: New Version Notification for draft-zhong-roll-dis-modifications-00.txt
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, 11 Nov 2015 10:24:25 -0000

I gave a little more thought on the proposed DIS modifications and am 
facing a few questions that I want to share on this mailing list.

Recap:
The proposal adds two new flags to the DIS that will only be evaluated 
in case of a multicast DIS.
For multicast DIS: if the N flag (no inconsistencies) is set, the 
trickle timer of the recipient MUST not be reset and the
DIO MUST contain a DODAG Configuration Option.

We also have this requirement for unicast DIS as per RFC 6550: the DIO 
MUST include a DODAG Configuration Option.

However, it is not always necessary and desired to dissipate DODAG 
Configuration options, if all configurations are well known to all nodes
within the network (e.g. by using default values). Each DODAG 
Configuration that is requested by the above rules are just
16 bytes (!) of unnecessary ballast in such situations.
It even may have a worse impact with the new requirement to respond with 
a Configuration Option if the `N` flag is set for multicast DIS.
Suddenly, all DIOs that were requested with a multicast DIS (without 
resetting the trickle timer) MUST include these 16 bytes.
So, if a node probes it's neighborhood for reachability or something 
else with a multicast DIS (without resetting the trickle timer),
all DIOs sent as response will be bloated with possibly superfluous 
"information".

Please correct me if my aforementioned assumptions are wrong.

In general, it might be a better idea to somehow get more control over 
"which DIO should include what option".
I suggest we could come up with a new RPL DIS option called something 
like "DIO Option Request Option(?)" (sounds weird..),
that includes the option type value of the option that should be 
included in the DIO. This way, it is even possible
to not only request Configuration Options, but also PIOs(+6COs) or more 
different options that might come in the future.
It would also be possible to request more than 1 option types per DIO by 
including different "Request options" in the DIS.

This additional "Request Option" would have a cost of 3 bytes (or 4 if 
we want to include reserved flags). I didn't to the math
and it is highly dependent on the use case, but I >assume< that this way 
of requesting options is far more cost-saving in the long run.

I would like to get your opinions on this idea.

Best,
Cenk

On 09.11.2015 21:08, Cenk Gündogan wrote:
> Hello *,
>
> After a quick look at this draft I noticed that the recommended type value
> of the ` Response Spreading Option` is `0x0A`.
> However, this value collides with the `P2P Route Discovery Option` 
> defined in [1] ([2]).
>
> Besides of my nit-picking, I find the extension to the DIS very 
> interesting.
> If it helps in any way (e.g. for experimenting), then I could 
> volunteer to adjust the
> RPL implementation of RIOT-OS [3] to include this DIS extension.
>
> Best,
> Cenk
>
> [1] https://tools.ietf.org/html/rfc6997#section-15.2
> [2] https://www.iana.org/assignments/rpl/rpl.xhtml#control-message-options
> [3] http://www.riot-os.org/
>
> On 04.11.2015 22:39, dominique.barthel@orange.com wrote:
>> Hello all,
>>
>> We've just submitted a draft to augment DIS behavior in RPL so that
>> solicitation for DIOs can be more selective and more finely controlled by
>> the soliciting node.
>> When the flags have their default values and the new options are absent,
>> [RFC6550] is unchanged.
>> Remember that [RFC6550] had provision in the text for such flag to augment
>> its behavior.
>> This proposal does not change the Trickle timer mechanism whatsoever
>> ([RFC6202]).
>> Experimental data on how effective this augmented DIS mechanism is, will
>> follow in a later revision of the draft.
>> We welcome your comments.
>> Best regards,
>>
>> Denglin, Dominique and Emmanuel
>>
>> Le 05/11/15 06:20, «internet-drafts@ietf.org  »<internet-drafts@ietf.org>
>> a écrit :
>>
>>> A new version of I-D, draft-zhong-roll-dis-modifications-00.txt
>>> has been successfully submitted by Dominique Barthel and posted to the
>>> IETF repository.
>>>
>>> Name:		draft-zhong-roll-dis-modifications
>>> Revision:	00
>>> Title:		DIS Modifications
>>> Document date:	2015-11-04
>>> Group:		Individual Submission
>>> Pages:		14
>>> URL:
>>> https://www.ietf.org/internet-drafts/draft-zhong-roll-dis-modifications-00
>>> .txt
>>> Status:
>>> https://datatracker.ietf.org/doc/draft-zhong-roll-dis-modifications/
>>> Htmlized:
>>> https://tools.ietf.org/html/draft-zhong-roll-dis-modifications-00
>>>
>>>
>>> Abstract:
>>>    This document augments [RFC6550] with DIS flags and options that
>>>    allow a RPL node to better control how neighbor RPL routers respond
>>>    to its solicitation for DIOs.
>>>
>>>                   
>>>         
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> The IETF Secretariat
>>>
>> _________________________________________________________________________________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>> France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci
>>
>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorization.
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>> As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified.
>> Thank you.
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>