Subject: Re: [Roll] Request for Comments for ROLL Charter

From: Ines Robles <[email-masked]>
Date: Mon, 4 Jul 2016 16:26:20 +0300

Dear all,

Thank you very much for your comments, we send a new version of the charter.

Last changes:

a- We  would keep the old paragraphs, might them be helpful for newcomers.

b- Remove "AD approval is required for each new work item that is
proposed." since it is part of the process anyway.

c - Two work items were modified:

  c.1-  Old: " Additional protocol to  reduce paths for RPL in non-storing
mode"
New: "Additional protocol elements to reduce packet size and the amount of
required routing states"

c.2 - Old: " Methods to improve or correct  the current RPL behaviour such
as DIS modifications and problems associated with DAO messaging in RPL"

New: "" Methods to improve or correct  the current RPL behaviour and the
other protocols defined by the working group.

Please comments,

Thank you,

Peter and Ines

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

CHARTER PROPOSAL:

Charter for Working Group

Low power and Lossy Networks (LLNs ) [RFC7102] [RFC7228] are made up of
many embedded devices with limited power, memory, and processing resources.
They are interconnected by a variety of links, such as IEEE 802.15.4,
Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline
Communication) links. LLNs are transitioning to an end-to-end IP-based
solution to avoid the problem of non-interoperable networks interconnected
by protocol translation gateways and proxies.

Generally speaking, LLNs are characterized as follows, but not limited to:

LLNs operate with a hard, very small bound on state.

In most cases, LLN optimize for saving energy by using small packet headers
and reduce amount of control packets.

Typical traffic patterns are not simply unicast flows (e.g. in some cases
most if not all traffic can be point to multipoint).

In most cases, LLNs will be employed over link layers with restricted
frame-sizes and low bit rates, thus a routing protocol for LLNs should be
specifically adapted for such link layers.

LLN routing protocols have to be very careful when trading off efficiency
for generality; since LLN nodes do not have resources to waste.

These specific properties cause LLNs to have specific routing requirements.

Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been
evaluated by the working group (draft-levis-roll-overview-protocols-00) and
have in their current form been found to not satisfy all of these specific
routing requirements “Routing Requirements for Urban Low-Power and Lossy
Networks” RFC 5548, “Industrial Routing Requirements in Low-Power and Lossy
Networks” RFC 5673, “Home Automation Routing Requirements in Low-Power and
Lossy Networks” RFC 5826, Building Automation Routing Requirements in
Low-Power and Lossy Networks RFC 5867.

The Working Group is focused on routing issues for LLN and maintaining the
protocols developed by the working group.

There is a wide scope of application areas for LLNs, including industrial
monitoring, building automation (HVAC, lighting, access control, fire),
connected homes, health care, environmental monitoring, urban sensor
networks (e.g. Smart Grid), asset tracking. The Working Group focuses on
routing solutions for a subset of these: connected home, building and urban
sensor networks for which routing requirements have been specified. These
application-specific routing requirement documents were used for protocol
design.

The Working Group focuses on IPv6 routing architectural framework for these
application scenarios. The Framework will take into consideration various
aspects including high reliability in the presence of time varying loss
characteristics and connectivity while permitting low-power operation with
very modest memory and CPU pressure in networks potentially comprising a
very large number (several thousands) of nodes.

The Working Group will document how data packets are routed and
encapsulated when they cross the LLN, and when they enter and exit the LLN:
the appropriate use of RPI (RFC6553), RH3 (RFC6554) and IPv6-in-IPv6
encapsulation including how routing loops are detected. In consultation
with the 6lo WG, the Working Group will design a method to compress these
routing headers into a single block. The WGLC on this work will be shared
with 6lo. The Working group will align with the 6man WG when needed.

ROLL is responsible for maintenance of the protocols that is has developed,
including RPL and MPL.

Work Items are:

- Guidance in using RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation.

- Compression of  RFC6553, RFC6554, and IP headers in the 6LoWPAN
adaptation layer context

