Re: [Roll] proposed amendments to ROLL charter

Ines Robles <mariainesrobles@googlemail.com> Mon, 06 April 2015 10:26 UTC

Return-Path: <mariainesrobles@googlemail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9481A86DD for <roll@ietfa.amsl.com>; Mon, 6 Apr 2015 03:26:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level:
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 pXT3c2t6FWn3 for <roll@ietfa.amsl.com>; Mon, 6 Apr 2015 03:26:31 -0700 (PDT)
Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (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 DE8DD1A8034 for <roll@ietf.org>; Mon, 6 Apr 2015 03:26:30 -0700 (PDT)
Received: by lagv1 with SMTP id v1so16951463lag.3 for <roll@ietf.org>; Mon, 06 Apr 2015 03:26:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6VadsWpDdqnCtC33rw8ExeodrHNpGwzfhAq6P1K3Esc=; b=wuErv3hdv3xiLATnwkJzlIgtVjVFeO4B1sMZ6rGUdGEsj0kqPPT0RkcBJnMLBpLigz nOZHPbEzNQMMrzUi321FHHWfAc+Fwiy/cDP3INGNb/DbKkEXmoSx0TU11Ah994C6PplG w2vSHRizKtnjjlvarswsxo0Rmir+Zl2weSSCpQCpszAiaWxp5JByuQX4bT0Y3oZiTvxe GqfzEWt+Kw2v6Kz3ZC8G2aZmdMcxu5+zEajI+rw0fJEpKsQaY3MEDuSc37n3jj39WDVU DiUr2Q1CfwQJNmFXNqKioTGZpcw7/G9hHQxxMAU+62wXjGwr3GwVowIF0TLAfTlzsdg/ WcHg==
MIME-Version: 1.0
X-Received: by 10.112.8.101 with SMTP id q5mr13109697lba.19.1428315989297; Mon, 06 Apr 2015 03:26:29 -0700 (PDT)
Received: by 10.25.89.4 with HTTP; Mon, 6 Apr 2015 03:26:29 -0700 (PDT)
In-Reply-To: <E045AECD98228444A58C61C200AE1BD849D98770@xmb-rcd-x01.cisco.com>
References: <30526.1427136071@sandelman.ca> <E045AECD98228444A58C61C200AE1BD849D918D7@xmb-rcd-x01.cisco.com> <CAP+sJUf4QMXXzZ4Dj7rB5J95idDdCBo5AQDXV2kuo_okfCRMSw@mail.gmail.com> <E045AECD98228444A58C61C200AE1BD849D98770@xmb-rcd-x01.cisco.com>
Date: Mon, 06 Apr 2015 13:26:29 +0300
Message-ID: <CAP+sJUcmy-f3vhtgCH_wV4HJaJo9EJxYUo32_uG4_e0gw7vjqg@mail.gmail.com>
From: Ines Robles <mariainesrobles@googlemail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/alternative; boundary="001a1134df962b511105130bbb12"
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/-SEGMb1oWsvyYnNtvFD2JbGM0_Y>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>
Subject: Re: [Roll] proposed amendments to ROLL charter
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Mon, 06 Apr 2015 10:26:35 -0000

Hi,

Ticket #169 [http://trac.tools.ietf.org/wg/roll/trac/ticket/169] was
created to tack these items.

Thank you,

Michael and Ines.

2015-04-02 18:59 GMT+03:00 Pascal Thubert (pthubert) <pthubert@cisco.com>:

>  A few other things I’d like to see, Ines:
>
>
>
> - One is a MOP based on BIER and/or Bloom filters, which is a way to
> compress BIER with a chance of false positive. Carsten has a draft that
> details the use of Bloom filters for source routing, but really both BIER
> and Bloom can apply to either storing and non-storing.
>
> - Work on mixed storing and non-storing, and all sort of optimization for
> the storing mode. I’m aware of feasible solutions in that space that really
> should be shared and made available to all.
>
> - Work on additional capabilities that we did not initially include in the
> spec:
>
> - The capability to kill a route from the root, e.g. if a DAO state is
> installed and should be cleaned up, e.g. if the root realizes that the node
> is no more there or there is a duplication or what-else.
>
> - The capability to trigger a DAO from the root if a target is expected to
> be present in the network but there is no DAO state (maybe to save
> resources)
>
> - The capability to request the triggering of a new iteration of a DODAG
> from a RPL node or a controlling element.
>
>
>
> Thanks for asking J
>
>
>
> Pascal
>
>
>
> *From:* Roll [mailto:roll-bounces@ietf.org] *On Behalf Of *Ines Robles
> *Sent:* mardi 31 mars 2015 16:10
> *To:* Routing Over Low power and Lossy networks
> *Cc:* Michael Richardson
> *Subject:* Re: [Roll] proposed amendments to ROLL charter
>
>
>
> Hi Pascal,
>
>
>
> Thank you very much for your comments, we are going to include them in our
> meeting.
>
>
>
> To all, There are additional topics that you would like to include in the
> charter? Please justify.
>
>
>
> Thank you very much,
>
>
>
> Michael and Ines
>
>
>
> 2015-03-31 13:49 GMT+03:00 Pascal Thubert (pthubert) <pthubert@cisco.com>:
>
> Hello Michael (and all):
>
> I fully support the additions. Since you are at it, I would like to
> explore a deeper realignment.
>
> ROLL is now in charge of the maintenance of RPL, isn't it?
> - I think that this should be a work item in the charter.
> - this should replace elements that were or are being delivered such as
> metrics, security, and RPL itself
>
> And if that's so, wouldn't it make sense to study how RPL works outside
> LLNs and in mixed environments?
> - I'd like to see work on RPL over foo where foo is Ethernet or Wi-Fi.
> Applicability of RPL in various environments outside LLN would be of
> interest, e.g. to build a Wi-Fi mesh or an unmanaged network. It seems that
> a DT will form at HOMENET to select a routing protocol, and an
> applicability statement of RPL for that case would be a good read if we can
> produce it in time.
> - From our experience of actually doing RPL over Ethernet, it is mostly a
> matter of *not* using the packet artifacts, probably not using the stretch
> in local repair, and reacting immediately to changes in link state. This is
> a very small spec indeed, mostly guidance on what to use and what not to
> use from RFC 6550, how to tune some parameters, which OF to use and how.
> - The work should also detail the mode where there is a backbone and a
> virtual root. I think that the current charter does not cover work outside
> LLN but considering that we are the group that knows RPL best, that work
> should happen here.
>
> What do you think?
>
> Pascal
>
>
> > -----Original Message-----
> > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Michael
> Richardson
> > Sent: lundi 23 mars 2015 19:41
> > To: roll@ietf.org
> > Subject: [Roll] proposed amendments to ROLL charter
> >
> >
> > The following changes are proposed for the ROLL charter to include the
> work to
> > profile 6553/6554/IPIP, and to compress it.
> >
> > To the pre-amble:
> >
> > After:
> >  - In most cases, LLNs will be employed over link layers with restricted
> >    frame-sizes, thus a routing protocol for LLNs should be specifically
> >    adapted for such link layers.
> >
> > Add:
> > +- LLN routing protocols have to be very careful when trading off
> > +efficiency
> > +  for generality; many LLN nodes do not have resources to waste.
> >
> > After:
> >  The solution must include unicast and multicast considerations.
> >
> > Add:
> > +The Working Group will document how non-control packets are routed when
> > +they cross the LLN, and when they enter and exit the LLN: the
> > +appropriate use of
> > +RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how
> > +routing loops are detected. In consultation with the 6lo WG, the
> > +Working Group will design a method to these routing headers into a
> > +single block.  The result will have a shared WGLC with 6lo.
>
> >
> > To  Work Items, add:
> > +     - A document detailing when to use RFC6553, RFC6554 and IPIP
> > +       encapsulation.
> > +
> > +     - A document detailing how to compress RFC6553, RFC6554 and IP
> headers
> > +       in the 6lowPAN HC context.
> >
> >
> > The resulting charter (after reformatting of some of the ugly text
> wrapping on
> > the web site) is:
> >
> > ----
> > 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 have at least five distinguishing
> > characteristics:
> > - LLNs operate with a hard, very small bound on state.
> > - In most cases, LLN optimize for saving energy.
> > - 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, 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; many 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 and have in their current form been found
> to
> > not satisfy all of these specific routing requirements.
> >
> > The Working Group is focused on routing issues for LLN.
> >
> > There is a wide scope of application areas for LLNs, including industrial
> > monitoring, building automation (HVAC, lighting, access control, fire),
> > connected homes, healthcare, environmental monitoring, urban sensor
> > networks (e.g. Smart Grid), asset tracking. The Working Group focuses on
> > routing solutions for a subset of these: industrial, connected home,
> building and
> > urban sensor networks for which routing requirements have been specified.
> > These application-specific routing requirement documents will be used for
> > protocol design.
> >
> > The Working Group focuses only 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 pay particular attention to routing security and
> > manageability (e.g., self routing configuration) issues. It will also
> need to
> > consider the transport characteristic the routing protocol messages will
> > experience. Mechanisms that protect an LLN from congestion collapse or
> that
> > establish some degree of fairness between concurrent communication
> sessions
> > are out of scope of the Working Group. It is expected that upper-layer
> > applications utilizing LLNs define appropriate mechanisms.
> >
> > The solution must include unicast and multicast considerations.
> >
> > The Working Group will document how non-control packets are routed when
> > they cross the LLN, and when they enter and exit the LLN: the
> appropriate use of
> > RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how routing
> > loops are detected. In consultation with the 6lo WG, the Working Group
> will
> > design a method to these routing headers into a single block.  The
> result will
> > have a shared WGLC with 6lo.
> >
> > Work Items:
> >
> >      - Specification of routing metrics used in path calculation. This
> >        includes static and dynamic link/node attributes required for
> routing in
> >        LLNs.
> >
> >      - Provide an architectural framework for routing and path selection
> at
> >        Layer 3 (Routing for LLN Architecture) that addresses such issues
> as
> >        whether LLN routing require a distributed and/or centralized path
> >        computation models, whether additional hierarchy is necessary and
> how it
> >        is applied.
> >
> >        Manageability will be considered with each approach, along with
> various
> >        trade-offs for maintaining low power operation, including the
> presence of
> >        non-trivial loss and networks with a very large number of nodes.
> >
> >      - Produce a routing security framework for routing in LLNs.
> >
> >      - Protocol work: The Working Group will consider specific routing
> >        requirements from the four application documents collectively, and
> >        specify either a new protocol or extend an existing routing
> protocol
> >        in cooperation with the relevant Working Group.
> >        If requirements from the four target application areas cannot be
> met
> >        with a single protocol, the WG may choose to specify or extend
> more than
> >        one protocol (this will require a recharter of the WG).
> >
> >      - Documentation of applicability statement of ROLL routing
> protocols.
> >
> >      - A document detailing when to use RFC6553, RFC6554 and IPIP
> >        encapsulation.
> >
> >      - A document detailing how to compress RFC6553, RFC6554 and IP
> headers
> >        in the 6lowPAN HC context.
> >
> >
> >
> > $Id: charter.txt,v 1.3 2015/03/23 18:33:38 mcr Exp $
> >
> >
> >
> > --
> > Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> > IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/
>
> _______________________________________________
> 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
>
>