Re: [Roll] Request for Comments for ROLL Charter
Ines Robles <mariainesrobles@googlemail.com> Thu, 23 June 2016 06:58 UTC
Return-Path: <mariainesrobles@googlemail.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 5D8E612D899 for <roll@ietfa.amsl.com>; Wed, 22 Jun 2016 23:58:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.689
X-Spam-Level:
X-Spam-Status: No, score=-2.689 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.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 2DDrjeptMJUW for <roll@ietfa.amsl.com>; Wed, 22 Jun 2016 23:58:49 -0700 (PDT)
Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (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 1638912D155 for <roll@ietf.org>; Wed, 22 Jun 2016 23:58:49 -0700 (PDT)
Received: by mail-vk0-x22a.google.com with SMTP id c2so63057689vkg.1 for <roll@ietf.org>; Wed, 22 Jun 2016 23:58:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b0GuY5V6BBJwdsKmWUOGeC/ebfK2LgDA3fRawffOEjw=; b=cf+xL42QyDAVbktClvDqZbR+qyeoOpCK1KpTmJ2ZUAR+XG6N96GChlBZ88WaoJCFbU 5TkJriARoS5VLO/f4XBgo+43znvKnf5fmSG8BecGAIcC4aPvSs+1Oe39ISGH9oOOl8kP PVdCUSKmfWz5R32+oJ40Bt8SbD39YVZFOhKEJINtwMFD7Io/hW+N6tMGUhOKlRqWDKVb cFWz9iXfJaATC1NOIET5LlEO3HGvlHbvWnnAT0xyUDdpQUM+8zLzcs6k83hFRwTcg3vF LJqhDCM1c2HrnEhNrif5ljt+amwrJK6lSsrTl+f9Qn9GE8BuJnHYUezuZw0vIwtKawSf OLlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=b0GuY5V6BBJwdsKmWUOGeC/ebfK2LgDA3fRawffOEjw=; b=XUJbRz5pAS5RgqI3A7TSK5+PP17ILdbtY19opkRGjs5wB/K86gUlGpvD7h7I0nj32X bMpFFCXAu6B3Ph4LIzCXvS2g5mvZRNy/t5SpuyOnen2yhfP+KS9Kn+aMYMUps9tqFMxf MF5RWYjenauLJTyhPmy/Y3om4AokgEE8fxjaf65yC2Fiheatlla6x1yvYA02hybPv1zJ moUZYoDeeDrZWb5RRraeeqa3Zm3Fd/auwEcE7q8Vv8qCH6dOkPVYkKuplA1mS5Jq6eey IITRBDFMHzKdLAubBGWNelRZoO1EF+kpOKcgcNnyLpcECfOx6S0JrDqF/0daQMOvgPIC 1cyA==
X-Gm-Message-State: ALyK8tJEEx2HXqeNVx1cDI/CJ3dfDYAnxIPgBsCExqeGa8BxYgQvAMlB8JX4XHBwvuKevDVCitfl2OYZW13pmg==
X-Received: by 10.159.36.65 with SMTP id 59mr14334490uaq.71.1466665127921; Wed, 22 Jun 2016 23:58:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.36.200 with HTTP; Wed, 22 Jun 2016 23:58:47 -0700 (PDT)
In-Reply-To: <982B626E107E334DBE601D979F31785C5D03D1AD@blreml510-mbs.china.huawei.com>
References: <CAP+sJUdRQHJhuszRLmMLoObVVELTGKAboPZpjHRV1M1t3T1BpA@mail.gmail.com> <457be029-a0f9-f6be-0900-51f38e10dc22@gmail.com> <982B626E107E334DBE601D979F31785C5D03D1AD@blreml510-mbs.china.huawei.com>
From: Ines Robles <mariainesrobles@googlemail.com>
Date: Thu, 23 Jun 2016 09:58:47 +0300
Message-ID: <CAP+sJUeQbJieOz3wazkkn5OH35BsQhjRT7m5CTNfMy1eNm6HEg@mail.gmail.com>
To: cnkgndgn@gmail.com
Content-Type: multipart/alternative; boundary="001a1135cfe2f44e930535ec95c1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/7QxzY-nwaoK58aM7uypxrjX9VDg>
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>
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: Thu, 23 Jun 2016 06:58:53 -0000
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. ////////////////////////////////////////////////////////////////////////////////// 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. 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. - 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) <rahul.jadhav@huawei.com>: > 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:roll-bounces@ietf.org] *On Behalf Of *Cenk Gündogan > *Sent:* 22 June 2016 PM 01:58 > *To:* roll@ietf.org > *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 > > 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 > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > >
- Re: [Roll] Request for Comments for ROLL Charter Ines Robles
- Re: [Roll] Request for Comments for ROLL Charter peter van der Stok
- Re: [Roll] Request for Comments for ROLL Charter Michael Richardson
- Re: [Roll] Request for Comments for ROLL Charter peter van der Stok
- Re: [Roll] Request for Comments for ROLL Charter Michael Richardson
- Re: [Roll] Request for Comments for ROLL Charter Pascal Thubert (pthubert)
- Re: [Roll] Request for Comments for ROLL Charter Ines Robles
- Re: [Roll] Request for Comments for ROLL Charter peter van der Stok
- Re: [Roll] Request for Comments for ROLL Charter Cenk Gündogan
- Re: [Roll] Request for Comments for ROLL Charter Prof. Diego Dujovne
- Re: [Roll] Request for Comments for ROLL Charter Pascal Thubert (pthubert)
- Re: [Roll] Request for Comments for ROLL Charter Turner, Randy
- Re: [Roll] Request for Comments for ROLL Charter Cenk Gündogan
- Re: [Roll] Request for Comments for ROLL Charter Pascal Thubert (pthubert)
- Re: [Roll] Request for Comments for ROLL Charter Pascal Thubert (pthubert)
- Re: [Roll] Request for Comments for ROLL Charter Michael Richardson
- Re: [Roll] Request for Comments for ROLL Charter Pascal Thubert (pthubert)
- Re: [Roll] Request for Comments for ROLL Charter Pascal Thubert (pthubert)
- Re: [Roll] Request for Comments for ROLL Charter Ines Robles
- Re: [Roll] Request for Comments for ROLL Charter Rahul Arvind Jadhav (Rahul Arvind Jadhav, 2012 Labs)
- Re: [Roll] Request for Comments for ROLL Charter Cenk Gündogan
- [Roll] Request for Comments for ROLL Charter Ines Robles
- Re: [Roll] Request for Comments for ROLL Charter Turner, Randy
- Re: [Roll] Request for Comments for ROLL Charter Turner, Randy
- Re: [Roll] Request for Comments for ROLL Charter Prof. Diego Dujovne
- Re: [Roll] Request for Comments for ROLL Charter peter van der Stok
- Re: [Roll] Request for Comments for ROLL Charter peter van der Stok