Subject: [Roll] DIS-modifications use cases; Re: FW: New Version Notification for draft-ietf-roll-dis-modifications-01.txt

From: <[email-masked]>
Date: Mon, 24 Feb 2020 16:52:35 +0000

Dear Rollers,

In preparation for the modification of the DIS (DODAG Information
Solicitation), we are collecting the use cases.
We want to make sure we understand all the requirements before crafting a
solution.
Georgios has kindly prepared a document on the ROLL GitHub repo.
See a text rendition at
https://github.com/roll-wg/roll-dis-modifications-use-cases/blob/master/dra
ft-papadopoulos-roll-dis-modifications-use-cases.txt
Currently, the document has two use cases:
- a new node joins an established RPL network. The use case calls for a
fairly quick confirmation that the node has joined with a good quality
path. However, we don't want to reset the Trickle timers of all nearby
routers and trigger broadcast, since the use case is that just one new
node was added/replaced/rebooted.
- another use case is that several nodes join at about the same time (e.g.
electricity meters all reboot following power outage). We want the DIOs to
be sent with broadcast so that all joining nodes benefit from them.
The draft draft-thubert-roll-eliding-dio-information-03 has another
request for modifying the DIS. We'll soon incorporate it into the use
cases document.
If you have yet another need for modifications in the DIS, please tell us
what the use case is.
The intent is to publish the draft in time for presentation/discussion at
Vancouver.
Thanks

Dominique

Le 21/11/19 17:02, « Roll on behalf of [email-masked] »
<[email-masked] on behalf of [email-masked]> a écrit :

>Hello all,
>
>In light of the current discussions on adding flags and generally
>improving the behavior of DIS messages, I've just republished the old
>dis-modifications draft with Informational status.
>The purpose is to provide the WG with the use cases that were described in
>that draft.
>Except for the issue date and version, the draft is unchanged from -00.
>Best regards,
>
>Dominique
>
>Le 21/11/19 16:57, « [email-masked] » <[email-masked]>
>a écrit :
>
>>
>>A new version of I-D, draft-ietf-roll-dis-modifications-01.txt
>>has been successfully submitted by Dominique Barthel and posted to the
>>IETF repository.
>>
>>Name:		draft-ietf-roll-dis-modifications
>>Revision:	01
>>Title:		DIS Modifications
>>Document date:	2019-11-21
>>Group:		roll
>>Pages:		15
>>URL:            
>>https://www.ietf.org/internet-drafts/draft-ietf-roll-dis-modifications-01
>>.
>>txt
>>Status:         
>>https://datatracker.ietf.org/doc/draft-ietf-roll-dis-modifications/
>>Htmlized:       
>>https://tools.ietf.org/html/draft-ietf-roll-dis-modifications-01
>>Htmlized:       
>>https://datatracker.ietf.org/doc/html/draft-ietf-roll-dis-modifications
>>Diff:           
>>https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-dis-modifications-01
>>
>>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,
>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 authorisation.
>If you have received this email in error, please notify the sender and
>delete this message and its attachments.
>As emails may be altered, Orange is not liable for messages that have
>been modified, changed or falsified.
>Thank you.
>
>_______________________________________________
>Roll mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/roll

_________________________________________________________________________________________________________________________

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,
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 authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Rahul Jadhav <[email-masked]>
Date: Tue, 25 Feb 2020 11:08:27 +0530

On Mon, 24 Feb 2020 at 22:22, <[email-masked]> wrote:

> <https://github.com/roll-wg/roll-dis-modifications-use-cases/blob/master/draft-papadopoulos-roll-dis-modifications-use-cases.txt>

[RJ] Thanks Georgios. This surely helps. I am assuming that the use-cases
text will get merged in the dis-modifications draft.
One point mentioned in the use-cases draft is that unicast DIS can request
__specific__ metric information from the parent. Currently, the parent
sends the complete metric set to the child using unicast DIO. Wondering
whether we need this mechanism for sending specific metric info back to the
child node. The draft does not give a use-case for this. Anyways, this
would be discussed when the drafts get merged and sent to the group.

> request for modifying the DIS. We'll soon incorporate it into the use

[RJ] Another use-case is of "adjacency probing". While (I believe) no new
primitives need to be added, still the use-case is well-worth mentioning.
The RPL-observations draft points to this use-case and you can pick some
text from there.

---

From: <[email-masked]>
Date: Tue, 25 Feb 2020 07:43:46 +0000

Hello Rahul, all,

Thanks, Rahul,  for your contribution, this is helpful!
WG, others ideas, comments?
Best regards

Dominique

De : Roll <[email-masked]<mailto:[email-masked]>> on behalf of Rahul Jadhav <[email-masked]<mailto:[email-masked]>>
Répondre à : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date : Tuesday 25 February 2020 06:38
À : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : Re: [Roll] DIS-modifications use cases; Re: FW: New Version Notification for draft-ietf-roll-dis-modifications-01.txt

On Mon, 24 Feb 2020 at 22:22, <[email-masked]<mailto:[email-masked]>> wrote:
Dear Rollers,

ft-papadopoulos-roll-dis-modifications-use-cases.txt<https://github.com/roll-wg/roll-dis-modifications-use-cases/blob/master/draft-papadopoulos-roll-dis-modifications-use-cases.txt>

[RJ] Thanks Georgios. This surely helps. I am assuming that the use-cases text will get merged in the dis-modifications draft.
One point mentioned in the use-cases draft is that unicast DIS can request __specific__ metric information from the parent. Currently, the parent sends the complete metric set to the child using unicast DIO. Wondering whether we need this mechanism for sending specific metric info back to the child node. The draft does not give a use-case for this. Anyways, this would be discussed when the drafts get merged and sent to the group.

[RJ] Another use-case is of "adjacency probing". While (I believe) no new primitives need to be added, still the use-case is well-worth mentioning. The RPL-observations draft points to this use-case and you can pick some text from there.