Subject: Re: [Roll] Topics and drafts within Roll charter

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 8 Feb 2018 13:40:04 +0000

Hello Peter:

I encourage the WG to consider your list carefully and respond.

My personal priorities would be:

1) Item 4. This deals with actual field problems, and is a preerq for the Join Process that 6TiSCH is working on. Michael has a draft and I'm willing to contribute together with Charlie from Cisco.
2) item 2+5, seem to be the same to me. This is a rather easy work once rfc6775-update is passed and I'm willing to start/contribute

Take care,

Pascal

-----Original Message-----
From: Roll [mailto:[email-masked]] On Behalf Of peter van der Stok
Sent: lundi 9 octobre 2017 09:47
To: Roll <[email-masked]>
Subject: [Roll] Topics and drafts within Roll charter

Hi Roll,

In a discussion with Rahul and Pascal, it transpires that there are still many topics to address that fit within our charter. The proliferation of topics worries us a bit. We have only a limited number of active authors and some topics also seem to be competing. The result of this situation might be that we have an overflowing work agenda. 
Therefore, we need to find additional people to work on those topics; or reduce the number of topics.
It is our suggestion that we discuss these topics, find dedicated authors, and prioritize them  after some debate on the M-L.
Also we should like to remove the competitive subjects by joining them into one draft.

Your comments please.

Ines + Peter

------------------------ List of topics
------------------------------------------

1 Route invalidation as a standalone topics The topic is mentioned in several drafts, but we need to come to one general approach.

2.A draft that allows a ND only device to connect, be reachable and move in a RPL network.

3. Not all implementers are aware of the design issues of storing mode of RPL vs non-storing. Both of the modes have issues with their design. 
Some
issues are getting sorted out by drafts such as dao-projection and no-path DAO optimization. But still considerable design issues need to be handled. To name few:
a. handling parent switching optimally in storing MOP. Currently with Storing MOP it would lead to DIO/DAO storm in the sub-path from the child node who switches the parent. This is handled well in NS MOP (Non-storing MOP).
b. how to handle node(6ln, 6lr, lbr) reboot scenario? In some cases it is trivial, but in most cases it is not (considering dependence on several state variables such as DTSN across reboots)! Also for practical point of view, need to consider that writing to flash/NV-memory is not a good option in embedded devices and should be avoided as far as possible.
c. Problems of current DAO-ACK in storing MOP. There was a discussion on ML long time back, but there is no draft in the space.
d. problem of bulging IPv6 headers in NS MOP. Most part of this will be taken care of by SRH compression and dao-projection.

4. Confusion between DAG selection (for joining and jumping) vs. parent selection (for re-parenting within a DODAG). 6TiSCH has isolated the need for a join preference which is different from the Rank used in parent selection. The resulting Rank may be used in the join preference, but not only. The size of the DODAG, the number of children of that parent, etc... may influence. There is basically the need for a new sort of objective function, this time in order to select a DODAG to join.

5. Integration with 6LoWPAN. We need to write that draft that standardizes the procedures suggested in the 6TiSCH architecture and shows a non RPL aware joining a DODAG and moving inside. With the new 6LoWPAN ND and the NP DAO, we now have all the tools to do it. Unless we consider that the reference is the 6TiSCH architecture in which case we complete the design there.

6. Exposing (some of) the structure of the Mesh to the root to enable the DAO projection for transversal routes and in storing mode in general.

7. Using bitmaps for multicast and unicast routing, used in
  7a routing tables, or 7b in header for source routing

8. Guidance to implementers who are relatively new to RPL are not aware of many design considerations and there should be a doc which talks about it. Similar work is started in
https://tools.ietf.org/html/draft-clausen-lln-rpl-experiences-09 ... but it does not list all the issues imo.

9. What to do with expired YANG model drafts

10. What else do you think that we should consider?

--
Peter van der Stok
vanderstok consultancy
mailto: [email-masked]
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Feb 2018 12:58:18 -0500

I would like 5 minutes for two slides on:

    > 4. Confusion between DAG selection (for joining and jumping) vs. parent
    > selection (for re-parenting within a DODAG). 6TiSCH has isolated the
    > need for a join preference which is different from the Rank used in
    > parent selection. The resulting Rank may be used in the join
    > preference, but not only. The size of the DODAG, the number of children
    > of that parent, etc... may influence. There is basically the need for a
    > new sort of objective function, this time in order to select a DODAG to
    > join.

I specifically want to provide definitions for:
1) enrollment.
2) joining.
3) jumping.

I will add these definitions to:
          draft-richardson-6tisch-roll-enrollment-priority-00

