Subject: [Roll] Request for Comments for ROLL Charter

From: Ines Robles <[email-masked]>
Date: Tue, 21 Jun 2016 19:27:16 +0300

Dear all,

Please find a draft of the working group charter.

Please review and comments. It would be good to have your comments before
IETF 96.

Thank you very much in advance,

Peter and Ines

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

Charter for Working Group

Low power and Lossy Networks (LLNs) 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 few 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 RH3 (RFC6553), RPI (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. AD approval is required for each new work item that
is proposed.

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 to  reduce paths for RPL in non-storing mode

- Automatic selection of MPL forwarders to reduce message replication

- Data models for RPL and MPL management

- Alternative Multicast algorithm based on Bier forwarding.

- Solution  of  the  problems associated with the use of No- Path DAO
messaging in RPL.

- Methods to improve the current RPL behaviour, e.g. DIS modifications in
RPL.

Milestones                                        DATE

Recharter WG or close                   September 2017

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

Initial submission of draft about MPL selection to IESG    January 2017

Initial submission of draft about Bier Multicast to IESG      November 2016

Submit draft about YANG MPL model to IESG     October 2016

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

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

Initial Submission of the No-Path DAO Problem Statement to the IESG
November 2016

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

---

From: Cenk Gündogan <[email-masked]>
Date: Wed, 22 Jun 2016 10:27:49 +0200

Hello Ines,Peter,

the proposed charter looks great as it is,
however, I have a few remarks and questions that Iinlined below.

Thanks!

Best,
Cenk

On 06/21/2016 06:27 PM, Ines Robles wrote:
> Please review and comments. It would be good to have your comments 
> before IETF 96.
>
> Low power and Lossy Networks (LLNs) are made up of many embedded 
> devices with limited

 > Should we reference RFC7228: "Terminology for Constrained-Node 
Networks" here to have
a consistent and common definition of the term LLN?

> 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.
>
> -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.
>
> encapsulated when they cross the LLN, and when they enter and exit the 
> LLN: the appropriate use of RH3 (RFC6553),

 > It should be the other way around: RH3 is RFC6554 and RPI is RFC6553

> RPI (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. AD approval is required for each new 
> work item that is proposed.
>
> Work Items are:
>

 > I remember a discussion on the mailing list about DAO/DAO-ACK being 
very underspecified,
which in turn may lead to non-interoperability between different 
implementations.
Should we use a more general wording here for the DAO handling, instead 
of just concentrating on the No-Path DAO?
For reference: 
https://www.ietf.org/mail-archive/web/roll/current/msg09449.html

>
> - Methods to improve the current RPL behaviour, e.g. DIS modifications 
> in RPL.
>
>
> Milestones                                        DATE
>
> Initial Submission of the draft about when to use RFC6553, RFC6554, 
> and IPv6-in-IPv6 encapsulation     August 2016
> Initial submission of the draft about how to compress RFC6553, 
> RFC6554, and IP headers in the 6LoWPAN adaptation layer context.  to 
> the IESG.    May 2016
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Rahul Arvind Jadhav (Rahul Arvind Jadhav, 2012 Labs)" <[email-masked]>
Date: Thu, 23 Jun 2016 03:56:40 +0000

Thanks Peter, Ines,

The updated charter looks good to me.

And as I understand work items related to RPL maintenance can be incorporated depending upon the proposals received.
E2E-ACK discussion that happened on the ML was an important discussion and based on my understanding of that work, if proposed, will be relevant to maintenance activity. Thanks Cenk for bringing it up and I hope that work gets going.

Regards,
Rahul

From: Roll [mailto:[email-masked]] On Behalf Of Cenk Gündogan
Sent: 22 June 2016 PM 01:58
To: [email-masked]
Subject: Re: [Roll] Request for Comments for ROLL Charter

Hello Ines, Peter,

the proposed charter looks great as it is,
however, I have a few remarks and questions that I inlined below.

Thanks!

Best,
Cenk

Please review and comments. It would be good to have your comments before IETF 96.

Peter and Ines

Low power and Lossy Networks (LLNs) are made up of many embedded devices with limited

> Should we reference RFC7228: "Terminology for Constrained-Node Networks" here to have

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 few 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 RH3 (RFC6553),

> It should be the other way around: RH3 is RFC6554 and RPI is RFC6553

RPI (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. AD approval is required for each new work item that is proposed.

Work Items are:

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

- Solution  of  the  problems associated with the use of No- Path DAO messaging in RPL.

> I remember a discussion on the mailing list about DAO/DAO-ACK being very underspecified,
which in turn may lead to non-interoperability between different implementations.
Should we use a more general wording here for the DAO handling, instead of just concentrating on the No-Path DAO?
For reference: https://www.ietf.org/mail-archive/web/roll/current/msg09449.html

- Methods to improve the current RPL behaviour, e.g. DIS modifications in RPL.

Milestones                                        DATE

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

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

Initial Submission of the No-Path DAO Problem Statement to the IESG     November 2016

Roll mailing list

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

---

From: Ines Robles <[email-masked]>
Date: Thu, 23 Jun 2016 09:58:47 +0300

Thank you very much Cenk and Rahul for your comments!! :-)

Please find attached the new charter including the corrections suggested by
Cenk.

Please comment,

Cheers,

Peter and Ines.

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

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.

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.

the appropriate use of RPI (RFC6553), RH3 (RFC6554) and IPv6-in-IPv6

Work Items are:

-  Methods to improve or correct  the current RPL behaviour such as DIS
modifications and problems associated with DAO messaging in RPL

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-23 6:56 GMT+03:00 Rahul Arvind Jadhav (Rahul Arvind Jadhav, 2012
Labs) <[email-masked]>:

> And as I understand work items related to RPL maintenance can be
> incorporated depending upon the proposals received.
>
> E2E-ACK discussion that happened on the ML was an important discussion and
> based on my understanding of that work, if proposed, will be relevant to
> maintenance activity. Thanks Cenk for bringing it up and I hope that work
> gets going.
>
>
>
> Regards,
>
> Rahul
>
>
>
> *From:* Roll [mailto:[email-masked]] *On Behalf Of *Cenk Gündogan
> *Sent:* 22 June 2016 PM 01:58
> *To:* [email-masked]
> *Subject:* Re: [Roll] Request for Comments for ROLL Charter
>
>
>
> Hello Ines, Peter,
>
> with limited
> 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.
>
>
>
> 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 appropriate use of RH3 (RFC6553),
>
>
> RPI (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.
>
> developed, including RPL and MPL. AD approval is required for each new work
> item that is proposed.
>
>
>
> Work Items are:
>
>
>
> Initial submission of the draft about how to compress RFC6553, RFC6554,
> and IP headers in the 6LoWPAN adaptation layer context.  to the IESG.
>  May 2016
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 27 Jun 2016 14:52:56 +0000

Hello Ines and Peter:

I’m happy with this proposed charter. On this particular item, though,
“
Additional protocol to  reduce paths for RPL in non-storing mode
“

I’ll note that methods that rely on BIER or on Bloom filters to make routing more efficient were already discussed and should be accommodated. Proposal:
“
Additional protocol elements to reduce source route headers in non-storing mode and/or memory consumption in storing mode such as route projection and BIER.
“

Low power and Lossy Networks (LLNs) 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.

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 RH3 (RFC6553), RPI (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. AD approval is required for each new work item that is proposed.

Work Items are:

Milestones                                        DATE

---

From: "Turner, Randy" <[email-masked]>
Date: Mon, 27 Jun 2016 15:13:29 +0000

Hi Pascal,

Could we just say that “the group will work on enhancements/optimizations for multicast on an LLN”, rather than spell out explicit items ? We’ve done this type of aggregation already for “Methods to improve the current RPL behavior”.

Or, if others feel we need to say absolutely what we plan on doing, then maybe these could be bulleted, with the last bullet indicating “and other methods of enhancing or optimizing multicast on an LLN”

Randy

From: Roll [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Monday, June 27, 2016 10:53 AM
To: Routing Over Low power and Lossy networks
Cc: peter van der Stok
Subject: Re: [Roll] Request for Comments for ROLL Charter

Hello Ines and Peter:

Work Items are:

Milestones                                        DATE

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 27 Jun 2016 16:17:00 +0000

Hello Randy:

I’d like to enable unicast and BIER-TE as well : )

Cheers,

Pascal

From: Roll [mailto:[email-masked]] On Behalf Of Turner, Randy
Sent: lundi 27 juin 2016 17:13
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] Request for Comments for ROLL Charter

Hi Pascal,

Randy

Hello Ines and Peter:

Work Items are:

Milestones                                        DATE

---

From: "Turner, Randy" <[email-masked]>
Date: Mon, 27 Jun 2016 16:47:23 +0000

Right:)

Just interested in a placeholder for other multicast ideas...

R.

On Jun 27, 2016, at 12:17 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

Hello Randy:

Cheers,

Pascal

From: Roll [mailto:[email-masked]] On Behalf Of Turner, Randy
Sent: lundi 27 juin 2016 17:13
To: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Roll] Request for Comments for ROLL Charter

Hi Pascal,

Randy

Hello Ines and Peter:

Work Items are:

Milestones                                        DATE

---

From: Michael Richardson <[email-masked]>
Date: Tue, 28 Jun 2016 08:47:15 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > Additional protocol elements to reduce source route headers in
    > non-storing mode and/or memory consumption in storing mode such as
    > route projection and BIER.

It sounds too prescriptive, as if we have limited ourselves in the charter
to those two methods.  I don't think that this is your intention.

If you wrote:

    > Additional protocol elements to reduce source route headers in
    > non-storing mode and/or memory consumption in storing mode.
    > These elements may leverage mechanisms such as route projection and BIER.

would be clearer that these are not the only two admissible methods.
I'm not sure that we need to say what the methods are *at all*

    > 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.

    > 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.

I'd like these two paragraphs removed as being ancient motherhood text.

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 28 Jun 2016 13:49:48 +0000

> It sounds too prescriptive, as if we have limited ourselves in the charter to those two methods.  I don't think that this is your intention.

Agreed, Michael. We can bar from " such as ..." on. 

Cheers,

Pascal

> -----Original Message-----
> From: Roll [mailto:[email-masked]] On Behalf Of Michael Richardson
> Sent: mardi 28 juin 2016 14:47
> Cc: peter van der Stok <[email-masked]>
> It sounds too prescriptive, as if we have limited ourselves in the charter to those
> two methods.  I don't think that this is your intention.
> 
> If you wrote:
> 
> Michael Richardson <[email-masked]>, Sandelman Software Works  -=
> IPv6 IoT consulting =-
> 
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 28 Jun 2016 13:49:49 +0000

+1

Cheers,

Pascal

From: Roll [mailto:[email-masked]] On Behalf Of Turner, Randy
Sent: lundi 27 juin 2016 18:47
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] Request for Comments for ROLL Charter

