Re: [Roll] Request for Comments for ROLL Charter

Cenk Gündogan <cnkgndgn@gmail.com> Wed, 22 June 2016 08:27 UTC

Return-Path: <cnkgndgn@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB64E12D091 for <roll@ietfa.amsl.com>; Wed, 22 Jun 2016 01:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.197
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_MMUlhpzKzU for <roll@ietfa.amsl.com>; Wed, 22 Jun 2016 01:27:54 -0700 (PDT)
Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EC6A12B00B for <roll@ietf.org>; Wed, 22 Jun 2016 01:27:53 -0700 (PDT)
Received: by mail-lb0-x229.google.com with SMTP id o4so17812998lbp.2 for <roll@ietf.org>; Wed, 22 Jun 2016 01:27:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.194.82.36 with SMTP id f4mr23830901wjy.104.1466584071056; Wed, 22 Jun 2016 01:27:51 -0700 (PDT)
Received: from [10.92.124.3] (z5c7c.pia.fu-berlin.de. [87.77.92.124]) by smtp.googlemail.com with ESMTPSA id t190sm6830621wmt.24.2016.06.22.01.27.50 for <roll@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jun 2016 01:27:50 -0700 (PDT)
To: roll@ietf.org
References: <CAP+sJUdRQHJhuszRLmMLoObVVELTGKAboPZpjHRV1M1t3T1BpA@mail.gmail.com>
From: =?UTF-8?Q?Cenk_G=c3=bcndogan?= <cnkgndgn@gmail.com>
Message-ID: <457be029-a0f9-f6be-0900-51f38e10dc22@gmail.com>
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: <CAP+sJUdRQHJhuszRLmMLoObVVELTGKAboPZpjHRV1M1t3T1BpA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------7ACBC1805E1B52BF63394879"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/cUhvKpdLFwTnrh9UVy_oA29NQSs>
Subject: Re: [Roll] Request for Comments for ROLL Charter
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=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.

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