(which I've renamed from draft-richardson-6tisch-roll-join-priority-02)

I've already presented the above document (was it at 98?), but still no WG adoption call.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 10 Feb 2018 11:21:36 +0200

Hi WG,

I disagree to discuss new issues before discussing our adopted drafts,
especially WGLC ones,

I suggest that our editors reply to discussions in our list, related to
adopted drafts before the ietf meeting,

I hope that this WG managers or Chairs, and the IETF chair follow up to
solve this important issue, the issue of no replies from ietf lists.

AB

On Mon, Oct 9, 2017 at 9:46 AM, peter van der Stok <[email-masked]>
wrote:

> Hi Roll,
>
> In a discussion with Rahul and Pascal, it transpires that there are still
> many topics to address that fit within our charter. The proliferation of
> topics worries us a bit. We have only a limited number of active authors
> and some topics also seem to be competing. The result of this situation
> might be that we have an overflowing work agenda. Therefore, we need to
> find additional people to work on those topics; or reduce the number of
> topics.
> It is our suggestion that we discuss these topics, find dedicated authors,
> and prioritize them  after some debate on the M-L.
> ------------------------ List of topics ------------------------------
> ------------
>
> 1 Route invalidation as a standalone topics The topic is mentioned in
> several drafts, but we need to come to one general approach.
>
> 3. Not all implementers are aware of the design issues of storing mode of
> RPL vs non-storing. Both of the modes have issues with their design. Some
> issues are getting sorted out by drafts such as dao-projection and no-path
> DAO optimization. But still considerable design issues need to be handled.
> To name few:
> a. handling parent switching optimally in storing MOP. Currently with
> Storing MOP it would lead to DIO/DAO storm in the sub-path from the child
> node who switches the parent. This is handled well in NS MOP (Non-storing
> MOP).
> b. how to handle node(6ln, 6lr, lbr) reboot scenario? In some cases it is
> trivial, but in most cases it is not (considering dependence on several
> state variables such as DTSN across reboots)! Also for practical point of
> view, need to consider that writing to flash/NV-memory is not a good
> option in
> embedded devices and should be avoided as far as possible.
> c. Problems of current DAO-ACK in storing MOP. There was a discussion on
> ML long time back, but there is no draft in the space.
> d. problem of bulging IPv6 headers in NS MOP. Most part of this will be
> taken care of by SRH compression and dao-projection.
>
> selection (for re-parenting within a DODAG). 6TiSCH has isolated the need
> for a join preference which is different from the Rank used in parent
> selection. The resulting Rank may be used in the join preference, but not
> only. The size of the DODAG, the number of children of that parent, etc...
> may influence. There is basically the need for a new sort of objective
> function, this time in order to select a DODAG to join.
>
> 5. Integration with 6LoWPAN. We need to write that draft that standardizes
> the procedures suggested in the 6TiSCH architecture and shows a non RPL
> aware joining a DODAG and moving inside. With the new 6LoWPAN ND and the NP
> DAO, we now have all the tools to do it. Unless we consider that the
> reference is the 6TiSCH architecture in which case we complete the design
> there.
>
> 6. Exposing (some of) the structure of the Mesh to the root to enable the
> DAO projection for transversal routes and in storing mode in general.
>
> 8. Guidance to implementers who are relatively new to
> RPL are not aware of many design considerations and there should be a doc
> which talks about it. Similar work is started in

---

From: Rahul Jadhav <[email-masked]>
Date: Mon, 12 Feb 2018 09:32:19 +0530

Hello ROLL,

Last week we had uploaded an ID "
https://datatracker.ietf.org/doc/draft-rahul-roll-rpl-observations/" inline
to what was promised in IETF100. (Strange the new ID notification was not
sent out to ROLL ML (?),, but the ID is actually uploaded!).
The draft is informational and describes issues related to existing
handling in RPL which either seems incomplete, ambiguous and may need
attention. It is possible that some of the issues already have some
existing solution which we would like to understand.
Please note that all the issues mentioned in the draft are related to
existing 6550 handling. Also many of those issues are pertaining to storing
MOP and we wanted to put out our understanding out there so as to get any
feedback from other implementers.

Thanks,
Rahul

On 8 February 2018 at 19:10, Pascal Thubert (pthubert) <[email-masked]>
wrote:

> 1) Item 4. This deals with actual field problems, and is a preerq for the
> Join Process that 6TiSCH is working on. Michael has a draft and I'm willing
> to contribute together with Charlie from Cisco.
> 2) item 2+5, seem to be the same to me. This is a rather easy work once
> rfc6775-update is passed and I'm willing to start/contribute
>
> Take care,
>
> Pascal
>
> might be that we have an overflowing work agenda.
> view, need to consider that writing to flash/NV-memory is not a good option
> in embedded devices and should be avoided as far as possible.
> 8. Guidance to implementers who are relatively new to RPL are not aware of
> many design considerations and there should be a doc which talks about it.
> Similar work is started in

