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

Thanks!

Best,
Cenk

On 06/21/2016 06:27 PM, Ines Robles wrote:
> 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

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

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

 > 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
>
> 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
>
>
>
> /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll