Re: [Roll] Request for Comments for ROLL Charter

Cenk Gündogan <> Wed, 22 June 2016 08:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DB64E12D091 for <>; Wed, 22 Jun 2016 01:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.197
X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p_MMUlhpzKzU for <>; Wed, 22 Jun 2016 01:27:54 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4EC6A12B00B for <>; Wed, 22 Jun 2016 01:27:53 -0700 (PDT)
Received: by with SMTP id o4so17812998lbp.2 for <>; Wed, 22 Jun 2016 01:27:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=hxrnXDMIa9m36cwCCswIDHxLr6P/TB0YBZV9nTHNmu8=; b=pHVtCSzUwUcZ5IlCRqhmp7uR2BJFpOl8buB8l1haom/1BmvC6bTElHsYcQGkpWVN7u YvuLUdjdOhsGZxOpgMfoG0I3tG1yt0n0LOeMLFQKjdYaJBLfeAijig7Dy+9MW3j/h2hx 5TAuWqtcbL7eQMAfsxkDshvKRSU7ahlkfpl9Yem51zO2OCFJ1tWgqhc/X+YKhj8SbxYT MGGHxn2PYOQ7YDFS/ivdqqWWWqCpsy3uEwSJuePbpXJ33vOufortovXNnpGiEhzO516Z rULjt4pNxHbpwq7brn2JbMcvg/q03yEqUIbNqvigzJfAjXuGJDywXRahgVgHDYzuflT2 1++w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=hxrnXDMIa9m36cwCCswIDHxLr6P/TB0YBZV9nTHNmu8=; b=gyaQt31kdpm5P2LfiCuDQfSYJU8aG42lySnVcv6raTdNffPMpLu0mTuZDPdM3q91ua yeMr2JwFVgA1XAyup/p2cd9BRtS5wd1mq86phjcJ/m7cruppFWPcfa4n54ubF5UHxdxH 6gFyaTTzLdnM0IrzBxfs6fLWLsKUK2MLjwAitXhKrkT8tSelxZv7WVHJsVexY1/14nce Mg/V1bSetDJlZFkIs1C0jbcKVeMbRFr76JU+VIWVrZp8ifQ3FZKuelQreEhf9G08jFWQ dFMHTfDSEEYhN0SsNBVE/BgL4/bfl4JBQZB4bkeGbo1CsKqmwE3apswUMLZH6cmHZ0f0 H6Pg==
X-Gm-Message-State: ALyK8tLZhclGrUaRESzYqqndirlVli4Jnilc6tjz6gkA+rw8PeI82JKOB3ndLclads+uGQ==
X-Received: by with SMTP id f4mr23830901wjy.104.1466584071056; Wed, 22 Jun 2016 01:27:51 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id t190sm6830621wmt.24.2016. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jun 2016 01:27:50 -0700 (PDT)
References: <>
From: =?UTF-8?Q?Cenk_G=c3=bcndogan?= <>
Message-ID: <>
Date: Wed, 22 Jun 2016 10:27:49 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------7ACBC1805E1B52BF63394879"
Archived-At: <>
Subject: Re: [Roll] Request for Comments for ROLL Charter
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <>
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Jun 2016 08:27:57 -0000

Hello Ines,Peter,

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



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 
Should we use a more general wording here for the DAO handling, instead 
of just concentrating on the No-Path DAO?
For reference:

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