- Additional protocol elements to reduce packet size and the amount of
required routing states

- Automatic selection of MPL forwarders to reduce message replication

- Data models for RPL and MPL management

- Alternative Multicast algorithm based on Bier forwarding.

- Methods to improve or correct  the current RPL behaviour and the other
protocols defined by the working group.

Milestones

DATE                            Milestone

September 2017            Recharter WG or close

March 2017           Initial submission of draft about YANG RPL model to
IESG

January 2017         Initial submission of draft about MPL selection to IESG

November 2016        Initial submission of draft about Bier Multicast to
IESG

October 2016         Submit draft about YANG MPL model to IESG

August 2016          Initial Submission of the draft about when to use
RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation
Draft-ietf-roll-useofrplinfo to the IESG.

May 2016             Initial submission of the draft about how to compress
RFC6553, RFC6554, and IP headers in the 6LoWPAN adaptation layer context.
 to the IESG. draft-ietf-roll-routing-dispatch
November 2016        Initial Submission of the No-Path DAO Problem
Statement to the IESG

2016-06-30 12:11 GMT+03:00 peter van der Stok <[email-masked]>:

> Hi Cenk,
>
> thanks for your suggestions.
> I cannot refrain from reacting, and see below.
>
> Cenk Gündogan schreef op 2016-06-29 17:04:
>
>> Hello Peter,
>>
>> I believe Pascal proposed to keep it in a more generic form
>> "improvements to the RPL routing protocol".
>>
>> Otherwise, read on for my comments regarding the former wording:
>> I propose we drop any form of uncertainty and change the "and/or" to
>> "and".
>>
>
> much better.
>
> Secondly, "packet size" sounds a little bit too generic, how about
>> "control packet sizes",
>> or "RPL related packet sizes"?
>>
>
> I was also thinking of the headers, and IP in IP headers; and whatever may
> come; so I prefer packet size (NOT to be confused with payload size)
> It looks general and still concrete enough.
>
> Thirdly, would "reduce ... the amount of required routing states"
>> be a better choice? It hints to a reduction of memory while still
>> providing an
>> operational (converged) DODAG.
>> The proposed form "reduce ... the amount of accumulated routing
>> states" could also
>> refer to drop states and decrease the quality of the routing protocol
>> while doing so.
>>
>
> required it is
>
>
>> Cenk
>>
>>
> Other suggestions or improvements?
>
> If not we send new text on monday/tuesday.
>
> Peter
>
> On 06/29/2016 09:05 AM, peter van der Stok wrote:
>>
>>> Hi All,
>>>
>>> If I understand correctly the discussion, the proposal is to replace
>>>
>>> "Additional protocol to  reduce paths for RPL in non-storing mode."
>>>
>>> by
>>>
>>> "Additional protocol elements to reduce packet size and/or the amount of
>>> accumulated routing states."
>>>
>>>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 6 Jul 2016 12:41:13 +0000

Hello Ines:

About

-         Compression of  RFC6553, RFC6554, and IP headers in the 6LoWPAN adaptation layer context

I think it is time to work on compressing RPL DIOs and DAOs as well, wouldn’t you say?

Pascal

From: Roll [mailto:[email-masked]] On Behalf Of Ines Robles
Sent: lundi 4 juillet 2016 15:26
To: roll <[email-masked]>
Cc: peter van der Stok <[email-masked]>; Michael Richardson <[email-masked]>
Subject: Re: [Roll] Request for Comments for ROLL Charter

Dear all,

Last changes:

b- Remove "AD approval is required for each new work item that is proposed." since it is part of the process anyway.

  c.1-  Old: " Additional protocol to  reduce paths for RPL in non-storing mode"
New: "Additional protocol elements to reduce packet size and the amount of required routing states"

c.2 - Old: " Methods to improve or correct  the current RPL behaviour such as DIS modifications and problems associated with DAO messaging in RPL"