---

From: peter van der Stok <[email-masked]>
Date: Mon, 12 Feb 2018 09:04:38 +0100

Hi Abdul,

Indeed, not all authors reply as quickly to reviews as one should wish.
There are several reasons for this, such as extra work load by employer, 
disappearing interest, etc..
As a WG we should be aware that our work is a composition of 
contributions by individual authors.

This being so, dependent on importance of topic, time spent by the 
authors, responsiveness by WG, and others, drafts will proceed in their 
own tempo (or leisure).

It is a bad idea to stop all WG progress on all topics, because some 
drafts have a very slow progress.
Drafts with little activity will finally disappear, while the WG as such 
needs to make progress.

There are two concerns that I have at the moment and that I want to 
discuss during ietf101:
- Making sure that all (current and future) drafts which discuss parent 
selection, ranking, or dodag selection, clarify the chosen metric and 
that the different metrics can co-exist or exclude each other during RPL 
operation.
- Making sure that there are enough authors and reviewers to advance 
this subject

I hope this clarifies the wish for a discussion during ietf101.

Peter

Abdussalam Baryun schreef op 2018-02-10 10:21:
> I suggest that our editors reply to discussions in our list, related
> to adopted drafts before the ietf meeting,
> 
> I hope that this WG managers or Chairs, and the IETF chair follow up
> to solve this important issue, the issue of no replies from ietf
> lists.
> 
> AB
> 
> On Mon, Oct 9, 2017 at 9:46 AM, peter van der Stok
> <[email-masked]> wrote:
> 
>> Hi Roll,
>> 
>> In a discussion with Rahul and Pascal, it transpires that there are
>> still many topics to address that fit within our charter. The
>> proliferation of topics worries us a bit. We have only a limited
>> number of active authors and some topics also seem to be competing.
>> The result of this situation might be that we have an overflowing
>> work agenda. Therefore, we need to find additional people to work on
>> those topics; or reduce the number of topics.
>> It is our suggestion that we discuss these topics, find dedicated
>> authors, and prioritize them  after some debate on the M-L.
>> 1 Route invalidation as a standalone topics The topic is mentioned
>> in several drafts, but we need to come to one general approach.
>> 
>> DAO optimization. But still considerable design issues need to be
>> handled. To name few:
>> 4. Confusion between DAG selection (for joining and jumping) vs.
>> parent selection (for re-parenting within a DODAG). 6TiSCH has
>> isolated the need for a join preference which is different from the
>> Rank used in parent selection. The resulting Rank may be used in the
>> join preference, but not only. The size of the DODAG, the number of
>> children of that parent, etc... may influence. There is basically
>> the need for a new sort of objective function, this time in order to
>> select a DODAG to join.
>> 
>> 5. Integration with 6LoWPAN. We need to write that draft that
>> standardizes the procedures suggested in the 6TiSCH architecture and
>> shows a non RPL aware joining a DODAG and moving inside. With the
>> new 6LoWPAN ND and the NP DAO, we now have all the tools to do it.
>> Unless we consider that the reference is the 6TiSCH architecture in
>> which case we complete the design there.
>> 
>> 6. Exposing (some of) the structure of the Mesh to the root to
>> enable the DAO projection for transversal routes and in storing mode
>> in general.
>> 
>> RPL are not aware of many design considerations and there should be
>> a doc which talks about it. Similar work is started in
>> https://tools.ietf.org/html/draft-clausen-lln-rpl-experiences-09 [1]
>> ... but
>> it does not list all the issues imo.
>> 
>> www: www.vanderstok.org [2]
>> tel NL: +31(0)492474673 [3]     F: +33(0)966015248 [4]
>> 
>> https://www.ietf.org/mailman/listinfo/roll [5]
> 
> 
> 
> Links:
> ------
> [1] https://tools.ietf.org/html/draft-clausen-lln-rpl-experiences-09
> [2] http://www.vanderstok.org
> [3] tel:%2B31%280%29492474673
> [4] tel:%2B33%280%29966015248
> [5] https://www.ietf.org/mailman/listinfo/roll

---

From: peter van der Stok <[email-masked]>
Date: Mon, 12 Feb 2018 09:07:26 +0100

Hi Rahul,

