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

["Pascal Thubert (pthubert)" <[e-mail]>]

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:[e-mail]] On Behalf Of Cenk Gündogan
Sent: lundi 9 novembre 2015 21:08
To: [e-mail]
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, [e-mail]<mailto:[e-mail]> 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, « [e-mail]<mailto:[e-mail]> » <[e-mail]><mailto:[e-mail]>

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

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/roll