Right:)

R.

I'd like to enable unicast and BIER-TE as well : )

Cheers,

Pascal

Hi Pascal,

Could we just say that "the group will work on enhancements/optimizations for multicast on an LLN", rather than spell out explicit items ? We've done this type of aggregation already for "Methods to improve the current RPL behavior".

Or, if others feel we need to say absolutely what we plan on doing, then maybe these could be bulleted, with the last bullet indicating "and other methods of enhancing or optimizing multicast on an LLN"

Randy

Hello Ines and Peter:

I'm happy with this proposed charter. On this particular item, though,
"
Additional protocol to  reduce paths for RPL in non-storing mode
"

I'll note that methods that rely on BIER or on Bloom filters to make routing more efficient were already discussed and should be accommodated. Proposal:
"
Additional protocol elements to reduce source route headers in non-storing mode and/or memory consumption in storing mode such as route projection and BIER.
"

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.

Work Items are:

Milestones                                        DATE

---

From: Cenk Gündogan <[email-masked]>
Date: Tue, 28 Jun 2016 16:31:27 +0200

Hello Pascal, Michael,

Isn't it too restrictive if we limit the text to the non-storing and 
storing modes only?
IMO other modes, like the "P2P Route Discovery" mode as defined inRFC6997
and future modes (if planned) could also benefit from those improvements.