New: "" Methods to improve or correct  the current RPL behaviour and the other protocols defined by the working group.

Please comments,

Thank you,

Peter and Ines

CHARTER PROPOSAL:

Low power and Lossy Networks (LLNs ) [RFC7102] [RFC7228] are made up of many embedded devices with limited power, memory, and processing resources. They are interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline Communication) links. LLNs are transitioning to an end-to-end IP-based solution to avoid the problem of non-interoperable networks interconnected by protocol translation gateways and proxies.

In most cases, LLN optimize for saving energy by using small packet headers and reduce amount of control packets.

Typical traffic patterns are not simply unicast flows (e.g. in some cases most if not all traffic can be point to multipoint).

In most cases, LLNs will be employed over link layers with restricted frame-sizes and low bit rates, thus a routing protocol for LLNs should be specifically adapted for such link layers.

LLN routing protocols have to be very careful when trading off efficiency for generality; since LLN nodes do not have resources to waste.

Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been evaluated by the working group (draft-levis-roll-overview-protocols-00) and have in their current form been found to not satisfy all of these specific routing requirements “Routing Requirements for Urban Low-Power and Lossy Networks” RFC 5548, “Industrial Routing Requirements in Low-Power and Lossy Networks” RFC 5673, “Home Automation Routing Requirements in Low-Power and Lossy Networks” RFC 5826, Building Automation Routing Requirements in Low-Power and Lossy Networks RFC 5867.

The Working Group is focused on routing issues for LLN and maintaining the protocols developed by the working group.

There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (HVAC, lighting, access control, fire), connected homes, health care, environmental monitoring, urban sensor networks (e.g. Smart Grid), asset tracking. The Working Group focuses on routing solutions for a subset of these: connected home, building and urban sensor networks for which routing requirements have been specified. These application-specific routing requirement documents were used for protocol design.

The Working Group focuses on IPv6 routing architectural framework for these application scenarios. The Framework will take into consideration various aspects including high reliability in the presence of time varying loss characteristics and connectivity while permitting low-power operation with very modest memory and CPU pressure in networks potentially comprising a very large number (several thousands) of nodes.

The Working Group will document how data packets are routed and encapsulated when they cross the LLN, and when they enter and exit the LLN: the appropriate use of RPI (RFC6553), RH3 (RFC6554) and IPv6-in-IPv6 encapsulation including how routing loops are detected. In consultation with the 6lo WG, the Working Group will design a method to compress these routing headers into a single block. The WGLC on this work will be shared with 6lo. The Working group will align with the 6man WG when needed.

ROLL is responsible for maintenance of the protocols that is has developed, including RPL and MPL.

Work Items are:

- Compression of  RFC6553, RFC6554, and IP headers in the 6LoWPAN adaptation layer context

- Additional protocol elements to reduce packet size and the amount of required routing states

- Methods to improve or correct  the current RPL behaviour and the other protocols defined by the working group.

Milestones

DATE                            Milestone

March 2017           Initial submission of draft about YANG RPL model to IESG

November 2016        Initial submission of draft about Bier Multicast to IESG

August 2016          Initial Submission of the draft about when to use RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation Draft-ietf-roll-useofrplinfo to the IESG.

May 2016             Initial submission of the draft about how to compress RFC6553, RFC6554, and IP headers in the 6LoWPAN adaptation layer context.  to the IESG. draft-ietf-roll-routing-dispatch
November 2016        Initial Submission of the No-Path DAO Problem Statement to the IESG

2016-06-30 12:11 GMT+03:00 peter van der Stok <[email-masked]<mailto:[email-masked]>>:
Hi Cenk,

Otherwise, read on for my comments regarding the former wording:
I propose we drop any form of uncertainty and change the "and/or" to "and".

much better.

