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

From: <[email-masked]>
Date: Wed, 4 Nov 2015 21:39:18 +0000

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, « [email-masked] » <[email-masked]>
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.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 07 Nov 2015 15:20:29 +0900

WRT: FW: New Version Notification for draft-zhong-roll-dis-modifications-00.txt

As we discussed at the WG meeting, this document is important and
interesting.  It falls into the category of RPL maintenance work.

It is good that deployment and experimentation is now at the point
where people are thinking about how to make it better!

At present, maintenance is out of charter: but this clearly should change.

In reading the charter, we either amend text to it, or since we are
very close to completing all previous milestones involving applicability
statements, etc.  we could think to rewrite/simplify the charter
significantly: It would start from the assumption that 6550 exists, rather
than motivate the reason why 6550 should be produced.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Cenk Gündogan <[email-masked]>
Date: Mon, 9 Nov 2015 21:08:00 +0100

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, [email-masked] wrote:
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 10 Nov 2015 09:32:09 +0000

I find this very interesting too.

My golden path for the group would be to

1)      as the chairs suggested re-charter for RPL maintenance. Perform a re-edit of RFC 6550 with no semantic change to make it more digestible to small communities and new comers. Include the chairs work on encapsulation, excluding non-RPL leaves. Point on 6loRH for compression when available.

2)      Provide an applicability document that insists more on what’s optional and the versatility of applications of the protocol, so it is easier to adopt in various environments. Revive text for industrial. Add mobility scenarios.

3)      select a few lines of work, charter for them in amounts that the group can swallow (more below)

4)      Integrate the above into an internet standard

Potential new lines of work for which drafts were published or discussions happened include:

-        Storing mode with limited resources. What if a parent node cannot accommodate all the DAO states that children want to inject. What if a parent node does not have enough bandwidth for all the flows. The DAO ack discussion falls into here.

-        Other forms of routing. Can we make a std track version of the reactive (P2P) RPL. Route projection model for SDN as presented at the last 2 IETFs.

-        Link types. What if the links are unconstrained (e.g. Ethernet). What if the links are asymmetric or unidirectional. What if the network is composed of heterogeneous link types (e.g. Ethernet backbone, mix of radio and powerline mesh). Impact of TDM/TSCH if any.

-        Non RPL leaves. Impact on encapsulation. Impact on / use of RPL signaling. Related requirements on 6LoWPAN ND (already discussed in 6lo ND update requirements draft).

What do people think?

Pascal

From: Roll [mailto:[email-masked]] On Behalf Of Cenk Gündogan
Sent: lundi 9 novembre 2015 21:08
To: [email-masked]
Subject: Re: [Roll] FW: New Version Notification for draft-zhong-roll-dis-modifications-00.txt

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, [email-masked]<mailto:[email-masked]> wrote:

Hello all,

the soliciting node.

[RFC6550] is unchanged.

its behavior.

([RFC6202]).

Best regards,

Le 05/11/15 06:20, « [email-masked]<mailto:[email-masked]> » <[email-masked]><mailto:[email-masked]>

a écrit :

IETF repository.

Revision: 00

Title:            DIS Modifications

Pages:            14

URL:

.txt

Status:

Htmlized:

Abstract:

submission

The IETF Secretariat

Thank you.

Roll mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 10 Nov 2015 09:47:12 +0000

On the side the list that I gave below is by far not exhaustive. Pleas shime in!

I already missed a number of topics that were in front of us but were not included in RFC 6550;

- Other RPL updates such as the work on DIS (draft-zhong-roll-dis-modifications) which I think is really interesting
- Removal of need of RAs between RPL routers. This adds more options in the DIO messages and the conversion of DIO to RA at the leaf edge
- Pull model for DAO. This adds the capability to place one or more target option in a DIO to trigger a DAO from the sought target, actually generalizing the P2P model.

So there is really a lot of stuff in front of the group, and the problem is more that of prioritization / call for interest than it is of a lack of work to do.

Cheers,

Pascal

From: Pascal Thubert (pthubert)
Sent: mardi 10 novembre 2015 10:31
To: [email-masked]
Subject: RE: [Roll] FW: New Version Notification for draft-zhong-roll-dis-modifications-00.txt

What do people think?

Pascal

From: Roll [mailto:[email-masked]] On Behalf Of Cenk Gündogan
Sent: lundi 9 novembre 2015 21:08
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Roll] FW: New Version Notification for draft-zhong-roll-dis-modifications-00.txt

Hello *,

Best,
Cenk

Hello all,

the soliciting node.

[RFC6550] is unchanged.

its behavior.

([RFC6202]).

Best regards,

a écrit :

IETF repository.

Revision: 00

Title:            DIS Modifications

Pages:            14

URL:

.txt

Status:

Htmlized:

Abstract:

submission

The IETF Secretariat

Thank you.

Roll mailing list

---

From: Cenk Gündogan <[email-masked]>
Date: Wed, 11 Nov 2015 11:24:19 +0100

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:
>> Le 05/11/15 06:20, «[email-masked]  »<[email-masked]>
>> a écrit :
>>