How about:
Additional protocol elements to reduce bytes over the air and/or the 
amount of accumulated routing states.

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Tue, 28 Jun 2016 11:42:55 -0300

Pascal, Michael:
                         I agree with Cenk. I think we need some room for
other ideas. Is it too general to use that phrase?
Regards,

                                          Diego

2016-06-28 10:31 GMT-04:00 Cenk Gündogan <[email-masked]>:

>>> It sounds too prescriptive, as if we have limited ourselves in the
>>> charter to those two methods.  I don't think that this is your intention.
>>>
>>>      > These elements may leverage mechanisms such as route projection
>>> and
>>> BIER.
>>>
>>> monitoring,
>>> consideration

-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125

---

From: "Turner, Randy" <[email-masked]>
Date: Tue, 28 Jun 2016 15:12:00 +0000

+1 just a generalization of my earlier suggestion

R.

On Jun 28, 2016, at 10:46 AM, Prof. Diego Dujovne <[email-masked]<mailto:[email-masked]>> wrote:

Pascal, Michael:

                                          Diego

2016-06-28 10:31 GMT-04:00 Cenk G?ndogan <[email-masked]<mailto:[email-masked]>>:
Hello Pascal, Michael,

Isn't it too restrictive if we limit the text to the non-storing and storing modes only?
IMO other modes, like the "P2P Route Discovery" mode as defined inRFC6997
and future modes (if planned) could also benefit from those improvements.