I was also thinking of the headers, and IP in IP headers; and whatever may come; so I prefer packet size (NOT to be confused with payload size)
It looks general and still concrete enough.
Thirdly, would "reduce ... the amount of required routing states"
be a better choice? It hints to a reduction of memory while still providing an
operational (converged) DODAG.
The proposed form "reduce ... the amount of accumulated routing
states" could also
refer to drop states and decrease the quality of the routing protocol
while doing so.

required it is

Cenk

Peter

by

"Additional protocol elements to reduce packet size and/or the amount of accumulated routing states."

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Jul 2016 10:54:08 -0400

> I think it is time to work on compressing RPL DIOs and DAOs as well,

I did some work some time ago (2012?) using GHC on RPL messages, and the result was
very encouraging.

To me, it just fits into the maintenance of the specification.
We don't need to list every single thing unless there will be a series of
milestones associated with the work.

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

---

From: peter van der Stok <[email-masked]>
Date: Wed, 06 Jul 2016 17:51:45 +0200

> milestones associated with the work.

I sympathize with Michael's remark.
Is there an associated milestone before June 2017?
The idea is to have a limited set of concrete subjects with 
corresponding realistic milestones

Peter

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Jul 2016 14:02:03 -0400

peter van der Stok <[email-masked]> wrote:
    >> To me, it just fits into the maintenance of the specification.  We
    >> don't need to list every single thing unless there will be a series of

    > I sympathize with Michael's remark.  Is there an associated milestone
    > before June 2017?  The idea is to have a limited set of concrete
    > subjects with corresponding realistic milestones

I'm not sure if I'm answering your ? or just emphasizing the point...

I said: "series of milestones" here.

If we are taking on work that is more than a single document, then I think we
need IESG and charter support.  If it's just a single document, and it shows
up, then when we adopt it, we insert a milestone.

---

From: peter van der Stok <[email-masked]>
Date: Thu, 07 Jul 2016 09:21:49 +0200

We seem to be in agreement.
I just wanted to emphasize that when detailed concrete subjects with 
associated draft turn up, we make this clear in the milestones.
Which means that the list of subjects can be more general.
And indeed, not everything we have in mind needs a milestone now.

I was not thinking about IESG approval procedures.

Peter

Michael Richardson schreef op 2016-07-06 20:02:
> We

---

From: Ines Robles <[email-masked]>
Date: Fri, 8 Jul 2016 16:30:53 +0300

Hi,

Pascal, about this:

"I think it is time to work on compressing RPL DIOs and DAOs as well,
wouldn’t you say?" - Very nice would be to have some work on that :-)

Would it be inside of this proposed work item: "Additional protocol
elements to reduce packet size and the amount of required routing states"?.
I think it agrees what Michael suggested.

Additionally, about milestones/work-items:

"...Every WG has milestones that the WG is
   supposed to meet, such as the publication of a particular Internet-
   Draft or the beginning of discussion on a particular topic.  A WG's
   charter has several parts; one of those parts is the milestones.
   Changing milestones currently requires Area Director (AD) approval,
   but changing the charter text requires IESG approval.....
   ...
 ...While most milestones map one-to-one with Internet-Drafts,
   some milestones do not map to any Internet-Draft (such as those that
   say when a general discussion will begin or finish), and other
   milestones map to multiple Internet-Drafts (such as a milestone that
   covers a topic that has multiple related Internet-Drafts).  Some
   Internet-Drafts are part of more than one milestone." [RFC 6433]

In here:

"...Goals and milestones
      The working group charter MUST establish a timetable for specific
      work items.  While this may be renegotiated over time, the list of
      milestones and dates facilitates the Area Director's tracking of
      working group progress and status, and it is indispensable to
      potential participants identifying the critical moments for input.
      Milestones shall consist of deliverables that can be qualified as
      showing specific achievement; e.g., "Internet-Draft finished" is
      fine, but "discuss via email" is not. It is helpful to specify
      milestones for every 3-6 months, so that progress can be gauged
      easily.  This milestone list is expected to be updated
      periodically..." [RFC 2418] -- I understand here that milestones and
work items are the same.

Cheers,

Ines.