> Last week we had uploaded an ID
> "https://datatracker.ietf.org/doc/draft-rahul-roll-rpl-observations/"
> inline to what was promised in IETF100. (Strange the new ID
> notification was not sent out to ROLL ML (?),, but the ID is actually
> uploaded!).

Not strange,
For individual drafts, you may send out the notification to the whole 
WG.
For WG drafts(ietf- in title) notification is distributed automatically 
to the WG.

Peter

---

From: Rahul Jadhav <[email-masked]>
Date: Mon, 12 Feb 2018 13:53:02 +0530

>
>
> Not strange,
> For individual drafts, you may send out the notification to the whole WG.
> For WG drafts(ietf- in title) notification is distributed automatically to
> the WG.

ohk! Thanks for clarifying.

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 14 Feb 2018 06:37:18 +0200

On Mon, Feb 12, 2018 at 6:02 AM, Rahul Jadhav <[email-masked]> wrote:

> Hello ROLL,
>
> Last week we had uploaded an ID "https://datatracker.ietf.org/
> doc/draft-rahul-roll-rpl-observations/" inline to what was promised in
> IETF100. (Strange the new ID notification was not sent out to ROLL ML (?),,
> but the ID is actually uploaded!).
>

Yes I think it is strange that it was not sent to this important list

I suggest that this needs to be solved by IESG or the AD responsible or the
WG chairs, so this does not happen again in future,

The draft is informational

The draft is not informational please check it again,

> and describes issues related to existing handling in RPL which either
> seems incomplete, ambiguous and may need attention. It is possible that
> some of the issues already have some existing solution which we would like
> to understand.

I am still waiting fo feedback related to an adapted draft and which is in
LC, related to issues,

>
> Thanks,
> Rahul
>
> On 8 February 2018 at 19:10, Pascal Thubert (pthubert) <[email-masked]
> > wrote:
>
>> Hello Peter:
>>
>> issues are getting sorted out by drafts such as dao-projection and
>> no-path DAO optimization. But still considerable design issues need to be
>> handled. To name few:
>> standardizes the procedures suggested in the 6TiSCH architecture and shows
>> a non RPL aware joining a DODAG and moving inside. With the new 6LoWPAN ND
>> and the NP DAO, we now have all the tools to do it. Unless we consider that
>> the reference is the 6TiSCH architecture in which case we complete the
>> design there.
>>
>> 8. Guidance to implementers who are relatively new to RPL are not aware
>> of many design considerations and there should be a doc which talks about
>> it. Similar work is started in
>> tel NL: +31(0)492474673 <+31%20492%20474%20673>     F: +33(0)966015248
>> <+33%209%2066%2001%2052%2048>
>>

---

From: Rahul Jadhav <[email-masked]>
Date: Wed, 14 Feb 2018 10:18:33 +0530

> The draft is not informational please check it again,

Oh Yes, I ll fix this in 01 ver. Thanks

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 14 Feb 2018 06:59:31 +0200

Hi Peter and Ines,

I thank you for your respond, and I think that WG chair
guidance/discussions are always important for any WG list, not only for
IETF lists. My comments below,

> Indeed, not all authors reply as quickly to reviews as one should wish.

I know that, but not a month, I think a month is a very very long time,
what do you think? However, I think that the WG chair/AD should follow up
with items that are related to WG LC drafts.

> As a WG we should be aware that our work is a composition of contributions
> by individual authors.
>

I don't think that is a good excuse for IETF business, because we have
managers in IETF, amanager should follow up and push the work or find who
can help. No one asked me to help or no author asked the WG participants
that they need help. If authors don't ask for help, they MUST not hold our
draft or the draft we adopted. The IESG MUST solve this issue, and SHOULD
find a better way to make WG lists respond to serious people/participats.

> authors, responsiveness by WG, and others, drafts will proceed in their own
> tempo (or leisure).
>

I never like to stop any thing, but we need to agree/discuss on priorities,
any IETF WG should discuss all issues, but some WGs discuss off lines or in
the face to face meeting. While I don't do meeting, I am concerned by WG
list or our ROLL list.

> Drafts with little activity will finally disappear, while the WG as such

I know, but the WG chair should comment on the list for such issue when
appears. Please note that in this comment I am not against any, but just
discussing for best practice,

> selection, ranking, or dodag selection, clarify the chosen metric and that
> the different metrics can co-exist or exclude each other during RPL
> operation.
> - Making sure that there are enough authors and reviewers to advance this
> subject
>

Yes, hope you/authors contact me if there is any draft needs
co-authoring/assistant, while some authors are bussy as you mentioned. So
we need to make things faster/acurate by sharing load.

AB

Africa Region

(above using SHOLD or MUST is not shouting, just like to use more clear
wording)

Peter
>>> no-path