How about:
Additional protocol elements to reduce bytes over the air and/or the amount of accumulated routing states.

Cheers,

Pascal

-----Original Message-----
From: Roll [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Michael Richardson
Sent: mardi 28 juin 2016 14:47
To: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>
Cc: peter van der Stok <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Roll] Request for Comments for ROLL Charter

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

--
DIEGO DUJOVNE
Profesor Asociado
Escuela de Inform?tica y Telecomunicaciones
Facultad de Ingenier?a - Universidad Diego Portales - Chile
www.ingenieria.udp.cl<http://www.ingenieria.udp.cl>
(56 2) 676 8125
_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 28 Jun 2016 15:53:21 +0000

So leave it at "improvements to the RPL routing protocol" ? It already has some multicast, so that much would be in as well.

Pascal

From: Roll [mailto:[email-masked]] On Behalf Of Turner, Randy
Sent: mardi 28 juin 2016 17:12
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] Request for Comments for ROLL Charter

R.

2016-06-28 10:31 GMT-04:00 Cenk Gündogan <[email-masked]<mailto:[email-masked]>>:
Hello Pascal, Michael,

How about:

Cheers,

Pascal

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Tue, 28 Jun 2016 13:02:18 -0300

I vote for that text. I like multicast included in the
charter too.
Regards,

                                Diego

2016-06-28 11:53 GMT-04:00 Pascal Thubert (pthubert) <[email-masked]>:

> So leave it at “improvements to the RPL routing protocol” ? It already has
> some multicast, so that much would be in as well.
>
>
>
> Pascal
>
>
>
> *From:* Roll [mailto:[email-masked]] *On Behalf Of *Turner, Randy
> *Sent:* mardi 28 juin 2016 17:12
> *To:* Routing Over Low power and Lossy networks <[email-masked]>
> On Jun 28, 2016, at 10:46 AM, Prof. Diego Dujovne <
> [email-masked]> wrote:
>
> Pascal, Michael:
>
> to those

---

From: peter van der Stok <[email-masked]>
Date: Wed, 29 Jun 2016 08:56:11 +0200

Hi Michael,

> I'd like these two paragraphs removed as being ancient motherhood text.
Indeed, I agree, these lines represent history.
However, newcomers should like to know the ROLL history.
And also these lines still reflect on the driving reasons of design 
decisions in the past and decisions to come.

So, I like to preserve them.

Greetings,

peter

---

From: peter van der Stok <[email-masked]>
Date: Wed, 29 Jun 2016 09:05:57 +0200

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."

As a side remark:
I don't like "through the air", Radio also works in vacuum.

Peter

---

From: Cenk Gündogan <[email-masked]>
Date: Wed, 29 Jun 2016 17:04:28 +0200

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".
Secondly, "packet size" sounds a little bit too generic, how about 
"control packet sizes",
or "RPL related packet sizes"?
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.

Cenk

On 06/29/2016 09:05 AM, peter van der Stok wrote:
> "Additional protocol elements to reduce packet size and/or the amount 
> of accumulated routing states."
>
> As a side remark:

---

From: peter van der Stok <[email-masked]>
Date: Thu, 30 Jun 2016 11:11:12 +0200

Hi Cenk,

thanks for your suggestions.
I cannot refrain from reacting, and see below.

> I propose we drop any form of uncertainty and change the "and/or" to 

much better.

> 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.

> The proposed form "reduce ... the amount of accumulated routing
> states" could also

required it is

> Cenk

Other suggestions or improvements?

If not we send new text on monday/tuesday.

Peter