From roll-bounces@ietf.org Mon Feb 2 10:28:54 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80DA33A6999; Mon, 2 Feb 2009 10:28:54 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBC4C3A6999 for ; Mon, 2 Feb 2009 10:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVYUzsjW99Je for ; Mon, 2 Feb 2009 10:28:52 -0800 (PST) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id 3169F3A6BB4 for ; Mon, 2 Feb 2009 10:28:52 -0800 (PST) Received: from sphinx.lix.polytechnique.fr ([129.104.11.1] helo=[192.168.112.180]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LU3X4-00043L-Ti; Mon, 02 Feb 2009 18:28:31 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 129.104.11.1 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18Rl9278mpN1lAFM6XGOAqP In-Reply-To: <374005f30901301106s2b59c315y29c6816498c843eb@mail.gmail.com> References: <20090127000001.9F1F03A6819@core3.amsl.com> <654A66D8-FFBA-408C-8045-935DE5EB2D80@cs.stanford.edu> <374005f30901290757j1c37c25dpa22d67b0e1485747@mail.gmail.com> <49828189.6030906@eecs.berkeley.edu> <374005f30901300626l4106e298y9ff4d71c47c1abfb@mail.gmail.com> <42F2FA60-B59E-4CF4-87C2-203A55BE63D1@thomasclausen.org> <50446ECF-CE4B-4C6B-8F6F-9258D3AF593A@cs.stanford.edu> <374005f30901301106s2b59c315y29c6816498c843eb@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <44971175-E77F-46F6-BB1C-7C2A23FB7464@thomasclausen.org> From: Thomas Heide Clausen Date: Mon, 2 Feb 2009 19:26:48 +0100 To: Ian Chakeres X-Mailer: Apple Mail (2.753.1) Cc: Ross Callon , ROLL WG , "David E. Culler" Subject: Re: [Roll] I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org But wait, Ian, either my [now dated] implementation of an early version of DYMO (-06, I think?) was wrong, or this has been possible since at least then -- although maybe not at the time spelled out explicitly? Thomas On Jan 30, 2009, at 8:06 PM, Ian Chakeres wrote: > DYMO can take these properties/attributes into account using the > (dimension-less) distance metric. > > I am guessing that we may have different opinions about how these > constraints can/should be conveyed to a routing protocol. > > Ian > > On Fri, Jan 30, 2009 at 12:27 PM, Philip Levis > wrote: > >> " However, in low power networks it is also desirable to account for >> the cost of forwarding through particular routers. Applications >> require node or parameter constrained routing, which takes into >> account node properties and attributes such as power, memory, and >> battery life that dictate a router's willingness or ability to >> route >> other packets." > > _______________________________________________ > 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 From roll-bounces@ietf.org Mon Feb 2 10:36:15 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE50E28C1CA; Mon, 2 Feb 2009 10:36:14 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69F043A6B28 for ; Mon, 2 Feb 2009 10:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bogt9WxqlkXy for ; Mon, 2 Feb 2009 10:36:12 -0800 (PST) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id 9F9E73A68CC for ; Mon, 2 Feb 2009 10:36:12 -0800 (PST) Received: from sphinx.lix.polytechnique.fr ([129.104.11.1] helo=[192.168.112.180]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LU3eD-0006gj-0L; Mon, 02 Feb 2009 18:35:53 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 129.104.11.1 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/zqI/bvoCfYiVsUCVL9i8X In-Reply-To: References: <20090121231501.7755A3A68E4@core3.amsl.com> <497849C1.6070705@polytechnique.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Thomas Heide Clausen Date: Mon, 2 Feb 2009 19:34:12 +0100 To: JP Vasseur X-Mailer: Apple Mail (2.753.1) Cc: Arsalan Tavakoli , ROLL WG , stevedh@cs.berkeley.edu Subject: Re: [Roll] I-D ACTION:draft-ietf-roll-protocols-survey-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Jan 24, 2009, at 3:29 PM, JP Vasseur wrote: > Hi Ulrich, > > On Jan 22, 2009, at 11:26 AM, Ulrich Herberg wrote: > >> >> - Another general remark: I am not sure that this would belong >> into this ID, but somewhere I would like to see an applicability >> statement that underlines the differences to MANET and 6lowpan >> requirements and protocols. For a reader that -- like me -- comes >> more from the MANET world, it would be good to emphasize why the >> protocols that work well in MANETs do not work in LLNs. MANETs are >> not per se limited to high power machines and stable links but may >> have the same constraints as LLNs. > > There is no such WG item. If someone is willing to write such an > informational document, why not but for the time being this is not > needed. On the other hand, we may end up writing applicability > statement to document the use of protocol X in condition Y. But > again this is premature, we first need to complete the protocol work. Well, this document does go through the exercise of concluding that no existing protocols, in their current form, are applicable to the ROLL problem space. I'm not disputing that this may be the case, however in order to understand this I need to understand what the ROLL problem space *IS*, and how it's different from the MANET problem space? I'm replying to a review of a -04, but IMO -05 does not address this issue either. Thomas _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Feb 2 10:39:37 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40D413A6BC9; Mon, 2 Feb 2009 10:39:37 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 763C23A6BC5 for ; Mon, 2 Feb 2009 10:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbV07+VPQDWF for ; Mon, 2 Feb 2009 10:39:35 -0800 (PST) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id 1CACB3A6BC3 for ; Mon, 2 Feb 2009 10:39:35 -0800 (PST) Received: from sphinx.lix.polytechnique.fr ([129.104.11.1] helo=[192.168.112.180]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LU3hP-0008BU-EB; Mon, 02 Feb 2009 18:39:11 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 129.104.11.1 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/23psmxdogAl+z68AHo/Ab In-Reply-To: <20090127000001.9F1F03A6819@core3.amsl.com> References: <20090127000001.9F1F03A6819@core3.amsl.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> From: Thomas Heide Clausen Date: Mon, 2 Feb 2009 19:37:27 +0100 To: roll@ietf.org X-Mailer: Apple Mail (2.753.1) Cc: Ross Callon , stevedh@cs.berkeley.edu, Arsalan Tavakoli , "David E. Culler" Subject: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org All, I promised a review, and I apologize that I wasn't able to do so before the weekend as originally projected. Other than some typos that Chris and others have pointed out, I'll try to offer my understanding of the problem space and suggest some ways of addressing my main concerns.... My first main concern remain that it is not clear, still, how ROLL positions itself with respect to MANET, 6LOW et. al, all of which appear to be within the same space and within the IETF. This I-D sees ROLL as presented with entirely new problems (the use of "novel" in the abstract, the statement that "existing protocols were not designed with these requirements in mind" seem to confirm this). Looking at the requirements listed, including "low power, low bandwidth, low footprint", these appear similar to those which are also brought forward in e.g. MANET and 6LOW. Reading (quickly, I confess) the various requirements documents of the draft-ietf-roll series present scenarios which are similar to those where MANETs are deployed, and are thought deployed, as well. I also note that many additional (and unstated) characteristics between ROLL and e.g. MANET are the same: mobile, wireless, fragility, auto-configuration, IP routing, interface/link issues... Arguing that, as does this I-D, despite the above impression "ROLL is novel and different" invites asking "how, exactly?" I think that this question is valid, and merits being answered, before the evaluations in this I-D can be judged fairly. Note that I come from a MANET background, and so I *could* interpret from the ROLL discussion that where MANETs may aim for "low power, low bandwidth, ....", ROLL may be able to quantify these as "below this firm threshold" -- i.e. as a sort of "extreme" or "constrained" MANET. This is a personal observation, I note, which would allow me to comprehend how ROLL and MANET are positioned relative to one another -- but one which neither this I-D nor the requirements document spell out or quantify -- or, for that matter, debunk. I think it's critical to understand this, in order to understand the need for a new protocol development. I think it is important to document this understanding in something with more persistency. If what I suggest above makes sense as a way of positioning ROLL and MANET relative to one another, I'd suggest including something to this effect in the survey I-D, as this I-D is the one making a *direct* reference to the applicability of MANET protocols to ROLL. If what I suggest doesn't make sense at all, then I'd be happy to have it debunked and, hopefully, through that debunking a positioning/ description that does ring true with us all can be produced? My second main concern is, that I still think that the choice of criteria is unfortunate (not the word, Phill has me convinced on that front, but the actual criteria). Control cost is, by all means, a rather meaningless criteria when taken in isolation. I've sketched a "zero-control-cost" routing protocol (flood all data - say use SMF, also a MANET protocol, and also a rather "mature" I-D and wg item) which would score well on the control cost criteria, but would likely be an extremely bad choice for delivering unicast data. The metric which matters, and which should matter to ROLL in particular, is "the total cost of getting user data through the network, including control cost necessary to set up paths" -- as we know, every packet sent and received costs bandwidth, energy and cycles -- user data no different from contro. According to the criterions as set up by this I-D, a protocol producing "longer than shortest paths" at the benefit of slightly lower control cost would score better than a protocol producing "shortest paths" with slightly higher control cost. This is not hypothetical, btw., there are plenty of studies observing and reflecting upon this regarding the different MANET protocols, in academic literature -- and observed in real networks as well. I note that this trade-off (slightly longer paths for lower control cost) may be perfectly fair, assuming that very low amounts of user data traffic transit through the network. However, I do not see this assumption mentioned as a justification for focusing on the control cost metric and discarding the "path length" or the "total cost of getting user data through the network". I believe that either these assumptions should be made explicit ("there's so little user data traffic in a ROLL network that we do not care about shortest paths") or -- if these assumptions do not hold, that the evaluation criteria are incomplete. I note that it's true that we can always add another criteria ad infinitum, and that's CLEARLY not what we want to do. However when I say "incomplete" in the above, I simply suggest that based on what is presented one cannot draw conclusions based on the evaluation criteria....or, worse, that one draws the wrong conclusions based on the information presented. So, in a nutshell, I suggest that we address (i) the positioning issue and (ii) the criteria issue thus: o Describe as I proposed above if ROLL and MANETs position themselves as I have deducted. If my deduction is incorrect, then let's quickly iterate on the list as to understand how to do produce an alternative description. If we can't do this, then the conclusion can be that "we do not know how ROLL and MANET position themselves wrt each other", and we could then state that clearly? It *should* not be more than a couple of paragraphs worth of text to add, I gather? o To the criteria, either of: - Add the assumption that "user data traffic is so low that path lengths do not matter nor does the cost of carrying user data traffice" - Add a criteria & evaluation of "path length" - Add a criteria & evaluation of "total cost for getting user data through the network" This would make a large chunk of my concerns and issues vanish, and allow correctly interpreting and evaluating the rest of the document. How does that sound as an approach forward? Cheers, Thomas On Jan 27, 2009, at 1:00 AM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Routing Over Low power and Lossy > networks Working Group of the IETF. > > Title : Overview of Existing Routing Protocols for Low Power and > Lossy Networks > Author(s) : A. Tavakoli, S. Dawson-Haggerty, P. Levis > Filename : draft-ietf-roll-protocols-survey-05.txt > Pages : 26 > Date : 2009-1-26 > > Networks of low power wireless devices introduce novel IP routing > issues. Low-power wireless devices, such as sensors, actuators and > smart objects, have difficult constraints: very limited memory, > little processing power, and long sleep periods. As most of these > devices are battery-powered, energy efficiency is critically > important. Wireless link qualities can vary significantly over > time, > requiring protocols to make agile decisions yet minimize topology > change energy costs. Routing over such low power and lossy > networks > has novel requirements that existing protocols may not address. > This > document provides a brief survey of the strengths and weaknesses of > existing protocols with respect to this class of networks. From > this > survey it examines whether existing and mature IETF protocols > can be > used without modification in these networks, or whether further > work > is necessary. > is necessary. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols- > survey-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2009-1-26155804.I-D@ietf.org> > > _______________________________________________ > 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 From roll-bounces@ietf.org Mon Feb 2 13:45:03 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4EF03A6BBD; Mon, 2 Feb 2009 13:45:03 -0800 (PST) X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 357673A6B47; Mon, 2 Feb 2009 13:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090202214501.357673A6B47@core3.amsl.com> Date: Mon, 2 Feb 2009 13:45:01 -0800 (PST) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-building-routing-reqs-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Building Automation Routing Requirements in Low Power and Lossy Networks Author(s) : J. Martocci, et al. Filename : draft-ietf-roll-building-routing-reqs-03.txt Pages : 29 Date : 2009-02-02 The Routing Over Low power and Lossy network (ROLL) Working Group has been chartered to work on routing solutions for Low Power and Lossy networks (LLN) in various markets: Industrial, Commercial (Building), Home and Urban. Pursuant to this effort, this document defines the routing requirements for building automation. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-building-routing-reqs-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-building-routing-reqs-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-02134100.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --NextPart-- From roll-bounces@ietf.org Mon Feb 2 14:16:53 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A3EB28C233; Mon, 2 Feb 2009 14:16:53 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F23C3A6B1B; Mon, 2 Feb 2009 14:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhktjl5QM5bq; Mon, 2 Feb 2009 14:16:51 -0800 (PST) Received: from exprod8og103.obsmtp.com (exprod8og103.obsmtp.com [64.18.3.86]) by core3.amsl.com (Postfix) with ESMTP id E77BF3A6BD4; Mon, 2 Feb 2009 14:16:25 -0800 (PST) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob103.postini.com ([64.18.7.12]) with SMTP ID DSNKSYdwoiT4uX9R0YzxOo96QtTTwhGGOich@postini.com; Mon, 02 Feb 2009 14:16:07 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009020216170329-3909446 ; Mon, 2 Feb 2009 16:17:03 -0600 In-Reply-To: <20090202214501.357673A6B47@core3.amsl.com> MIME-Version: 1.0 To: Internet-Drafts@ietf.org X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Mon, 2 Feb 2009 16:15:54 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 02/02/2009 04:16:00 PM, Serialize complete at 02/02/2009 04:16:00 PM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 02/02/2009 04:17:03 PM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 02/02/2009 04:17:09 PM, Serialize complete at 02/02/2009 04:17:09 PM Cc: roll@ietf.org, roll-bounces@ietf.org, i-d-announce@ietf.org Subject: Re: [Roll] I-D Action:draft-ietf-roll-building-routing-reqs-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1467065465==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multipart message in MIME format. --===============1467065465== Content-Type: multipart/alternative; boundary="=_alternative 007A4DD486257551_=" This is a multipart message in MIME format. --=_alternative 007A4DD486257551_= Content-Type: text/plain; charset="US-ASCII" All, As noted below, I have posted the -03 version of the "draft-ietf-roll-building-routing-reqs" to the repository. This version incorporates all known comments to date. The main commenters from the previous version were JP Vassuer, David Culler and Nicolas Riou. The following is the summary of changes in this version of the document: David and JP did a deep-dive on the overall content of the document pointing out textual and grammatical errors; nomenclature issues and requirement rewording to clarify and highlight the requirements. Nicolas helped resolve the issue of the 'bidirectionality' requirement and the use of low-power (or zero power) sensors. Some items that had been documented as routing requirements were removed and put into Appendix A. Appendix A incorporates building requirements that are out of scope for routing and hence ROLL, but may be of interest to other WGs. The 'Use Case' section was moved from the document body to Appendix B The Security requirements were refined and added to the Security Considerations (Chapter 7). Regards, Jerry Martocci Internet-Drafts@ietf.org Sent by: roll-bounces@ietf.org 02/02/2009 03:45 PM To i-d-announce@ietf.org cc roll@ietf.org Subject [Roll] I-D Action:draft-ietf-roll-building-routing-reqs-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Building Automation Routing Requirements in Low Power and Lossy Networks Author(s) : J. Martocci, et al. Filename : draft-ietf-roll-building-routing-reqs-03.txt Pages : 29 Date : 2009-02-02 The Routing Over Low power and Lossy network (ROLL) Working Group has been chartered to work on routing solutions for Low Power and Lossy networks (LLN) in various markets: Industrial, Commercial (Building), Home and Urban. Pursuant to this effort, this document defines the routing requirements for building automation. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-building-routing-reqs-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-roll-building-routing-reqs-03.txt _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 007A4DD486257551_= Content-Type: text/html; charset="US-ASCII"
All,

As noted below, I have posted the -03 version of the "draft-ietf-roll-building-routing-reqs" to the repository.  This version incorporates all known comments to date.  The main commenters from the previous version were JP Vassuer, David Culler and Nicolas Riou.  

The following is the summary of changes in this version of the document:

David and JP did a deep-dive on the overall content of the document pointing out textual and grammatical errors; nomenclature issues and requirement rewording to clarify and highlight the requirements.  

Nicolas helped resolve the issue of the 'bidirectionality' requirement and the use of low-power (or zero power) sensors.

Some items that had been documented as routing requirements were removed and put into Appendix A.  Appendix A incorporates building requirements that are out of scope for routing and hence ROLL, but may be of interest to other WGs.  

The 'Use Case' section was moved from the document body to Appendix B

The Security requirements were refined and added to the Security Considerations (Chapter 7).  

Regards,

Jerry Martocci







Internet-Drafts@ietf.org
Sent by: roll-bounces@ietf.org

02/02/2009 03:45 PM

To
i-d-announce@ietf.org
cc
roll@ietf.org
Subject
[Roll] I-D Action:draft-ietf-roll-building-routing-reqs-03.txt





A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF.


                Title           : Building Automation Routing Requirements in Low Power and Lossy Networks
                Author(s)       : J. Martocci, et al.
                Filename        : draft-ietf-roll-building-routing-reqs-03.txt
                Pages           : 29
                Date            : 2009-02-02

The Routing Over Low power and Lossy network (ROLL) Working Group has
been chartered to work on routing solutions for Low Power and Lossy
networks (LLN) in various markets: Industrial, Commercial (Building),
Home and Urban. Pursuant to this effort, this document defines the
routing requirements for building automation.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-building-routing-reqs-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-roll-building-routing-reqs-03.txt_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 007A4DD486257551_=-- --===============1467065465== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1467065465==-- From roll-bounces@ietf.org Mon Feb 2 14:33:56 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 647333A6BD4; Mon, 2 Feb 2009 14:33:56 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53AD13A6BD4 for ; Mon, 2 Feb 2009 14:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRiVEt0pyV2z for ; Mon, 2 Feb 2009 14:33:54 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id 55AA13A67B5 for ; Mon, 2 Feb 2009 14:33:53 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so1563172ywj.49 for ; Mon, 02 Feb 2009 14:33:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4XfEgLE3vnFH6ZxDEEWMHPta8iiCuLET1vkSal116Ok=; b=JncMj0zSjWcutqe5BixXu+++SZii7mvrkAB8q7iaJYEjJEFW2n4+5qC68MH550dFs3 Jd6F4kv0eX2DNDb9ANczf2LRZj3ZxHzZH18AGmcGCqUxEXNsyjXEMGtPvK/EEiyjtHgX FhZGiCyZaMBscrwvZLmPbJ7kQfz6QBQQd1ADY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FSb2Jd2tiapIQtX/4dMxroRDbB0/+FI0RcPX4zDP+VJB2h+PxlmDkyVj9i054BURoV r4tPR4p/YuDefYoNFvM6bMPM6FwLrCgUNwskuP90mmyu5hyBFg+Wp0FBW6Wfoaze90x+ fe3uYWkEOYsBoaps9SC4K9Rwu81dKuH/28UsE= MIME-Version: 1.0 Received: by 10.90.82.8 with SMTP id f8mr3080750agb.21.1233614014771; Mon, 02 Feb 2009 14:33:34 -0800 (PST) In-Reply-To: <44971175-E77F-46F6-BB1C-7C2A23FB7464@thomasclausen.org> References: <20090127000001.9F1F03A6819@core3.amsl.com> <654A66D8-FFBA-408C-8045-935DE5EB2D80@cs.stanford.edu> <374005f30901290757j1c37c25dpa22d67b0e1485747@mail.gmail.com> <49828189.6030906@eecs.berkeley.edu> <374005f30901300626l4106e298y9ff4d71c47c1abfb@mail.gmail.com> <42F2FA60-B59E-4CF4-87C2-203A55BE63D1@thomasclausen.org> <50446ECF-CE4B-4C6B-8F6F-9258D3AF593A@cs.stanford.edu> <374005f30901301106s2b59c315y29c6816498c843eb@mail.gmail.com> <44971175-E77F-46F6-BB1C-7C2A23FB7464@thomasclausen.org> Date: Mon, 2 Feb 2009 17:33:34 -0500 Message-ID: <374005f30902021433r15c0023fh58915444839fe9c7@mail.gmail.com> From: Ian Chakeres To: Thomas Heide Clausen Cc: Ross Callon , ROLL WG , "David E. Culler" Subject: Re: [Roll] I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Thomas as you pointed out, it has been possible for quite some time. Recently, I did edit the document to call more attention to this feature. Ian On Mon, Feb 2, 2009 at 1:26 PM, Thomas Heide Clausen wrote: > But wait, Ian, either my [now dated] implementation of an early version of > DYMO (-06, I think?) was wrong, or this has been possible since at least > then -- although maybe not at the time spelled out explicitly? > > Thomas > > On Jan 30, 2009, at 8:06 PM, Ian Chakeres wrote: > >> DYMO can take these properties/attributes into account using the >> (dimension-less) distance metric. >> >> I am guessing that we may have different opinions about how these >> constraints can/should be conveyed to a routing protocol. >> >> Ian >> >> On Fri, Jan 30, 2009 at 12:27 PM, Philip Levis >> wrote: >> >>> >>> " However, in low power networks it is also desirable to account for >>> the cost of forwarding through particular routers. Applications >>> require node or parameter constrained routing, which takes into >>> account node properties and attributes such as power, memory, and >>> battery life that dictate a router's willingness or ability to route >>> other packets." >> >> >> _______________________________________________ >> 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 From roll-bounces@ietf.org Mon Feb 2 14:35:25 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBA2628C125; Mon, 2 Feb 2009 14:35:25 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18E2B3A67B5 for ; Mon, 2 Feb 2009 14:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIcW0775U+8S for ; Mon, 2 Feb 2009 14:35:23 -0800 (PST) Received: from scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by core3.amsl.com (Postfix) with ESMTP id 161763A6BD6 for ; Mon, 2 Feb 2009 14:35:22 -0800 (PST) Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by scorpius.cttc.es (8.13.8/8.13.5) with ESMTP id n12MWai5029017; Mon, 2 Feb 2009 23:32:36 +0100 Received: from [127.0.0.1] (128.Red-83-61-207.dynamicIP.rima-tde.net [83.61.207.128]) by castor (Postfix) with ESMTP id 37F952FC26B; Mon, 2 Feb 2009 23:32:35 +0100 (CET) Message-ID: <498774C1.6080603@cttc.es> Date: Mon, 02 Feb 2009 23:33:37 +0100 From: Mischa Dohler User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Thomas Heide Clausen References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> In-Reply-To: <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> X-Antivirus: avast! (VPS 090202-0, 02/02/2009), Outbound message X-Antivirus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Mon, 02 Feb 2009 23:32:36 +0100 (CET) X-Scanned-By: MIMEDefang 2.57 on 84.88.62.197 Cc: Ross Callon , roll@ietf.org, Arsalan Tavakoli , "David E. Culler" , stevedh@cs.berkeley.edu Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Thomas, all, I have not been part of the decade design efforts of MANET but here some high-level differences which had been circulating before and which triggered the birth of ROLL: 6LoWPAN: - mainly specifies IPv6 header compression but not (optimized) routing per se; - is stuck to IEEE 802.15.4 radios. MANET: - design paradigm is to offer certain QoS and see how long we can run the network, whereas in ROLL we are likely to go the other way, ie optimize the longevity/energy efficiency and see what we can offer (maybe a hybrid of both); - properties of data contents is not (or in limited form) used to facilitate protocol designs, whereas in ROLL this is likely going to be central to the routing protocol design (example is the convergecast traffic pattern where not every node wishes to communicate with any other node, etc). As for your proposition, I have another one: Why don't we stop here and get on with the actual protocol design stage, knowing that some criteria may not be ideal or not applicable or of little use. Having a set of protocols at hand gives us a much clearer idea which parameters are of real key importance. I guess the discussion on the criteria could potentially last some more months - a time we cannot afford. The WSN market is different from the MANET market - it is very much alive and it is moving quickly. I know of at least two WSN companies who make good money with their networks but which have not gone for any MANET routing protocol - there must have been a reasoning behind this design choice. ROLL hopes to make companies choose its routing protocol(s) in the near future. Thanks for your support, Mischa. Thomas Heide Clausen wrote: > All, > > I promised a review, and I apologize that I wasn't able to do so before > the weekend as originally projected. > > Other than some typos that Chris and others have pointed out, I'll try > to offer my understanding of the problem space and suggest some ways of > addressing my main concerns.... > > My first main concern remain that it is not clear, still, how ROLL > positions itself with respect to MANET, 6LOW et. al, all of which appear > to be within the same space and within the IETF. This I-D sees ROLL as > presented with entirely new problems (the use of "novel" in the > abstract, the statement that "existing protocols were not designed with > these requirements in mind" seem to confirm this). > > Looking at the requirements listed, including "low power, low > bandwidth, low footprint", these appear similar to those which are also > brought forward in e.g. MANET and 6LOW. Reading (quickly, I confess) the > various requirements documents of the draft-ietf-roll series present > scenarios which are similar to those where MANETs are deployed, and are > thought deployed, as well. > > I also note that many additional (and unstated) characteristics between > ROLL and e.g. MANET are the same: mobile, wireless, fragility, > auto-configuration, IP routing, interface/link issues... > > Arguing that, as does this I-D, despite the above impression "ROLL is > novel and different" invites asking "how, exactly?" I think that this > question is valid, and merits being answered, before the evaluations in > this I-D can be judged fairly. > > Note that I come from a MANET background, and so I *could* interpret > from the ROLL discussion that where MANETs may aim for "low power, low > bandwidth, ....", ROLL may be able to quantify these as "below this firm > threshold" -- i.e. as a sort of "extreme" or "constrained" MANET. > > This is a personal observation, I note, which would allow me to > comprehend how ROLL and MANET are positioned relative to one another -- > but one which neither this I-D nor the requirements document spell out > or quantify -- or, for that matter, debunk. > > I think it's critical to understand this, in order to understand the > need for a new protocol development. I think it is important to document > this understanding in something with more persistency. > > If what I suggest above makes sense as a way of positioning ROLL and > MANET relative to one another, I'd suggest including something to this > effect in the survey I-D, as this I-D is the one making a *direct* > reference to the applicability of MANET protocols to ROLL. > > If what I suggest doesn't make sense at all, then I'd be happy to have > it debunked and, hopefully, through that debunking a > positioning/description that does ring true with us all can be produced? > > My second main concern is, that I still think that the choice of > criteria is unfortunate (not the word, Phill has me convinced on that > front, but the actual criteria). Control cost is, by all means, a rather > meaningless criteria when taken in isolation. I've sketched a > "zero-control-cost" routing protocol (flood all data - say use SMF, also > a MANET protocol, and also a rather "mature" I-D and wg item) which > would score well on the control cost criteria, but would likely be an > extremely bad choice for delivering unicast data. > > The metric which matters, and which should matter to ROLL in particular, > is "the total cost of getting user data through the network, including > control cost necessary to set up paths" -- as we know, every packet sent > and received costs bandwidth, energy and cycles -- user data no > different from contro. > > According to the criterions as set up by this I-D, a protocol producing > "longer than shortest paths" at the benefit of slightly lower control > cost would score better than a protocol producing "shortest paths" with > slightly higher control cost. This is not hypothetical, btw., there are > plenty of studies observing and reflecting upon this regarding the > different MANET protocols, in academic literature -- and observed in > real networks as well. > > I note that this trade-off (slightly longer paths for lower control > cost) may be perfectly fair, assuming that very low amounts of user data > traffic transit through the network. However, I do not see this > assumption mentioned as a justification for focusing on the control cost > metric and discarding the "path length" or the "total cost of getting > user data through the network". > > I believe that either these assumptions should be made explicit > ("there's so little user data traffic in a ROLL network that we do not > care about shortest paths") or -- if these assumptions do not hold, that > the evaluation criteria are incomplete. > > I note that it's true that we can always add another criteria ad > infinitum, and that's CLEARLY not what we want to do. However when I say > "incomplete" in the above, I simply suggest that based on what is > presented one cannot draw conclusions based on the evaluation > criteria....or, worse, that one draws the wrong conclusions based on the > information presented. > > So, in a nutshell, I suggest that we address (i) the positioning issue > and (ii) the criteria issue thus: > > o Describe as I proposed above if ROLL and MANETs position > themselves as I > have deducted. If my deduction is incorrect, then let's quickly > iterate on the list > as to understand how to do produce an alternative description. > If we can't do this, > then the conclusion can be that "we do not know how ROLL and > MANET position > themselves wrt each other", and we could then state that clearly? > > It *should* not be more than a couple of paragraphs worth of > text to add, I gather? > > o To the criteria, either of: > > - Add the assumption that "user data traffic is so low > that path lengths do not > matter nor does the cost of carrying user data traffice" > > - Add a criteria & evaluation of "path length" > > - Add a criteria & evaluation of "total cost for getting > user data through the network" > > This would make a large chunk of my concerns and issues vanish, and > allow correctly interpreting and evaluating the rest of the document. > > How does that sound as an approach forward? > > Cheers, > > Thomas > > On Jan 27, 2009, at 1:00 AM, Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Routing Over Low power and Lossy >> networks Working Group of the IETF. >> >> Title : Overview of Existing Routing Protocols for Low >> Power and Lossy Networks >> Author(s) : A. Tavakoli, S. Dawson-Haggerty, P. Levis >> Filename : draft-ietf-roll-protocols-survey-05.txt >> Pages : 26 >> Date : 2009-1-26 >> >> Networks of low power wireless devices introduce novel IP routing >> issues. Low-power wireless devices, such as sensors, actuators and >> smart objects, have difficult constraints: very limited memory, >> little processing power, and long sleep periods. As most of these >> devices are battery-powered, energy efficiency is critically >> important. Wireless link qualities can vary significantly over time, >> requiring protocols to make agile decisions yet minimize topology >> change energy costs. Routing over such low power and lossy networks >> has novel requirements that existing protocols may not address. This >> document provides a brief survey of the strengths and weaknesses of >> existing protocols with respect to this class of networks. From this >> survey it examines whether existing and mature IETF protocols can be >> used without modification in these networks, or whether further work >> is necessary. >> is necessary. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-survey-05.txt >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> Content-Type: text/plain >> Content-ID: <2009-1-26155804.I-D@ietf.org> >> >> _______________________________________________ >> 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 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Feb 2 15:22:39 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD2293A699C; Mon, 2 Feb 2009 15:22:39 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B324A3A699C for ; Mon, 2 Feb 2009 15:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwFHhASMTA20 for ; Mon, 2 Feb 2009 15:22:37 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 1CA763A67B5 for ; Mon, 2 Feb 2009 15:22:35 -0800 (PST) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id D74A69400A4; Tue, 3 Feb 2009 00:22:09 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id ED5E094001E; Tue, 3 Feb 2009 00:22:05 +0100 (CET) Message-ID: <49878003.8050307@gmail.com> Date: Tue, 03 Feb 2009 00:21:39 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Mischa Dohler References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> In-Reply-To: <498774C1.6080603@cttc.es> X-Antivirus: avast! (VPS 090202-0, 02/02/2009), Outbound message X-Antivirus-Status: Clean Cc: Arsalan Tavakoli , "David E. Culler" , stevedh@cs.berkeley.edu, roll@ietf.org, Ross Callon Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Mischa Dohler a =E9crit : [...] > As for your proposition, I have another one: Why don't we stop here > and get on with the actual protocol design stage, Sorry, which protocol do we mean to go on to protocol design stage? Could one imagine starting from scratch designing a new protocol? Alex knowing that some > criteria may not be ideal or not applicable or of little use. Having > a set of protocols at hand gives us a much clearer idea which > parameters are of real key importance. I guess the discussion on the > criteria could potentially last some more months - a time we cannot > afford. The WSN market is different from the MANET market - it is > very much alive and it is moving quickly. I know of at least two WSN > companies who make good money with their networks but which have not > gone for any MANET routing protocol - there must have been a > reasoning behind this design choice. ROLL hopes to make companies > choose its routing protocol(s) in the near future. > = > Thanks for your support, Mischa. > = > = > = > = > Thomas Heide Clausen wrote: >> All, >> = >> I promised a review, and I apologize that I wasn't able to do so = >> before the weekend as originally projected. >> = >> Other than some typos that Chris and others have pointed out, I'll >> try to offer my understanding of the problem space and suggest some >> ways of addressing my main concerns.... >> = >> My first main concern remain that it is not clear, still, how ROLL >> positions itself with respect to MANET, 6LOW et. al, all of which >> appear to be within the same space and within the IETF. This I-D >> sees ROLL as presented with entirely new problems (the use of >> "novel" in the abstract, the statement that "existing protocols >> were not designed with these requirements in mind" seem to confirm >> this). >> = >> Looking at the requirements listed, including "low power, low = >> bandwidth, low footprint", these appear similar to those which are >> also brought forward in e.g. MANET and 6LOW. Reading (quickly, I = >> confess) the various requirements documents of the draft-ietf-roll >> series present scenarios which are similar to those where MANETs >> are deployed, and are thought deployed, as well. >> = >> I also note that many additional (and unstated) characteristics = >> between ROLL and e.g. MANET are the same: mobile, wireless, >> fragility, auto-configuration, IP routing, interface/link issues... >> = >> = >> Arguing that, as does this I-D, despite the above impression "ROLL >> is novel and different" invites asking "how, exactly?" I think that >> this question is valid, and merits being answered, before the >> evaluations in this I-D can be judged fairly. >> = >> Note that I come from a MANET background, and so I *could* >> interpret from the ROLL discussion that where MANETs may aim for >> "low power, low bandwidth, ....", ROLL may be able to quantify >> these as "below this firm threshold" -- i.e. as a sort of "extreme" >> or "constrained" MANET. >> = >> This is a personal observation, I note, which would allow me to = >> comprehend how ROLL and MANET are positioned relative to one >> another -- but one which neither this I-D nor the requirements >> document spell out or quantify -- or, for that matter, debunk. >> = >> I think it's critical to understand this, in order to understand >> the need for a new protocol development. I think it is important to >> document this understanding in something with more persistency. >> = >> If what I suggest above makes sense as a way of positioning ROLL >> and MANET relative to one another, I'd suggest including something >> to this effect in the survey I-D, as this I-D is the one making a >> *direct* reference to the applicability of MANET protocols to ROLL. >> = >> = >> If what I suggest doesn't make sense at all, then I'd be happy to >> have it debunked and, hopefully, through that debunking a = >> positioning/description that does ring true with us all can be >> produced? >> = >> My second main concern is, that I still think that the choice of = >> criteria is unfortunate (not the word, Phill has me convinced on >> that front, but the actual criteria). Control cost is, by all >> means, a rather meaningless criteria when taken in isolation. I've >> sketched a "zero-control-cost" routing protocol (flood all data - >> say use SMF, also a MANET protocol, and also a rather "mature" I-D >> and wg item) which would score well on the control cost criteria, >> but would likely be an extremely bad choice for delivering unicast >> data. >> = >> The metric which matters, and which should matter to ROLL in = >> particular, is "the total cost of getting user data through the = >> network, including control cost necessary to set up paths" -- as we >> know, every packet sent and received costs bandwidth, energy and = >> cycles -- user data no different from contro. >> = >> According to the criterions as set up by this I-D, a protocol = >> producing "longer than shortest paths" at the benefit of slightly = >> lower control cost would score better than a protocol producing = >> "shortest paths" with slightly higher control cost. This is not = >> hypothetical, btw., there are plenty of studies observing and = >> reflecting upon this regarding the different MANET protocols, in = >> academic literature -- and observed in real networks as well. >> = >> I note that this trade-off (slightly longer paths for lower control >> cost) may be perfectly fair, assuming that very low amounts of >> user data traffic transit through the network. However, I do not >> see this assumption mentioned as a justification for focusing on >> the control cost metric and discarding the "path length" or the >> "total cost of getting user data through the network". >> = >> I believe that either these assumptions should be made explicit = >> ("there's so little user data traffic in a ROLL network that we do >> not care about shortest paths") or -- if these assumptions do not >> hold, that the evaluation criteria are incomplete. >> = >> I note that it's true that we can always add another criteria ad = >> infinitum, and that's CLEARLY not what we want to do. However when >> I say "incomplete" in the above, I simply suggest that based on >> what is presented one cannot draw conclusions based on the >> evaluation criteria....or, worse, that one draws the wrong >> conclusions based on the information presented. >> = >> So, in a nutshell, I suggest that we address (i) the positioning >> issue and (ii) the criteria issue thus: >> = >> o Describe as I proposed above if ROLL and MANETs position = >> themselves as I have deducted. If my deduction is incorrect, then >> let's quickly iterate on the list as to understand how to do >> produce an alternative description. If we can't do this, then the >> conclusion can be that "we do not know how ROLL and MANET position = >> themselves wrt each other", and we could then state that clearly? = >> It *should* not be more than a couple of paragraphs worth of text >> to add, I gather? >> = >> o To the criteria, either of: >> = >> - Add the assumption that "user data traffic is so low that path >> lengths do not matter nor does the cost of carrying user data >> traffice" >> = >> - Add a criteria & evaluation of "path length" >> = >> - Add a criteria & evaluation of "total cost for getting user >> data through the network" >> = >> This would make a large chunk of my concerns and issues vanish, and >> allow correctly interpreting and evaluating the rest of the >> document. >> = >> How does that sound as an approach forward? >> = >> Cheers, >> = >> Thomas >> = >> On Jan 27, 2009, at 1:00 AM, Internet-Drafts@ietf.org wrote: >> = >>> A New Internet-Draft is available from the on-line >>> Internet-Drafts directories. This draft is a work item of the >>> Routing Over Low power and Lossy networks Working Group of the >>> IETF. >>> = >>> Title : Overview of Existing Routing Protocols for Low = >>> Power and Lossy Networks Author(s) : A. Tavakoli, S. >>> Dawson-Haggerty, P. Levis Filename : >>> draft-ietf-roll-protocols-survey-05.txt Pages : 26 Date >>> : 2009-1-26 Networks of low power wireless devices introduce >>> novel IP routing issues. Low-power wireless devices, such as >>> sensors, actuators and smart objects, have difficult constraints: >>> very limited memory, little processing power, and long sleep >>> periods. As most of these devices are battery-powered, energy >>> efficiency is critically important. Wireless link qualities can >>> vary significantly over time, requiring protocols to make agile >>> decisions yet minimize topology change energy costs. Routing >>> over such low power and lossy networks has novel requirements >>> that existing protocols may not address. This document provides >>> a brief survey of the strengths and weaknesses of existing >>> protocols with respect to this class of networks. From this = >>> survey it examines whether existing and mature IETF protocols can >>> be used without modification in these networks, or whether >>> further work is necessary. is necessary. >>> = >>> A URL for this Internet-Draft is: = >>> http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-survey-05= .txt >>> = >>> = >>> = >>> Internet-Drafts are also available by anonymous FTP at: = >>> ftp://ftp.ietf.org/internet-drafts/ >>> = >>> Below is the data which will enable a MIME compliant mail reader = >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. Content-Type: text/plain Content-ID: >>> <2009-1-26155804.I-D@ietf.org> >>> = >>> _______________________________________________ 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 > _______________________________________________ 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 From roll-bounces@ietf.org Mon Feb 2 16:03:35 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9B473A69C1; Mon, 2 Feb 2009 16:03:35 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5B0D3A6AAF for ; Mon, 2 Feb 2009 16:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVtJQ8xLHUCy for ; Mon, 2 Feb 2009 16:03:33 -0800 (PST) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by core3.amsl.com (Postfix) with ESMTP id 2B6903A6975 for ; Mon, 2 Feb 2009 16:03:31 -0800 (PST) Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id 4669A4B006D; Tue, 3 Feb 2009 01:03:05 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp2-g21.free.fr (Postfix) with ESMTP id 4A4C64B006B; Tue, 3 Feb 2009 01:03:02 +0100 (CET) Message-ID: <4987899C.3090708@gmail.com> Date: Tue, 03 Feb 2009 01:02:36 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Mischa Dohler References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> In-Reply-To: <498774C1.6080603@cttc.es> X-Antivirus: avast! (VPS 090202-0, 02/02/2009), Outbound message X-Antivirus-Status: Clean Cc: Arsalan Tavakoli , "David E. Culler" , stevedh@cs.berkeley.edu, roll@ietf.org, Ross Callon Subject: Re: [Roll] 6lowpan WG items and ROLL WG activities (was: Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Mischa Dohler a =E9crit : [...] > 6LoWPAN: - mainly specifies IPv6 header compression but not > (optimized) routing per se; Not only Header Compression, 6lowpan WG seems to also be looking at Neighbor Discovery for 802.15.4, which is quite relevant here I believe, because ZigBee was mentioned recently here. > - [6lowpan] is stuck to IEEE 802.15.4 radios. I think it is good to list the radios ROLL looks at: IEEE 802.15.4 SP100 http://tinyurl.com/4d3j64 ZigBee HART http://tinyurl.com/4d3j64 Alex > = > MANET: - design paradigm is to offer certain QoS and see how long we > can run the network, whereas in ROLL we are likely to go the other > way, ie optimize the longevity/energy efficiency and see what we can > offer (maybe a hybrid of both); - properties of data contents is not > (or in limited form) used to facilitate protocol designs, whereas in > ROLL this is likely going to be central to the routing protocol > design (example is the convergecast traffic pattern where not every > node wishes to communicate with any other node, etc). > = > As for your proposition, I have another one: Why don't we stop here > and get on with the actual protocol design stage, knowing that some > criteria may not be ideal or not applicable or of little use. Having > a set of protocols at hand gives us a much clearer idea which > parameters are of real key importance. I guess the discussion on the > criteria could potentially last some more months - a time we cannot > afford. The WSN market is different from the MANET market - it is > very much alive and it is moving quickly. I know of at least two WSN > companies who make good money with their networks but which have not > gone for any MANET routing protocol - there must have been a > reasoning behind this design choice. ROLL hopes to make companies > choose its routing protocol(s) in the near future. > = > Thanks for your support, Mischa. > = > = > = > = > Thomas Heide Clausen wrote: >> All, >> = >> I promised a review, and I apologize that I wasn't able to do so = >> before the weekend as originally projected. >> = >> Other than some typos that Chris and others have pointed out, I'll >> try to offer my understanding of the problem space and suggest some >> ways of addressing my main concerns.... >> = >> My first main concern remain that it is not clear, still, how ROLL >> positions itself with respect to MANET, 6LOW et. al, all of which >> appear to be within the same space and within the IETF. This I-D >> sees ROLL as presented with entirely new problems (the use of >> "novel" in the abstract, the statement that "existing protocols >> were not designed with these requirements in mind" seem to confirm >> this). >> = >> Looking at the requirements listed, including "low power, low = >> bandwidth, low footprint", these appear similar to those which are >> also brought forward in e.g. MANET and 6LOW. Reading (quickly, I = >> confess) the various requirements documents of the draft-ietf-roll >> series present scenarios which are similar to those where MANETs >> are deployed, and are thought deployed, as well. >> = >> I also note that many additional (and unstated) characteristics = >> between ROLL and e.g. MANET are the same: mobile, wireless, >> fragility, auto-configuration, IP routing, interface/link issues... >> = >> = >> Arguing that, as does this I-D, despite the above impression "ROLL >> is novel and different" invites asking "how, exactly?" I think that >> this question is valid, and merits being answered, before the >> evaluations in this I-D can be judged fairly. >> = >> Note that I come from a MANET background, and so I *could* >> interpret from the ROLL discussion that where MANETs may aim for >> "low power, low bandwidth, ....", ROLL may be able to quantify >> these as "below this firm threshold" -- i.e. as a sort of "extreme" >> or "constrained" MANET. >> = >> This is a personal observation, I note, which would allow me to = >> comprehend how ROLL and MANET are positioned relative to one >> another -- but one which neither this I-D nor the requirements >> document spell out or quantify -- or, for that matter, debunk. >> = >> I think it's critical to understand this, in order to understand >> the need for a new protocol development. I think it is important to >> document this understanding in something with more persistency. >> = >> If what I suggest above makes sense as a way of positioning ROLL >> and MANET relative to one another, I'd suggest including something >> to this effect in the survey I-D, as this I-D is the one making a >> *direct* reference to the applicability of MANET protocols to ROLL. >> = >> = >> If what I suggest doesn't make sense at all, then I'd be happy to >> have it debunked and, hopefully, through that debunking a = >> positioning/description that does ring true with us all can be >> produced? >> = >> My second main concern is, that I still think that the choice of = >> criteria is unfortunate (not the word, Phill has me convinced on >> that front, but the actual criteria). Control cost is, by all >> means, a rather meaningless criteria when taken in isolation. I've >> sketched a "zero-control-cost" routing protocol (flood all data - >> say use SMF, also a MANET protocol, and also a rather "mature" I-D >> and wg item) which would score well on the control cost criteria, >> but would likely be an extremely bad choice for delivering unicast >> data. >> = >> The metric which matters, and which should matter to ROLL in = >> particular, is "the total cost of getting user data through the = >> network, including control cost necessary to set up paths" -- as we >> know, every packet sent and received costs bandwidth, energy and = >> cycles -- user data no different from contro. >> = >> According to the criterions as set up by this I-D, a protocol = >> producing "longer than shortest paths" at the benefit of slightly = >> lower control cost would score better than a protocol producing = >> "shortest paths" with slightly higher control cost. This is not = >> hypothetical, btw., there are plenty of studies observing and = >> reflecting upon this regarding the different MANET protocols, in = >> academic literature -- and observed in real networks as well. >> = >> I note that this trade-off (slightly longer paths for lower control >> cost) may be perfectly fair, assuming that very low amounts of >> user data traffic transit through the network. However, I do not >> see this assumption mentioned as a justification for focusing on >> the control cost metric and discarding the "path length" or the >> "total cost of getting user data through the network". >> = >> I believe that either these assumptions should be made explicit = >> ("there's so little user data traffic in a ROLL network that we do >> not care about shortest paths") or -- if these assumptions do not >> hold, that the evaluation criteria are incomplete. >> = >> I note that it's true that we can always add another criteria ad = >> infinitum, and that's CLEARLY not what we want to do. However when >> I say "incomplete" in the above, I simply suggest that based on >> what is presented one cannot draw conclusions based on the >> evaluation criteria....or, worse, that one draws the wrong >> conclusions based on the information presented. >> = >> So, in a nutshell, I suggest that we address (i) the positioning >> issue and (ii) the criteria issue thus: >> = >> o Describe as I proposed above if ROLL and MANETs position = >> themselves as I have deducted. If my deduction is incorrect, then >> let's quickly iterate on the list as to understand how to do >> produce an alternative description. If we can't do this, then the >> conclusion can be that "we do not know how ROLL and MANET position = >> themselves wrt each other", and we could then state that clearly? = >> It *should* not be more than a couple of paragraphs worth of text >> to add, I gather? >> = >> o To the criteria, either of: >> = >> - Add the assumption that "user data traffic is so low that path >> lengths do not matter nor does the cost of carrying user data >> traffice" >> = >> - Add a criteria & evaluation of "path length" >> = >> - Add a criteria & evaluation of "total cost for getting user >> data through the network" >> = >> This would make a large chunk of my concerns and issues vanish, and >> allow correctly interpreting and evaluating the rest of the >> document. >> = >> How does that sound as an approach forward? >> = >> Cheers, >> = >> Thomas >> = >> On Jan 27, 2009, at 1:00 AM, Internet-Drafts@ietf.org wrote: >> = >>> A New Internet-Draft is available from the on-line >>> Internet-Drafts directories. This draft is a work item of the >>> Routing Over Low power and Lossy networks Working Group of the >>> IETF. >>> = >>> Title : Overview of Existing Routing Protocols for Low = >>> Power and Lossy Networks Author(s) : A. Tavakoli, S. >>> Dawson-Haggerty, P. Levis Filename : >>> draft-ietf-roll-protocols-survey-05.txt Pages : 26 Date >>> : 2009-1-26 Networks of low power wireless devices introduce >>> novel IP routing issues. Low-power wireless devices, such as >>> sensors, actuators and smart objects, have difficult constraints: >>> very limited memory, little processing power, and long sleep >>> periods. As most of these devices are battery-powered, energy >>> efficiency is critically important. Wireless link qualities can >>> vary significantly over time, requiring protocols to make agile >>> decisions yet minimize topology change energy costs. Routing >>> over such low power and lossy networks has novel requirements >>> that existing protocols may not address. This document provides >>> a brief survey of the strengths and weaknesses of existing >>> protocols with respect to this class of networks. From this = >>> survey it examines whether existing and mature IETF protocols can >>> be used without modification in these networks, or whether >>> further work is necessary. is necessary. >>> = >>> A URL for this Internet-Draft is: = >>> http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-survey-05= .txt >>> = >>> = >>> = >>> Internet-Drafts are also available by anonymous FTP at: = >>> ftp://ftp.ietf.org/internet-drafts/ >>> = >>> Below is the data which will enable a MIME compliant mail reader = >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. Content-Type: text/plain Content-ID: >>> <2009-1-26155804.I-D@ietf.org> >>> = >>> _______________________________________________ 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 > _______________________________________________ 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 From roll-bounces@ietf.org Mon Feb 2 16:23:29 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 577283A6B18; Mon, 2 Feb 2009 16:23:29 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3243B3A6AB6 for ; Mon, 2 Feb 2009 16:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDmnEHMk-ub5 for ; Mon, 2 Feb 2009 16:23:27 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 37B0F3A69C1 for ; Mon, 2 Feb 2009 16:23:25 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 5AFB4D48079; Tue, 3 Feb 2009 01:22:59 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id AF406D48042; Tue, 3 Feb 2009 01:22:56 +0100 (CET) Message-ID: <49878E46.7050105@gmail.com> Date: Tue, 03 Feb 2009 01:22:30 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Arsalan Tavakoli References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <69306dde0902021535i353b02fdie689bf78d6fce7f5@mail.gmail.com> In-Reply-To: <69306dde0902021535i353b02fdie689bf78d6fce7f5@mail.gmail.com> X-Antivirus: avast! (VPS 090202-0, 02/02/2009), Outbound message X-Antivirus-Status: Clean Cc: "David E. Culler" , roll@ietf.org, Ross Callon Subject: Re: [Roll] requirements? (was: Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Arsalan Tavakoli a =E9crit : > As was discussed earlier, at the protocol design stage, the group = > will be soliciting specifications for a protocol that meets the ROLL > requirements, whether it is an extension/modification of an existing > protocol, or a specification written from scratch. Advancing to > that stage simply implies that no such specification (in its current > form) presently exists. The protocol-survey draft wouldn't impede going to the next stage, were it silently updated every 6 months, away from LastCall. We could probably then discuss requirements. Let me humbly propose a 're-usability' requirement, common: "an = important requirement is to identify and reuse as much as possible an existing protocol that pertains to this application domain; this has the immediate advantage of software availability for first prototypes". What do you think? Alex _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Feb 2 23:25:28 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42B2C3A6993; Mon, 2 Feb 2009 23:25:28 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AB983A6951 for ; Mon, 2 Feb 2009 23:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NSDaVBQ3GqR for ; Mon, 2 Feb 2009 23:25:26 -0800 (PST) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by core3.amsl.com (Postfix) with ESMTP id 089B53A6993 for ; Mon, 2 Feb 2009 23:25:24 -0800 (PST) Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id B42AF818137; Tue, 3 Feb 2009 08:24:59 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp3-g21.free.fr (Postfix) with ESMTP id 2929A8180E5; Tue, 3 Feb 2009 08:24:56 +0100 (CET) Message-ID: <4987F12D.3000609@gmail.com> Date: Tue, 03 Feb 2009 08:24:29 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Arsalan Tavakoli References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <69306dde0902021535i353b02fdie689bf78d6fce7f5@mail.gmail.com> <49878E46.7050105@gmail.com> <69306dde0902021653u4e9e0b89kaba0515c65824df2@mail.gmail.com> In-Reply-To: <69306dde0902021653u4e9e0b89kaba0515c65824df2@mail.gmail.com> X-Antivirus: avast! (VPS 090202-1, 02/02/2009), Outbound message X-Antivirus-Status: Clean Cc: Ross Callon , roll@ietf.org, "David E. Culler" Subject: Re: [Roll] Why is next stage impeded by protocol-survey draft? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Arsalan Tavakoli a =E9crit : > On Mon, Feb 2, 2009 at 4:22 PM, Alexandru Petrescu = > > = > wrote: > = > Arsalan Tavakoli a =E9crit : > = >>> As was discussed earlier, at the protocol design stage, the group >>> will be soliciting specifications for a protocol that meets the = >>> ROLL requirements, whether it is an extension/modification of an >>> existing protocol, or a specification written from scratch. = >>> Advancing to that stage simply implies that no such specification >>> (in its current form) presently exists. >> = >> The protocol-survey draft wouldn't impede going to the next stage, = >> were it silently updated every 6 months, away from LastCall. > = > I don't particularly understand the need for such a move. By = > definition, holding up the protocol-survey draft IS holding up going = > to the next stage. I don't understand this definition at all. I think we could very well go to the next stage without necessarily LC'ing the protocol-survey draft. In this way we could avoid deep controversion about which existing protocol is better. If protocol-survey sets some conclusions - I think they will constrain the next stage more than the requirements drafts. Don't you think so? I think each item in the Charter's timeline is completely independent, = no? (they're not sequentially dependent). Alex The purpose of the protocol survey draft is to > determine whether an existing specification, again in current form, = > satisfies the set of criteria. Our current charter is limited to = > answering this question. In order to move to the design stage, at = > which point we start discussing actual protocol and design, we need = > to recharter, and we can not do that until this draft is finalized, = > hence why this draft impedes us from moving on. By definition, the = > protocol specified during the next stage will satisfy the ROLL = > requirements, and changes to existing protocol specifications (for = > those evaluated in the draft) to allow them to pass ROLL criteria, = > can be presented during the next stage, which would make an update of > the document a moot point. > = > = > = > = > We could probably then discuss requirements. > = > Let me humbly propose a 're-usability' requirement, common: "an = > important requirement is to identify and reuse as much as possible an > existing protocol that pertains to this application domain; this has > the immediate advantage of software availability for first = > prototypes". > = > = > Again, as David has written frequently, these are all very important = > issues that will need to be discussed when we move to the protocol = > and design stage. However, this is completely outside the scope of = > the protocol survey draft, and hence I believe should not be = > discussed in the draft. The draft takes no position on such a = > requirement. If we can close on this draft, then we can recharter, = > and move on to the next stage, at which point all these issues that = > everybody is so anxious to get to can be discussed, rather than = > having to continually to postpone them as we block on this document. > = > = > = > = > What do you think? > = > Alex _______________________________________________ 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 From roll-bounces@ietf.org Tue Feb 3 01:04:49 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3EAF3A67F1; Tue, 3 Feb 2009 01:04:49 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95D013A67F1 for ; Tue, 3 Feb 2009 01:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEfpwQCOLeeo for ; Tue, 3 Feb 2009 01:04:48 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id AD46E3A677D for ; Tue, 3 Feb 2009 01:04:47 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1392gWm015409; Tue, 3 Feb 2009 10:02:42 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1394KL8008669; Tue, 3 Feb 2009 10:04:20 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n1394JFb020746; Tue, 3 Feb 2009 10:04:20 +0100 Message-ID: <49880893.3010106@gmail.com> Date: Tue, 03 Feb 2009 10:04:19 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Arsalan Tavakoli References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <69306dde0902021535i353b02fdie689bf78d6fce7f5@mail.gmail.com> <49878E46.7050105@gmail.com> <69306dde0902021653u4e9e0b89kaba0515c65824df2@mail.gmail.com> In-Reply-To: <69306dde0902021653u4e9e0b89kaba0515c65824df2@mail.gmail.com> Cc: roll@ietf.org Subject: Re: [Roll] requirements? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Arsalan Tavakoli a =E9crit : > A. Petrescu wrote: >> We could probably then discuss requirements. >> = >> Let me humbly propose a 're-usability' requirement, common: "an = >> important requirement is to identify and reuse as much as possible >> an existing protocol that pertains to this application domain; this >> has the immediate advantage of software availability for first = >> prototypes". > = > Again, as David has written frequently, these are all very important > issues that will need to be discussed when we move to the protocol > and design stage. However, this is completely outside the scope of > the protocol survey draft, and hence I believe should not be > discussed in the draft. The draft takes no position on such a > requirement. Sorry, I meant the reusability requirement proposal for the 4 = requirements drafts, not for the protocols-survey draft. What do you think? Alex _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Feb 3 04:19:42 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EA4C3A67B2; Tue, 3 Feb 2009 04:19:42 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CE233A63EB for ; Tue, 3 Feb 2009 04:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.493 X-Spam-Level: X-Spam-Status: No, score=-10.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bWxjBCUJBeU for ; Tue, 3 Feb 2009 04:19:40 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 32D623A67B2 for ; Tue, 3 Feb 2009 04:19:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,372,1231113600"; d="scan'208";a="32690032" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2009 12:19:19 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n13CJJsv027761; Tue, 3 Feb 2009 13:19:19 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n13CJJPX027743; Tue, 3 Feb 2009 12:19:19 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 13:19:19 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 13:19:18 +0100 Message-Id: <0B295CCB-D8C8-48D6-955C-68F195C0C84D@cisco.com> From: JP Vasseur To: Ulrich Herberg In-Reply-To: <49818BDF.5000904@polytechnique.edu> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Feb 2009 13:19:18 +0100 References: <20090127000001.9F1F03A6819@core3.amsl.com> <654A66D8-FFBA-408C-8045-935DE5EB2D80@cs.stanford.edu> <49818BDF.5000904@polytechnique.edu> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Feb 2009 12:19:19.0009 (UTC) FILETIME=[A3509D10:01C985F9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2059; t=1233663559; x=1234527559; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20I-D=20ACTION=3Adraft-ietf-roll -protocols-survey-05.txt |Sender:=20; bh=nQaHzA6bfYubbF8qJkJ8IIOTVQvvur6OHyFcv1uPWJg=; b=mC/O+kQxNL3MX+dV+eyNwaymCWBtQp6nyVZl1zC60CHKExNEL3vtxXej7s P8Y3b95n2I9cJKrHX8TeOSe3Geor7pvs47hoJEGB70+mxoPBY1QYckIZEiB6 5hf/Rxryap; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG Subject: Re: [Roll] I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org OK Thanks. JP. On Jan 29, 2009, at 11:58 AM, Ulrich Herberg wrote: > Hi, > > thanks to the authors for this revised version of the ID. It certainly > has improved a lot. All my minor points have been addressed and > included. Some of my general remarks (applicability statement, > security > considerations section, split up of criteria and protocol evaluation > into two documents) in my last email have been noted but not > included. I > don't have anything new to add. > > Best regards, > Ulrich > > Philip Levis wrote: >> On Jan 26, 2009, at 4:00 PM, Internet-Drafts@ietf.org wrote: >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Routing Over Low power and Lossy >>> networks Working Group of the IETF. >>> >>> Title : Overview of Existing Routing Protocols for Low Power and >>> Lossy Networks >>> Author(s) : A. Tavakoli, S. Dawson-Haggerty, P. Levis >>> Filename : draft-ietf-roll-protocols-survey-05.txt >>> Pages : 26 >>> Date : 2009-1-26 >> >> Edits: >> >> Fixed all editorial nits (spelling, etc.) from Thomas and Ulrich. >> >> Fixed incorrect table values for OLSRv2. Triggered updates are >> optional, so loss is a ?. >> >> Changed "Suitability Summary" to "Criteria" >> >> Fixed O(R + e) to O(R) + e. >> >> Removed redundant paragraph in 4.4 "The control cost criterion is a >> necessary but not..." >> >> Made IETF scope more specific ("any protocol" -> "any protocol >> outside >> the IETF"). >> >> Added errata to terminology section ("NOT RECOMMENDED"). >> >> Cleaned up RFC/draft terminology in Section 4. >> >> Clarified "unbounded" control overhead. >> >> Explained 4kB of RAM. >> >> Phil >> >> >> >> >> >> _______________________________________________ >> 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 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Feb 3 04:20:58 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABEE13A68FF; Tue, 3 Feb 2009 04:20:58 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26B0B3A68FF for ; Tue, 3 Feb 2009 04:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.497 X-Spam-Level: X-Spam-Status: No, score=-10.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGusgtpqk4vD for ; Tue, 3 Feb 2009 04:20:56 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D49263A67B2 for ; Tue, 3 Feb 2009 04:20:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,372,1231113600"; d="scan'208";a="32690179" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2009 12:20:35 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n13CKZDX028158; Tue, 3 Feb 2009 13:20:35 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n13CKZJq028177; Tue, 3 Feb 2009 12:20:35 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 13:20:35 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 13:20:34 +0100 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4981CF94.7070800@eecs.berkeley.edu> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Feb 2009 13:20:34 +0100 References: <49819061.8090902@gmail.com> <4981CF94.7070800@eecs.berkeley.edu> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Feb 2009 12:20:35.0023 (UTC) FILETIME=[D09F6DF0:01C985F9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1583; t=1233663635; x=1234527635; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Rechartering=20discussion? |Sender:=20; bh=7D7ERP5C+Bafi1fpJWK2VQwz08Y2ATHBZMiiyJpOXyM=; b=RKCGjnCCHqWbtV/ceLI/jtwvsAPMV8lf/Y4jbYhPb0C78iSj4ygnaOeBwj 5SjhH11IrOuAPk8vbbtANNSzVLFnk+Lyz49ArReeCUll0TBTZhefwKugB447 v2BFvje28O; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] Rechartering discussion? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Alex, On Jan 29, 2009, at 4:47 PM, David E. Culler wrote: > Yes, it has been discussed at every IETF meeting and on the mailing > list. The original charter was extremely restrictive. We could not > begin any protocol design, not even tweaks to existing protocols, > until we completed the requirements documents and the protocol > survey. The rationale was that the outcome of this analysis might > arrive at the conclusion that no new routing protocol work is > needed. The charter was designed to maintain that as an option so > that it would not be a foregone conclusion that the group would jump > whole hog into yet another routing protocol. This has been in the > slide materials and minutes over every meeting. It is why it is so > important that we complete this phase of work. We cannot even > consider changing one line of a protocol draft until we recharter. > > Alexandru Petrescu wrote: >> Rechartering ROLL has been mentioned to me in private several >> times, and now in public, when discussing the protocol-survey draft. >> >> This rechartering is news to me. Has ROLL rechartering been >> already discussed publicly on the list? Sorry I may have missed >> emails. It is coming ... Thanks. JP. >> >> >> Alex >> >> _______________________________________________ >> 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 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Feb 3 04:21:12 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4BF43A6A63; Tue, 3 Feb 2009 04:21:12 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87A8228C0FF for ; Tue, 3 Feb 2009 04:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.498 X-Spam-Level: X-Spam-Status: No, score=-10.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ax-pq5ZaE6wz for ; Tue, 3 Feb 2009 04:21:09 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5071028C138 for ; Tue, 3 Feb 2009 04:21:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,372,1231113600"; d="scan'208,217";a="32690200" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2009 12:20:48 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n13CKmKe028205; Tue, 3 Feb 2009 13:20:48 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n13CKlf5028241; Tue, 3 Feb 2009 12:20:48 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 13:20:47 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 13:20:46 +0100 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4981FFA3.5030803@gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Feb 2009 13:20:46 +0100 References: <4981FFA3.5030803@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Feb 2009 12:20:47.0242 (UTC) FILETIME=[D7E7E6A0:01C985F9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=24963; t=1233663648; x=1234527648; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20More=20comments=20and=20some=2 0questions=20on=20the=20protocol-survey=20draft |Sender:=20; bh=yq2J40y8CM6xORnmIxV/ab4aoxyf8SDkxBK9GJAjaKM=; b=RglU34pyI5pJSsF9eKtmRPrG76hbvhp1WbUpGznilbSkn9Yn82XXUeNP66 nVEZK+Sj5f0MRv3tlyI4uuGc/2doP9HK16tV2cIc7PTauAxGksJp+sfQlFZL /Z+72MoNc7; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG Subject: Re: [Roll] More comments and some questions on the protocol-survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0012976274==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0012976274== Content-Type: multipart/alternative; boundary=Apple-Mail-98--194107359 --Apple-Mail-98--194107359 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On Jan 29, 2009, at 8:12 PM, Alexandru Petrescu wrote: > In this mail I argue about: > -Table Scalability can't be a factor to disqualify any protocol (specs > are eminently silent about how tables are represented and thus > how they scale). > -Loss Response can't be a factor to discard NEMO (MR only sends to HA, > not to n destinations upon link up/down events). > -Control Cost tests can very well accept MIP-based NEMO protocol in > that > MIP and ND have rate limitation. > > -Asking about Link and Node cost metrics: maybe that's it actually. > > -Suggest corrections to the use of "Neighbor disovery" term, makes > think > of "Neighbor Discovery" > -suggest that ND doesn't risk storms of replied RAs to a RS, because > they're randomly spaced in time. > -suggest that addresses being a direct expression of the underlying > network topology is a deep Internet assumption that can't be changed. > -ask about necessity of asymmetric support. > > For details, when time permits, see below. > >> 4.2. Table Scalability >> Scalability support for large networks of sensors is highlighted as a >> key requirement by all three application requirements documents. > [...] >> More precisely, routing table size scaling with O(N) or O(L) fails. A >> table that scales O(D) (assuming no N or L) passes. > > This is a problem of representing data structures, and not of the > protocol per se. I hope some protocol isn't discarded by some > dangerously false assumptions on the way it represents its so-called > tables in the memory. > > For example there exist various implementations of Binding Cache (of > MIP) and Neighbor Cache (of ND) which are more or less efficient. > Some > are quick at finding, others at inserting, others are smaller, and > so on. > > Also related to this: >> For example, a node with 4kB of RAM, a typical amount for top-end >> microcontrollers, cannot store full neighbor state when it has 1000 >> other nodes nearby. > > LEt's see: which addresses IPv4 or IPv6? How are they represented? > Are > they covered by a long or short prefix length (subnet address)? Which > link layer? > > And is it assumed that a micro-controller needs to talk to 1000 > neighbors at the same time? Because the Neighbor Cache only holds the > neighbors to which a node has recently talked to, there are tweakable > expiry timers. And I doubt there exists a link layer supporting this > assumption of one-to-1000 simultaneous neighbors communication. > >> 4.3. Loss Response >> In low power and lossy networks, links routinely come and go due to >> being close to the signal-to-noise threshold at the physical layer. >> It is important that link churn not trigger unnecessary responses >> by the routing protocol. > [...] >> A protocol which requires many link changes to propagate across the >> entire network fails. Protocols which constrain the scope of >> information propagation to only when they affect routes to active >> destinations, or to local neighborhoods, pass. Protocols which allow >> proactively path maintenance pass if the choice of which paths to >> maintain is user-specified. >> More precisely, loss responses that require O(N) transmissions >> fail, while responses that can rely on O(1) local broadcasts or >> O(D) route updates pass. > > I think Mobile IP-based NEMO protocol should pass this test. Whenever > the Mobile Router's egress interface comes down or up only the HA > (Home > Agent) is let know about it, it's not O(N), it's simply 1. Besides, > it > has a retransmission control specified, such as to not make too much > noise. > >> 4.4. Control Cost > [...] >> a common case [I-D.ietf-roll-indus-routing-reqs]. In terms of >> routing structure, any proposed LLN routing protocol ought to support >> the autonomous organization and configuration of the network at the >> lowest possible energy cost [I-D.ietf-roll-urban-routing-reqs]. >> All routing protocols must transmit additional data to detect >> neighbors, build routes, transmit routing tables, or otherwise >> conduct routing. As low-power wireless networks can have very low >> data rates, protocols which require a minimum control packet rate can >> have an unbounded control overhead per data packet. This is >> particularly true for event-driven networks, which only report data >> when certain conditions are met. Regions of a network which never >> meet the condition can be forced to send significant control >> traffic even when there is no data to send. For these use cases, >> hard-coded timing constants are unacceptable, because they imply a >> prior knowledge of the expected data rate. >> Of course, protocols require the ability to send at least a very >> small amount of control traffic, in order to discover a topology. But >> this bootstrapping discovery and maintenance traffic should be >> small: communicating once an hour is far more reasonable than >> communicating once a second. So while control traffic should be >> bounded by data traffic, it requires some leeway to bootstrap and >> maintain a long-lived yet idle network. >> In the case of control traffic, the communication rate (sum of >> transmissions and receptions at a node) is a better measure than >> the transmission rate (since energy is consumed for both >> transmissions and receptions). Controlling the transmission rate >> is insufficient, as it would mean that the energy cost (sum of >> transmission and receptions) of control traffic could grow with O(L). >> A protocol fails the control cost criterion if its per-node control >> traffic (transmissions plus receptions) rate is not bounded by the >> data rate plus a small constant. > > Neighbor Discovery and Mobile IPv6 both have built-in rate limitation > mechanisms. > >> For example, a protocol using a beacon rate only passes if it can be >> turned arbitrarily low, in order to match the data rate. > > Both MIP and ND do that. It's turned arbitrarily low by an > administrator. I hope that's ok. > >> 4.5. Link and Node Cost >> These two criteria specify how a protocol chooses routes for data >> packets to take through the network. Classical routing algorithms >> typically acknowledge the differing costs of paths and may use a >> shortest path algorithm to find paths. This is a requirement for low >> power networks, as links must be evaluated as part of an objective >> function across various metric types, such as minimizing latency and >> maximizing reliability [I-D.ietf-roll-indus-routing-reqs]. >> However, in low power networks it is also desirable to account for >> the cost of forwarding through particular routers. Applications >> require node or parameter constrained routing, which takes into >> account node properties and attributes such as power, memory, and >> battery life that dictate a router's willingness or ability to route >> other packets. Home routing requirements note that devices will >> vary in their duty cycle, and that routing protocols should prefer >> nodes with permanent power [I-D.ietf-roll-home-routing-reqs]. The >> urban requirements note that routing protocols may wish to take >> advantage of differing data processing and management capabilities >> among network devices [I-D.ietf-roll-urban-routing-reqs]. Finally, >> industrial requirements cite differing lifetime requirements as an >> important factor to account for [I-D.ietf-roll-indus-routing-reqs]. >> Node cost refers to the ability for a protocol to incorporate router >> properties into routing metrics and use node attributes for >> constraint-based routing. >> A "pass" indicates that the protocol contains a mechanism allowing >> these considerations to be considered when choosing routes. > > Sorry, which considerations more precisely? > > Do you mean we don't have a routing metric saying "energy level"/ > "memory size"? Is it this? > > If yes I think I could make a separate thread with various reflections > on the topic. > >> Neighbor discovery is a critical component of any routing protocol. > > Terminology: as already described in the draft, "Neighbor Discovery" > being a specific Internet-area protocol RFC 4861, independent of any > routing protocol (could be called the ARP of IPv6). Thus reading the > above phrase may make one think ND is a critical component of any > routing protocol - it's not. The lexical situation is worse knowing > that OSPF calls a Neighbor _almost_ the same thing as an ND neighbor. > > As such, the above phrase is very difficult to parse. > >> 8.1. IPv6 Neighbor Discovery >> IPv6 neighbor discovery provides mechanisms for nodes to discover >> single-hop neighbors as well as routers that can forward packets past >> the local neighborhood. There is an implicit assumption that the >> delegation of whether a node is a router or not is static (e.g., >> based on a wired topology). The fact that all routers must respond >> to a Router Solicitation requires that the number of routers with a >> 1-hop neighborhood is small, or there will be a reply implosion. > > RAs sent in response to a RS are randomly spaced in time, tunable > timer, thus I would qualify that neither as explosion nor as > implosion, because they're not simultaneous. ND specifiers often > complained about 'storms' they experienced with faulty cards and ARP > and thus felt ND could do better, I think it went on ok. > >> Furthermore, IPv6 neighbor discovery's support of address >> autoconfiguration assumes address provisioning, in that addresses >> reflect the underlying communication topology. > > I'm afraid this touches on a fundamental Internet design: yes > addresses > reflect the underlying communication topology. So what? I hope the > intention is not to design some protocol which assumes the addresses > do > not reflect the underlying communication topology. > > I'm afraid we may have a big big misunderstanding here. > >> IPv6 neighbor discovery does not consider asymmetric links. > > And? Does ROLL consider asymmetric links? Which ones? In what are > they asymmetric? Bandwidth? Reachability? MTU? > > For example, whereas WiFi radio channel may look asymmetric bandwidth > ul/dl (from the MAC layer), when the ND looks at that MAC it sees it > symmetric. > > Maybe ND is enough for these apparently asymmetric links? > >> Nevertheless, it may be possible to extend and adapt IPv6's >> mechanisms to wireless in order to avoid response storms and >> implosions. > > I think this has already been done with many protocols in IPv6 space. > ND is a typical example, but also Mobile IPv6. I think OSPF for IPv6 > also has means to avoid storms and implosions. > > Or I don't understand at all the requirement. > > Alex > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-98--194107359 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi,

On Jan = 29, 2009, at 8:12 PM, Alexandru Petrescu wrote:

In = this mail I argue about:
-Table Scalability can't be a factor to = disqualify any protocol (specs
are eminently silent about how tables = are represented and thus
how they scale).
-Loss Response can't be = a factor to discard NEMO (MR only sends to HA,
not to n destinations = upon link up/down events).
-Control Cost tests can very well accept = MIP-based NEMO protocol in that
MIP and ND have rate = limitation.

-Asking about Link and Node cost metrics: maybe = that's it actually.

-Suggest corrections to the use of "Neighbor = disovery" term, makes think
of "Neighbor Discovery"
-suggest that = ND doesn't risk storms of replied RAs to a RS, because
they're = randomly spaced in time.
-suggest that addresses being a direct = expression of the underlying
network topology is a deep Internet = assumption that can't be changed.
-ask about necessity of asymmetric = support.

For details, when time permits, see = below.

4.2.  Table = Scalability
Scalability = support for large networks of sensors is highlighted as = a
key requirement by all = three application requirements = documents.
[...]
More = precisely, routing table size scaling with O(N) or O(L) fails. = A
table that scales O(D) = (assuming no N or L) passes.

This is a problem of = representing data structures, and not of the
protocol per se.  I = hope some protocol isn't discarded by some
dangerously false = assumptions on the way it represents its so-called
tables in the = memory.

For example there exist various implementations of = Binding Cache (of
MIP) and Neighbor Cache (of ND) which are more or = less efficient.  Some
are quick at finding, others at inserting, = others are smaller, and so on.

Also related to = this:
For example, a node with 4kB of RAM, = a typical amount for top-end microcontrollers, cannot store full = neighbor state when it has 1000 other nodes = nearby.

LEt's see: which addresses IPv4 or IPv6? =  How are they represented?  Are
they covered by a long or = short prefix length (subnet address)?  Which
link = layer?

And is it assumed that a micro-controller needs to talk to = 1000
neighbors at the same time?  Because the Neighbor Cache = only holds the
neighbors to which a node has recently talked to, = there are tweakable
expiry timers.  And I doubt there exists a = link layer supporting this
assumption of one-to-1000 simultaneous = neighbors communication.

4.3. =  Loss Response
In low = power and lossy networks, links routinely come and go due to being close = to the signal-to-noise threshold at the physical layer. It is important = that link churn not trigger unnecessary responses by the routing = protocol.
[...]
A protocol = which requires many link changes to propagate across the entire network = fails.  Protocols which constrain the scope of information = propagation to only when they affect routes to active destinations, or = to local neighborhoods, pass.  Protocols which = allow
proactively path = maintenance pass if the choice of which paths to maintain is = user-specified.
More = precisely, loss responses that require O(N) transmissions fail, while = responses that can rely on O(1) local broadcasts or O(D) route updates = pass.

I think Mobile IP-based NEMO protocol should = pass this test.  Whenever
the Mobile Router's egress interface = comes down or up only the HA (Home
Agent) is let know about it, it's = not O(N), it's simply 1.  Besides, it
has a retransmission = control specified, such as to not make too much = noise.

4.4.  Control = Cost
[...]
a common case = [I-D.ietf-roll-indus-routing-reqs].  In terms of routing structure, = any proposed LLN routing protocol ought to = support
the autonomous = organization and configuration of the network at the lowest possible = energy cost = [I-D.ietf-roll-urban-routing-reqs].
All routing protocols must transmit additional data to = detect neighbors, build routes, transmit routing tables, or otherwise = conduct routing.  As low-power wireless networks can have very low = data rates, protocols which require a minimum control packet rate = can
have an unbounded control = overhead per data packet.  This is particularly true for = event-driven networks, which only report data when certain conditions = are met.  Regions of a network which never meet the condition can = be forced to send significant control traffic even when there is no data = to send.  For these use cases, hard-coded timing constants are = unacceptable, because they imply a prior knowledge of the expected data = rate.
Of course, protocols = require the ability to send at least a very small amount of control = traffic, in order to discover a topology. = But
this bootstrapping = discovery and maintenance traffic should be small: communicating once an = hour is far more reasonable than communicating once a second.  So = while control traffic should be bounded by data traffic, it requires = some leeway to bootstrap and maintain a long-lived yet idle = network.
In the case of = control traffic, the communication rate (sum of transmissions and = receptions at a node) is a better measure than the transmission rate = (since energy is consumed for both transmissions and receptions). =  Controlling the transmission rate is insufficient, as it would = mean that the energy cost (sum of transmission and receptions) of = control traffic could grow with O(L).
A protocol fails the control cost criterion if its = per-node control traffic (transmissions plus receptions) rate is not = bounded by the data rate plus a small = constant.

Neighbor Discovery and Mobile IPv6 both = have built-in rate limitation
mechanisms.

For example, a protocol using a beacon rate only passes if = it can be
turned arbitrarily = low, in order to match the data rate.

Both MIP and = ND do that.  It's turned arbitrarily low by an
administrator. =  I hope that's ok.

4.5.  Link = and Node Cost
These two = criteria specify how a protocol chooses routes for data packets to take = through the network.  Classical routing algorithms typically = acknowledge the differing costs of paths and may use a shortest path = algorithm to find paths.  This is a requirement for = low
power networks, as links = must be evaluated as part of an objective function across various metric = types, such as minimizing latency and
maximizing reliability = [I-D.ietf-roll-indus-routing-reqs].
However, in low power networks it is also desirable to = account for the cost of forwarding through particular routers. =  Applications require node or parameter constrained routing, which = takes into account node properties and attributes such as power, memory, = and battery life that dictate a router's willingness or ability to = route
other packets. =  Home routing requirements note that devices = will
vary in their duty cycle, = and that routing protocols should prefer
nodes with permanent power = [I-D.ietf-roll-home-routing-reqs].  The
urban requirements note that routing protocols may wish to = take
advantage of differing = data processing and management capabilities
among network devices [I-D.ietf-roll-urban-routing-reqs]. =  Finally, industrial requirements cite differing lifetime = requirements as an important factor to account for = [I-D.ietf-roll-indus-routing-reqs]. Node cost refers to the ability for = a protocol to incorporate router
properties into routing metrics and use node attributes = for constraint-based routing.
A = "pass" indicates that the protocol contains a mechanism allowing these = considerations to be considered when choosing = routes.

Sorry, which considerations more = precisely?

Do you mean we don't have a routing metric saying = "energy level"/
"memory size"?  Is it this?

If yes I = think I could make a separate thread with various reflections
on the = topic.

Neighbor discovery is a critical = component of any routing protocol.

Terminology: as = already described in the draft, "Neighbor Discovery"
being a specific = Internet-area protocol RFC 4861, independent of any
routing protocol = (could be called the ARP of IPv6).  Thus reading the
above = phrase may make one think ND is a critical component of any
routing = protocol - it's not.  The lexical situation is worse = knowing
that OSPF calls a Neighbor _almost_ the same thing as an ND = neighbor.

As such, the above phrase is very difficult to = parse.

8.1.  IPv6 Neighbor = Discovery
IPv6 neighbor = discovery provides mechanisms for nodes to discover single-hop neighbors = as well as routers that can forward packets = past
the local neighborhood. =  There is an implicit assumption that the delegation of whether a = node is a router or not is static (e.g., based on a wired topology). =  The fact that all routers must respond to a Router Solicitation = requires that the number of routers with a 1-hop neighborhood is small, = or there will be a reply implosion.

RAs sent in = response to a RS are randomly spaced in time, tunable timer, thus I = would qualify that neither as explosion nor as implosion, because = they're not simultaneous.  ND specifiers often complained about = 'storms' they experienced with faulty cards and ARP and thus felt ND = could do better, I think it went on ok.

Furthermore, IPv6 neighbor discovery's support of address = autoconfiguration assumes address provisioning, in that addresses = reflect the underlying communication topology.

I'm = afraid this touches on a fundamental Internet design: yes = addresses
reflect the underlying communication topology.  So = what?  I hope the
intention is not to design some protocol which = assumes the addresses do
not reflect the underlying communication = topology.

I'm afraid we may have a big big misunderstanding = here.

IPv6 neighbor discovery does not = consider asymmetric links.

And?  Does ROLL = consider asymmetric links?  Which ones?  In what are
they = asymmetric?  Bandwidth?  Reachability?  MTU?

For = example, whereas WiFi radio channel may look asymmetric = bandwidth
ul/dl (from the MAC layer), when the ND looks at that MAC = it sees it
symmetric.

Maybe ND is enough for these apparently = asymmetric links?

Nevertheless, it may = be possible to extend and adapt IPv6's mechanisms to wireless in order = to avoid response storms and implosions.

I think = this has already been done with many protocols in IPv6 space.
ND is a = typical example, but also Mobile IPv6.  I think OSPF for = IPv6
also has means to avoid storms and implosions.

Or I don't = understand at all the = requirement.

Alex

__________________________________________= _____
Roll mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-98--194107359-- --===============0012976274== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0012976274==-- From roll-bounces@ietf.org Tue Feb 3 04:21:17 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2169228C1A4; Tue, 3 Feb 2009 04:21:17 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD05128C1A4 for ; Tue, 3 Feb 2009 04:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.5 X-Spam-Level: X-Spam-Status: No, score=-10.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLeAA74DxW4d for ; Tue, 3 Feb 2009 04:21:14 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 6510628C19E for ; Tue, 3 Feb 2009 04:21:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,372,1231113600"; d="scan'208";a="32690214" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2009 12:20:54 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n13CKsSs008801; Tue, 3 Feb 2009 13:20:54 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n13CKsqf028280; Tue, 3 Feb 2009 12:20:54 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 13:20:54 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 13:20:53 +0100 Message-Id: <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <49878003.8050307@gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Feb 2009 13:20:52 +0100 References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Feb 2009 12:20:53.0695 (UTC) FILETIME=[DBC08CF0:01C985F9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11387; t=1233663654; x=1234527654; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Review=20and=20comments=20Re=3 A=09I-D=09ACTION=3Adraft-ietf-roll-protocols-survey-05.txt |Sender:=20; bh=SOLcowcuki68c8eEfFiL6hA2ZsmoM1moVcRkOuq2Rys=; b=cTBjJSgYRWkq6ZrcxUhJiiTTPW5me5buNId/CC+pOlOFO8fIx+hey/GX1Q OosWz+OzySkuIS5GLwVkvWpBUIsRBPe45MRyTTJZuMJZgfvPNz0iIGtLK91I wmC2vP8NYg; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Arsalan Tavakoli , "David E. Culler" , stevedh@cs.berkeley.edu, roll@ietf.org, Ross Callon Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Alex, On Feb 3, 2009, at 12:21 AM, Alexandru Petrescu wrote: > Mischa Dohler a =E9crit : > [...] >> As for your proposition, I have another one: Why don't we stop here >> and get on with the actual protocol design stage, > > Sorry, which protocol do we mean to go on to protocol design stage? > > Could one imagine starting from scratch designing a new protocol? > We have detailed routing requirements documents. Should we re-charter, = the process gets quite simple. Look at different candidates and how close they are to the requirements. Then select one or two (in = which case we need clear applicability statement). And yes if we can use an adapted existing protocol, then great. Note that this is no = different than what is done with many other WGs. Let me quickly share some experience here. In the PCE WG that I'm co-chairing for several = years we faced a very similar situations. Several application specific requirements and about 7 protocol proposals on the table = including existing protocols (BGP, RSVP, SIP, ...) to be considered and new ones. It took *one* WG meeting to draw a consensus: yes that = was difficult but we managed to get a consensus. Bottom line? About 1 year to stabilize the protocol, now 10 implementations :-) Why = should it be different here ? Cheers. Thanks. JP. > Alex > > > knowing that some >> criteria may not be ideal or not applicable or of little use. Having >> a set of protocols at hand gives us a much clearer idea which >> parameters are of real key importance. I guess the discussion on the >> criteria could potentially last some more months - a time we cannot >> afford. The WSN market is different from the MANET market - it is >> very much alive and it is moving quickly. I know of at least two WSN >> companies who make good money with their networks but which have not >> gone for any MANET routing protocol - there must have been a >> reasoning behind this design choice. ROLL hopes to make companies >> choose its routing protocol(s) in the near future. >> Thanks for your support, Mischa. >> Thomas Heide Clausen wrote: >>> All, >>> I promised a review, and I apologize that I wasn't able to do so = >>> before the weekend as originally projected. >>> Other than some typos that Chris and others have pointed out, I'll >>> try to offer my understanding of the problem space and suggest some >>> ways of addressing my main concerns.... >>> My first main concern remain that it is not clear, still, how ROLL >>> positions itself with respect to MANET, 6LOW et. al, all of which >>> appear to be within the same space and within the IETF. This I-D >>> sees ROLL as presented with entirely new problems (the use of >>> "novel" in the abstract, the statement that "existing protocols >>> were not designed with these requirements in mind" seem to confirm >>> this). >>> Looking at the requirements listed, including "low power, low = >>> bandwidth, low footprint", these appear similar to those which are >>> also brought forward in e.g. MANET and 6LOW. Reading (quickly, I = >>> confess) the various requirements documents of the draft-ietf-roll >>> series present scenarios which are similar to those where MANETs >>> are deployed, and are thought deployed, as well. >>> I also note that many additional (and unstated) characteristics = >>> between ROLL and e.g. MANET are the same: mobile, wireless, >>> fragility, auto-configuration, IP routing, interface/link issues... >>> Arguing that, as does this I-D, despite the above impression "ROLL >>> is novel and different" invites asking "how, exactly?" I think that >>> this question is valid, and merits being answered, before the >>> evaluations in this I-D can be judged fairly. >>> Note that I come from a MANET background, and so I *could* >>> interpret from the ROLL discussion that where MANETs may aim for >>> "low power, low bandwidth, ....", ROLL may be able to quantify >>> these as "below this firm threshold" -- i.e. as a sort of "extreme" >>> or "constrained" MANET. >>> This is a personal observation, I note, which would allow me to = >>> comprehend how ROLL and MANET are positioned relative to one >>> another -- but one which neither this I-D nor the requirements >>> document spell out or quantify -- or, for that matter, debunk. >>> I think it's critical to understand this, in order to understand >>> the need for a new protocol development. I think it is important to >>> document this understanding in something with more persistency. >>> If what I suggest above makes sense as a way of positioning ROLL >>> and MANET relative to one another, I'd suggest including something >>> to this effect in the survey I-D, as this I-D is the one making a >>> *direct* reference to the applicability of MANET protocols to ROLL. >>> If what I suggest doesn't make sense at all, then I'd be happy to >>> have it debunked and, hopefully, through that debunking a = >>> positioning/description that does ring true with us all can be >>> produced? >>> My second main concern is, that I still think that the choice of = >>> criteria is unfortunate (not the word, Phill has me convinced on >>> that front, but the actual criteria). Control cost is, by all >>> means, a rather meaningless criteria when taken in isolation. I've >>> sketched a "zero-control-cost" routing protocol (flood all data - >>> say use SMF, also a MANET protocol, and also a rather "mature" I-D >>> and wg item) which would score well on the control cost criteria, >>> but would likely be an extremely bad choice for delivering unicast >>> data. >>> The metric which matters, and which should matter to ROLL in = >>> particular, is "the total cost of getting user data through the = >>> network, including control cost necessary to set up paths" -- as we >>> know, every packet sent and received costs bandwidth, energy and = >>> cycles -- user data no different from contro. >>> According to the criterions as set up by this I-D, a protocol = >>> producing "longer than shortest paths" at the benefit of slightly = >>> lower control cost would score better than a protocol producing = >>> "shortest paths" with slightly higher control cost. This is not = >>> hypothetical, btw., there are plenty of studies observing and = >>> reflecting upon this regarding the different MANET protocols, in = >>> academic literature -- and observed in real networks as well. >>> I note that this trade-off (slightly longer paths for lower control >>> cost) may be perfectly fair, assuming that very low amounts of >>> user data traffic transit through the network. However, I do not >>> see this assumption mentioned as a justification for focusing on >>> the control cost metric and discarding the "path length" or the >>> "total cost of getting user data through the network". >>> I believe that either these assumptions should be made explicit = >>> ("there's so little user data traffic in a ROLL network that we do >>> not care about shortest paths") or -- if these assumptions do not >>> hold, that the evaluation criteria are incomplete. >>> I note that it's true that we can always add another criteria ad = >>> infinitum, and that's CLEARLY not what we want to do. However when >>> I say "incomplete" in the above, I simply suggest that based on >>> what is presented one cannot draw conclusions based on the >>> evaluation criteria....or, worse, that one draws the wrong >>> conclusions based on the information presented. >>> So, in a nutshell, I suggest that we address (i) the positioning >>> issue and (ii) the criteria issue thus: >>> o Describe as I proposed above if ROLL and MANETs position = >>> themselves as I have deducted. If my deduction is incorrect, then >>> let's quickly iterate on the list as to understand how to do >>> produce an alternative description. If we can't do this, then the >>> conclusion can be that "we do not know how ROLL and MANET position = >>> themselves wrt each other", and we could then state that clearly? = >>> It *should* not be more than a couple of paragraphs worth of text >>> to add, I gather? >>> o To the criteria, either of: >>> - Add the assumption that "user data traffic is so low that path >>> lengths do not matter nor does the cost of carrying user data >>> traffice" >>> - Add a criteria & evaluation of "path length" >>> - Add a criteria & evaluation of "total cost for getting user >>> data through the network" >>> This would make a large chunk of my concerns and issues vanish, and >>> allow correctly interpreting and evaluating the rest of the >>> document. >>> How does that sound as an approach forward? >>> Cheers, >>> Thomas >>> On Jan 27, 2009, at 1:00 AM, Internet-Drafts@ietf.org wrote: >>>> A New Internet-Draft is available from the on-line >>>> Internet-Drafts directories. This draft is a work item of the >>>> Routing Over Low power and Lossy networks Working Group of the >>>> IETF. >>>> Title : Overview of Existing Routing Protocols for Low = >>>> Power and Lossy Networks Author(s) : A. Tavakoli, S. >>>> Dawson-Haggerty, P. Levis Filename : >>>> draft-ietf-roll-protocols-survey-05.txt Pages : 26 Date >>>> : 2009-1-26 Networks of low power wireless devices introduce >>>> novel IP routing issues. Low-power wireless devices, such as >>>> sensors, actuators and smart objects, have difficult constraints: >>>> very limited memory, little processing power, and long sleep >>>> periods. As most of these devices are battery-powered, energy >>>> efficiency is critically important. Wireless link qualities can >>>> vary significantly over time, requiring protocols to make agile >>>> decisions yet minimize topology change energy costs. Routing >>>> over such low power and lossy networks has novel requirements >>>> that existing protocols may not address. This document provides >>>> a brief survey of the strengths and weaknesses of existing >>>> protocols with respect to this class of networks. From this = >>>> survey it examines whether existing and mature IETF protocols can >>>> be used without modification in these networks, or whether >>>> further work is necessary. is necessary. >>>> A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/= draft-ietf-roll-protocols-survey-05.txt >>>> Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf= .org/internet-drafts/ >>>> Below is the data which will enable a MIME compliant mail reader = >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. Content-Type: text/plain Content-ID: >>>> <2009-1-26155804.I-D@ietf.org> >>>> _______________________________________________ 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 >> _______________________________________________ Roll mailing list Roll@i= etf.org = >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > 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 From roll-bounces@ietf.org Tue Feb 3 04:21:23 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C7AD3A69BA; Tue, 3 Feb 2009 04:21:23 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F59D28C0FF for ; Tue, 3 Feb 2009 04:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.501 X-Spam-Level: X-Spam-Status: No, score=-10.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEtrBnFxYrEo for ; Tue, 3 Feb 2009 04:21:19 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E21AF28C198 for ; Tue, 3 Feb 2009 04:21:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,372,1231113600"; d="scan'208";a="32690234" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2009 12:20:59 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n13CKxLN008843; Tue, 3 Feb 2009 13:20:59 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n13CKx83028327; Tue, 3 Feb 2009 12:20:59 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 13:20:59 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 13:20:58 +0100 Message-Id: <7C6DC187-681B-48DF-AFF1-FE329EA93CA8@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4987899C.3090708@gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Feb 2009 13:20:58 +0100 References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <4987899C.3090708@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Feb 2009 12:20:59.0164 (UTC) FILETIME=[DF030DC0:01C985F9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11625; t=1233663659; x=1234527659; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=206lowpan=20WG=20items=20and=20R OLL=20WG=20activities=20(was=3A=20Review=20and=20comments=20 Re=3A=09I-D=09ACTION=3Adraft-ietf-roll-protocols-survey-05.t xt) |Sender:=20; bh=Zp1lkpQqoDJL+LEhZaT63e25TYVo6M3hfeuL1rF9ppk=; b=PhwbqDr1Bb+f7wyb1Dj6mgsMXfp1yAuU3+Y9KV3Db5ExNxwMSGCB8DDjHU h2M4ZolUPdxZwojxxFK3YCIpq85z6lJnyBWmEZvSK+TuUUWlYCglQSntcgak CNxv3dNOxC; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Arsalan Tavakoli , "David E. Culler" , stevedh@cs.berkeley.edu, roll@ietf.org, Ross Callon Subject: Re: [Roll] 6lowpan WG items and ROLL WG activities (was: Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Feb 3, 2009, at 1:02 AM, Alexandru Petrescu wrote: > Mischa Dohler a =E9crit : > [...] >> 6LoWPAN: - mainly specifies IPv6 header compression but not >> (optimized) routing per se; > > Not only Header Compression, 6lowpan WG seems to also be looking at > Neighbor Discovery for 802.15.4, which is quite relevant here I = > believe, > because ZigBee was mentioned recently here. HOLD-ON ... We are NOT working on ZIGBEE here. Let's not go there. = This is the IETF, we work on IP. > > >> - [6lowpan] is stuck to IEEE 802.15.4 radios. > > I think it is good to list the radios ROLL looks at: > > IEEE 802.15.4 > SP100 http://tinyurl.com/4d3j64 > ZigBee > HART http://tinyurl.com/4d3j64 > There is quite a bit of confusion. Zigbee is non-IP and build above = 15.4. We are designing IP-solution and indeed 15.4 is one of the PHY/MAC LLN = may run onto. Thanks. JP. > Alex > > > >> MANET: - design paradigm is to offer certain QoS and see how long we >> can run the network, whereas in ROLL we are likely to go the other >> way, ie optimize the longevity/energy efficiency and see what we can >> offer (maybe a hybrid of both); - properties of data contents is not >> (or in limited form) used to facilitate protocol designs, whereas in >> ROLL this is likely going to be central to the routing protocol >> design (example is the convergecast traffic pattern where not every >> node wishes to communicate with any other node, etc). >> As for your proposition, I have another one: Why don't we stop here >> and get on with the actual protocol design stage, knowing that some >> criteria may not be ideal or not applicable or of little use. Having >> a set of protocols at hand gives us a much clearer idea which >> parameters are of real key importance. I guess the discussion on the >> criteria could potentially last some more months - a time we cannot >> afford. The WSN market is different from the MANET market - it is >> very much alive and it is moving quickly. I know of at least two WSN >> companies who make good money with their networks but which have not >> gone for any MANET routing protocol - there must have been a >> reasoning behind this design choice. ROLL hopes to make companies >> choose its routing protocol(s) in the near future. >> Thanks for your support, Mischa. >> Thomas Heide Clausen wrote: >>> All, >>> I promised a review, and I apologize that I wasn't able to do so = >>> before the weekend as originally projected. >>> Other than some typos that Chris and others have pointed out, I'll >>> try to offer my understanding of the problem space and suggest some >>> ways of addressing my main concerns.... >>> My first main concern remain that it is not clear, still, how ROLL >>> positions itself with respect to MANET, 6LOW et. al, all of which >>> appear to be within the same space and within the IETF. This I-D >>> sees ROLL as presented with entirely new problems (the use of >>> "novel" in the abstract, the statement that "existing protocols >>> were not designed with these requirements in mind" seem to confirm >>> this). >>> Looking at the requirements listed, including "low power, low = >>> bandwidth, low footprint", these appear similar to those which are >>> also brought forward in e.g. MANET and 6LOW. Reading (quickly, I = >>> confess) the various requirements documents of the draft-ietf-roll >>> series present scenarios which are similar to those where MANETs >>> are deployed, and are thought deployed, as well. >>> I also note that many additional (and unstated) characteristics = >>> between ROLL and e.g. MANET are the same: mobile, wireless, >>> fragility, auto-configuration, IP routing, interface/link issues... >>> Arguing that, as does this I-D, despite the above impression "ROLL >>> is novel and different" invites asking "how, exactly?" I think that >>> this question is valid, and merits being answered, before the >>> evaluations in this I-D can be judged fairly. >>> Note that I come from a MANET background, and so I *could* >>> interpret from the ROLL discussion that where MANETs may aim for >>> "low power, low bandwidth, ....", ROLL may be able to quantify >>> these as "below this firm threshold" -- i.e. as a sort of "extreme" >>> or "constrained" MANET. >>> This is a personal observation, I note, which would allow me to = >>> comprehend how ROLL and MANET are positioned relative to one >>> another -- but one which neither this I-D nor the requirements >>> document spell out or quantify -- or, for that matter, debunk. >>> I think it's critical to understand this, in order to understand >>> the need for a new protocol development. I think it is important to >>> document this understanding in something with more persistency. >>> If what I suggest above makes sense as a way of positioning ROLL >>> and MANET relative to one another, I'd suggest including something >>> to this effect in the survey I-D, as this I-D is the one making a >>> *direct* reference to the applicability of MANET protocols to ROLL. >>> If what I suggest doesn't make sense at all, then I'd be happy to >>> have it debunked and, hopefully, through that debunking a = >>> positioning/description that does ring true with us all can be >>> produced? >>> My second main concern is, that I still think that the choice of = >>> criteria is unfortunate (not the word, Phill has me convinced on >>> that front, but the actual criteria). Control cost is, by all >>> means, a rather meaningless criteria when taken in isolation. I've >>> sketched a "zero-control-cost" routing protocol (flood all data - >>> say use SMF, also a MANET protocol, and also a rather "mature" I-D >>> and wg item) which would score well on the control cost criteria, >>> but would likely be an extremely bad choice for delivering unicast >>> data. >>> The metric which matters, and which should matter to ROLL in = >>> particular, is "the total cost of getting user data through the = >>> network, including control cost necessary to set up paths" -- as we >>> know, every packet sent and received costs bandwidth, energy and = >>> cycles -- user data no different from contro. >>> According to the criterions as set up by this I-D, a protocol = >>> producing "longer than shortest paths" at the benefit of slightly = >>> lower control cost would score better than a protocol producing = >>> "shortest paths" with slightly higher control cost. This is not = >>> hypothetical, btw., there are plenty of studies observing and = >>> reflecting upon this regarding the different MANET protocols, in = >>> academic literature -- and observed in real networks as well. >>> I note that this trade-off (slightly longer paths for lower control >>> cost) may be perfectly fair, assuming that very low amounts of >>> user data traffic transit through the network. However, I do not >>> see this assumption mentioned as a justification for focusing on >>> the control cost metric and discarding the "path length" or the >>> "total cost of getting user data through the network". >>> I believe that either these assumptions should be made explicit = >>> ("there's so little user data traffic in a ROLL network that we do >>> not care about shortest paths") or -- if these assumptions do not >>> hold, that the evaluation criteria are incomplete. >>> I note that it's true that we can always add another criteria ad = >>> infinitum, and that's CLEARLY not what we want to do. However when >>> I say "incomplete" in the above, I simply suggest that based on >>> what is presented one cannot draw conclusions based on the >>> evaluation criteria....or, worse, that one draws the wrong >>> conclusions based on the information presented. >>> So, in a nutshell, I suggest that we address (i) the positioning >>> issue and (ii) the criteria issue thus: >>> o Describe as I proposed above if ROLL and MANETs position = >>> themselves as I have deducted. If my deduction is incorrect, then >>> let's quickly iterate on the list as to understand how to do >>> produce an alternative description. If we can't do this, then the >>> conclusion can be that "we do not know how ROLL and MANET position = >>> themselves wrt each other", and we could then state that clearly? = >>> It *should* not be more than a couple of paragraphs worth of text >>> to add, I gather? >>> o To the criteria, either of: >>> - Add the assumption that "user data traffic is so low that path >>> lengths do not matter nor does the cost of carrying user data >>> traffice" >>> - Add a criteria & evaluation of "path length" >>> - Add a criteria & evaluation of "total cost for getting user >>> data through the network" >>> This would make a large chunk of my concerns and issues vanish, and >>> allow correctly interpreting and evaluating the rest of the >>> document. >>> How does that sound as an approach forward? >>> Cheers, >>> Thomas >>> On Jan 27, 2009, at 1:00 AM, Internet-Drafts@ietf.org wrote: >>>> A New Internet-Draft is available from the on-line >>>> Internet-Drafts directories. This draft is a work item of the >>>> Routing Over Low power and Lossy networks Working Group of the >>>> IETF. >>>> Title : Overview of Existing Routing Protocols for Low = >>>> Power and Lossy Networks Author(s) : A. Tavakoli, S. >>>> Dawson-Haggerty, P. Levis Filename : >>>> draft-ietf-roll-protocols-survey-05.txt Pages : 26 Date >>>> : 2009-1-26 Networks of low power wireless devices introduce >>>> novel IP routing issues. Low-power wireless devices, such as >>>> sensors, actuators and smart objects, have difficult constraints: >>>> very limited memory, little processing power, and long sleep >>>> periods. As most of these devices are battery-powered, energy >>>> efficiency is critically important. Wireless link qualities can >>>> vary significantly over time, requiring protocols to make agile >>>> decisions yet minimize topology change energy costs. Routing >>>> over such low power and lossy networks has novel requirements >>>> that existing protocols may not address. This document provides >>>> a brief survey of the strengths and weaknesses of existing >>>> protocols with respect to this class of networks. From this = >>>> survey it examines whether existing and mature IETF protocols can >>>> be used without modification in these networks, or whether >>>> further work is necessary. is necessary. >>>> A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/= draft-ietf-roll-protocols-survey-05.txt >>>> Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf= .org/internet-drafts/ >>>> Below is the data which will enable a MIME compliant mail reader = >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. Content-Type: text/plain Content-ID: >>>> <2009-1-26155804.I-D@ietf.org> >>>> _______________________________________________ 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 >> _______________________________________________ Roll mailing list Roll@i= etf.org = >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > 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 From roll-bounces@ietf.org Tue Feb 3 04:21:56 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 824A23A6A8B; Tue, 3 Feb 2009 04:21:56 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2612F28C1A5 for ; Tue, 3 Feb 2009 04:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.202 X-Spam-Level: X-Spam-Status: No, score=-10.202 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cywuQEyNMSiP for ; Tue, 3 Feb 2009 04:21:55 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1F2313A68FF for ; Tue, 3 Feb 2009 04:21:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,372,1231113600"; d="scan'208";a="32690250" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2009 12:21:05 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n13CL5fn028352; Tue, 3 Feb 2009 13:21:05 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n13CL5Zo028376; Tue, 3 Feb 2009 12:21:05 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 13:21:05 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 13:21:04 +0100 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4987F12D.3000609@gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Feb 2009 13:21:04 +0100 References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <69306dde0902021535i353b02fdie689bf78d6fce7f5@mail.gmail.com> <49878E46.7050105@gmail.com> <69306dde0902021653u4e9e0b89kaba0515c65824df2@mail.gmail.com> <4987F12D.3000609@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Feb 2009 12:21:04.0960 (UTC) FILETIME=[E2777400:01C985F9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4092; t=1233663665; x=1234527665; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Why=20is=20next=20stage=20impe ded=20by=20protocol-survey=20draft? |Sender:=20; bh=2rfLbL/VhqBR9kd6/K45cOw8+WREZpNBJv6sAeQuf1k=; b=kvn6bIY+FA9ADE9UwRm+k41vwvJcDLHmXMiyYaVsWF0oW0bKNZE9Ti8FEq u/GnIKbLDpw1gHZbbxkE3jwDXgtRqDHoDVkOqz00jmEbz/sHIWyJ6QTGCfyK /L5L485qkF; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Ross Callon , ROLL WG , Arsalan Tavakoli , "David E. Culler" Subject: Re: [Roll] Why is next stage impeded by protocol-survey draft? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Feb 3, 2009, at 8:24 AM, Alexandru Petrescu wrote: > > Arsalan Tavakoli a =E9crit : >> On Mon, Feb 2, 2009 at 4:22 PM, Alexandru Petrescu > > wrote: >> Arsalan Tavakoli a =E9crit : >>>> As was discussed earlier, at the protocol design stage, the group >>>> will be soliciting specifications for a protocol that meets the = >>>> ROLL requirements, whether it is an extension/modification of an >>>> existing protocol, or a specification written from scratch. = >>>> Advancing to that stage simply implies that no such specification >>>> (in its current form) presently exists. >>> The protocol-survey draft wouldn't impede going to the next stage, = >>> were it silently updated every 6 months, away from LastCall. >> I don't particularly understand the need for such a move. By = >> definition, holding up the protocol-survey draft IS holding up = >> going to the next stage. > > I don't understand this definition at all. I think we could very well > go to the next stage without necessarily LC'ing the protocol-survey > draft. In this way we could avoid deep controversion about which > existing protocol is better. > > If protocol-survey sets some conclusions - I think they will constrain > the next stage more than the requirements drafts. Don't you think so? Ah you missed something here, glad you raise the point. The *only* aim = of the protocol survey is to see whether an existing protocol (with no change) can be used, that's it. Once re- = chartered we will go back to the requirements documents. > > > I think each item in the Charter's timeline is completely = > independent, no? (they're not sequentially dependent). > That depends ... in this case, we want the question answered. Thanks. JP. > Alex > > > The purpose of the protocol survey draft is to >> determine whether an existing specification, again in current form, = >> satisfies the set of criteria. Our current charter is limited to = >> answering this question. In order to move to the design stage, at = >> which point we start discussing actual protocol and design, we need = >> to recharter, and we can not do that until this draft is finalized, = >> hence why this draft impedes us from moving on. By definition, the = >> protocol specified during the next stage will satisfy the ROLL = >> requirements, and changes to existing protocol specifications (for = >> those evaluated in the draft) to allow them to pass ROLL criteria, = >> can be presented during the next stage, which would make an update of >> the document a moot point. >> We could probably then discuss requirements. >> Let me humbly propose a 're-usability' requirement, common: "an = >> important requirement is to identify and reuse as much as possible an >> existing protocol that pertains to this application domain; this has >> the immediate advantage of software availability for first = >> prototypes". >> Again, as David has written frequently, these are all very = >> important issues that will need to be discussed when we move to the = >> protocol and design stage. However, this is completely outside the = >> scope of the protocol survey draft, and hence I believe should not = >> be discussed in the draft. The draft takes no position on such a = >> requirement. If we can close on this draft, then we can recharter, = >> and move on to the next stage, at which point all these issues that = >> everybody is so anxious to get to can be discussed, rather than = >> having to continually to postpone them as we block on this document. >> What do you think? >> Alex _______________________________________________ Roll mailing = >> list Roll@ietf.org https://www.ietf.org/mailman/l= istinfo/roll > > _______________________________________________ > 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 From roll-bounces@ietf.org Tue Feb 3 04:24:26 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D797E3A695D; Tue, 3 Feb 2009 04:24:26 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDD2F28C11D for ; Mon, 2 Feb 2009 15:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pW3bZ46sRDcd for ; Mon, 2 Feb 2009 15:36:05 -0800 (PST) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by core3.amsl.com (Postfix) with ESMTP id 0DF383A67B5 for ; Mon, 2 Feb 2009 15:36:03 -0800 (PST) Received: by ewy14 with SMTP id 14so2159465ewy.13 for ; Mon, 02 Feb 2009 15:35:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=qgKf6/mdEpEB0eRtfXWElM3JRP7/L6VBm/o1ZjpRFa0=; b=wvquF/U0/RsWiXg2pCBPQ4M5aMNIjsX4VhRX9g15jie0ceXh6bLrTnX3yjP4xlNkVf VSNULyavD8Fv6GnYuh7vrCis+eigDc4fGjk11IeUqbCJW5QE1P0oxNuk0VbjPLYWny0T MJYslEX/fXPR+Jb/TKZw0r6uffN0OsEdLwzZo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=fV+Kt9qaxq+Gz71tpqKkdNvptkCHz55qKsEZNRoI4TlbjeGhXIFlqzs/Gd4A8575aI 8G2D4zTSUmGqgyGUD8RvoMOW6/kfWLPAGFHGAp0jIpgVKMJ7zxUxDa2ZWC4dpb43oawi UXZI0fqU7vdj1LHWSuXRLGo9EUIGMieQIk6pI= MIME-Version: 1.0 Received: by 10.210.37.16 with SMTP id k16mr2463745ebk.97.1233617742958; Mon, 02 Feb 2009 15:35:42 -0800 (PST) In-Reply-To: <49878003.8050307@gmail.com> References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> Date: Mon, 2 Feb 2009 15:35:42 -0800 X-Google-Sender-Auth: 161ebd604c03c05d Message-ID: <69306dde0902021535i353b02fdie689bf78d6fce7f5@mail.gmail.com> From: Arsalan Tavakoli To: Alexandru Petrescu X-Mailman-Approved-At: Tue, 03 Feb 2009 04:24:25 -0800 Cc: "David E. Culler" , roll@ietf.org, Ross Callon Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1802670391==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1802670391== Content-Type: multipart/alternative; boundary=0015174c14225b8fff0461f8030c --0015174c14225b8fff0461f8030c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As was discussed earlier, at the protocol design stage, the group will be soliciting specifications for a protocol that meets the ROLL requirements, whether it is an extension/modification of an existing protocol, or a specification written from scratch. Advancing to that stage simply implies that no such specification (in its current form) presently exists. - Arsalan On Mon, Feb 2, 2009 at 3:21 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Mischa Dohler a =E9crit : > [...] > >> As for your proposition, I have another one: Why don't we stop here >> and get on with the actual protocol design stage, >> > > Sorry, which protocol do we mean to go on to protocol design stage? > > Could one imagine starting from scratch designing a new protocol? > > Alex > > > knowing that some > >> criteria may not be ideal or not applicable or of little use. Having >> a set of protocols at hand gives us a much clearer idea which >> parameters are of real key importance. I guess the discussion on the >> criteria could potentially last some more months - a time we cannot >> afford. The WSN market is different from the MANET market - it is >> very much alive and it is moving quickly. I know of at least two WSN >> companies who make good money with their networks but which have not >> gone for any MANET routing protocol - there must have been a >> reasoning behind this design choice. ROLL hopes to make companies >> choose its routing protocol(s) in the near future. >> >> Thanks for your support, Mischa. >> >> >> >> >> Thomas Heide Clausen wrote: >> >>> All, >>> >>> I promised a review, and I apologize that I wasn't able to do so before >>> the weekend as originally projected. >>> >>> Other than some typos that Chris and others have pointed out, I'll >>> try to offer my understanding of the problem space and suggest some >>> ways of addressing my main concerns.... >>> >>> My first main concern remain that it is not clear, still, how ROLL >>> positions itself with respect to MANET, 6LOW et. al, all of which >>> appear to be within the same space and within the IETF. This I-D >>> sees ROLL as presented with entirely new problems (the use of >>> "novel" in the abstract, the statement that "existing protocols >>> were not designed with these requirements in mind" seem to confirm >>> this). >>> >>> Looking at the requirements listed, including "low power, low bandwidt= h, >>> low footprint", these appear similar to those which are >>> also brought forward in e.g. MANET and 6LOW. Reading (quickly, I >>> confess) the various requirements documents of the draft-ietf-roll >>> series present scenarios which are similar to those where MANETs >>> are deployed, and are thought deployed, as well. >>> >>> I also note that many additional (and unstated) characteristics between >>> ROLL and e.g. MANET are the same: mobile, wireless, >>> fragility, auto-configuration, IP routing, interface/link issues... >>> >>> >>> Arguing that, as does this I-D, despite the above impression "ROLL >>> is novel and different" invites asking "how, exactly?" I think that >>> this question is valid, and merits being answered, before the >>> evaluations in this I-D can be judged fairly. >>> >>> Note that I come from a MANET background, and so I *could* >>> interpret from the ROLL discussion that where MANETs may aim for >>> "low power, low bandwidth, ....", ROLL may be able to quantify >>> these as "below this firm threshold" -- i.e. as a sort of "extreme" >>> or "constrained" MANET. >>> >>> This is a personal observation, I note, which would allow me to >>> comprehend how ROLL and MANET are positioned relative to one >>> another -- but one which neither this I-D nor the requirements >>> document spell out or quantify -- or, for that matter, debunk. >>> >>> I think it's critical to understand this, in order to understand >>> the need for a new protocol development. I think it is important to >>> document this understanding in something with more persistency. >>> >>> If what I suggest above makes sense as a way of positioning ROLL >>> and MANET relative to one another, I'd suggest including something >>> to this effect in the survey I-D, as this I-D is the one making a >>> *direct* reference to the applicability of MANET protocols to ROLL. >>> >>> >>> If what I suggest doesn't make sense at all, then I'd be happy to >>> have it debunked and, hopefully, through that debunking a >>> positioning/description that does ring true with us all can be >>> produced? >>> >>> My second main concern is, that I still think that the choice of criter= ia >>> is unfortunate (not the word, Phill has me convinced on >>> that front, but the actual criteria). Control cost is, by all >>> means, a rather meaningless criteria when taken in isolation. I've >>> sketched a "zero-control-cost" routing protocol (flood all data - >>> say use SMF, also a MANET protocol, and also a rather "mature" I-D >>> and wg item) which would score well on the control cost criteria, >>> but would likely be an extremely bad choice for delivering unicast >>> data. >>> >>> The metric which matters, and which should matter to ROLL in particular= , >>> is "the total cost of getting user data through the network, including >>> control cost necessary to set up paths" -- as we >>> know, every packet sent and received costs bandwidth, energy and cycle= s >>> -- user data no different from contro. >>> >>> According to the criterions as set up by this I-D, a protocol producing >>> "longer than shortest paths" at the benefit of slightly lower control c= ost >>> would score better than a protocol producing "shortest paths" with slig= htly >>> higher control cost. This is not hypothetical, btw., there are plenty o= f >>> studies observing and reflecting upon this regarding the different MANE= T >>> protocols, in academic literature -- and observed in real networks as w= ell. >>> >>> I note that this trade-off (slightly longer paths for lower control >>> cost) may be perfectly fair, assuming that very low amounts of >>> user data traffic transit through the network. However, I do not >>> see this assumption mentioned as a justification for focusing on >>> the control cost metric and discarding the "path length" or the >>> "total cost of getting user data through the network". >>> >>> I believe that either these assumptions should be made explicit ("there= 's >>> so little user data traffic in a ROLL network that we do >>> not care about shortest paths") or -- if these assumptions do not >>> hold, that the evaluation criteria are incomplete. >>> >>> I note that it's true that we can always add another criteria ad >>> infinitum, and that's CLEARLY not what we want to do. However when >>> I say "incomplete" in the above, I simply suggest that based on >>> what is presented one cannot draw conclusions based on the >>> evaluation criteria....or, worse, that one draws the wrong >>> conclusions based on the information presented. >>> >>> So, in a nutshell, I suggest that we address (i) the positioning >>> issue and (ii) the criteria issue thus: >>> >>> o Describe as I proposed above if ROLL and MANETs position themselve= s >>> as I have deducted. If my deduction is incorrect, then >>> let's quickly iterate on the list as to understand how to do >>> produce an alternative description. If we can't do this, then the >>> conclusion can be that "we do not know how ROLL and MANET position >>> themselves wrt each other", and we could then state that clearly? It >>> *should* not be more than a couple of paragraphs worth of text >>> to add, I gather? >>> >>> o To the criteria, either of: >>> >>> - Add the assumption that "user data traffic is so low that path >>> lengths do not matter nor does the cost of carrying user data >>> traffice" >>> >>> - Add a criteria & evaluation of "path length" >>> >>> - Add a criteria & evaluation of "total cost for getting user >>> data through the network" >>> >>> This would make a large chunk of my concerns and issues vanish, and >>> allow correctly interpreting and evaluating the rest of the >>> document. >>> >>> How does that sound as an approach forward? >>> >>> Cheers, >>> >>> Thomas >>> >>> On Jan 27, 2009, at 1:00 AM, Internet-Drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line >>>> Internet-Drafts directories. This draft is a work item of the >>>> Routing Over Low power and Lossy networks Working Group of the >>>> IETF. >>>> >>>> Title : Overview of Existing Routing Protocols for Low Power an= d >>>> Lossy Networks Author(s) : A. Tavakoli, S. >>>> Dawson-Haggerty, P. Levis Filename : >>>> draft-ietf-roll-protocols-survey-05.txt Pages : 26 Date >>>> : 2009-1-26 Networks of low power wireless devices introduce >>>> novel IP routing issues. Low-power wireless devices, such as >>>> sensors, actuators and smart objects, have difficult constraints: >>>> very limited memory, little processing power, and long sleep >>>> periods. As most of these devices are battery-powered, energy >>>> efficiency is critically important. Wireless link qualities can >>>> vary significantly over time, requiring protocols to make agile >>>> decisions yet minimize topology change energy costs. Routing >>>> over such low power and lossy networks has novel requirements >>>> that existing protocols may not address. This document provides >>>> a brief survey of the strengths and weaknesses of existing >>>> protocols with respect to this class of networks. From this survey it >>>> examines whether existing and mature IETF protocols can >>>> be used without modification in these networks, or whether >>>> further work is necessary. is necessary. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-survey-0= 5.txt >>>> >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. Content-Type: text/plain Content-ID: >>>> <2009-1-26155804.I-D@ietf.org> >>>> >>>> _______________________________________________ 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 >>> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> >> > --0015174c14225b8fff0461f8030c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As was discussed earlier, at the protocol design stage, the group will be s= oliciting specifications for a protocol that meets the ROLL requirements, w= hether it is an extension/modification of an existing protocol, or a specif= ication written from scratch.  Advancing to that stage simply implies = that no such specification (in its current form) presently exists.

- Arsalan

On Mon, Feb 2, 2= 009 at 3:21 PM, Alexandru Petrescu <alexandru.petrescu@gmail.com> w= rote:
Mischa Dohler a =E9crit :
[...]

As for your proposition, I have another one: Why don't we stop here
and get on with the actual protocol design stage,

Sorry, which protocol do we mean to go on to protocol design stage?

Could one imagine starting from scratch designing a new protocol?

Alex


 knowing that some
criteria may not be ideal or not applicable or of little use. Having
a set of protocols at hand gives us a much clearer idea which
parameters are of real key importance. I guess the discussion on the
criteria could potentially last some more months - a time we cannot
afford. The WSN market is different from the MANET market - it is
very much alive and it is moving quickly. I know of at least two WSN
companies who make good money with their networks but which have not
gone for any MANET routing protocol - there must have been a
reasoning behind this design choice. ROLL hopes to make companies
choose its routing protocol(s) in the near future.

Thanks for your support, Mischa.




Thomas Heide Clausen wrote:
All,

I promised a review, and I apologize that I wasn't able to do so before= the weekend as originally projected.

Other than some typos that Chris and others have pointed out, I'll
try to offer my understanding of the problem space and suggest some
ways of addressing my main concerns....

My first main concern remain that it is not clear, still, how ROLL
 positions itself with respect to MANET, 6LOW et. al, all of which
 appear to be within the same space and within the IETF. This I-D
sees ROLL as presented with entirely new problems (the use of
"novel" in the abstract, the statement that "existing protoc= ols
were not designed with these requirements in mind" seem to confirm
this).

Looking at the  requirements listed, including "low power, low ba= ndwidth, low footprint", these appear similar to those which are
 also brought forward in e.g. MANET and 6LOW. Reading (quickly, I conf= ess) the various requirements documents  of the draft-ietf-roll
 series present scenarios which are similar to those where MANETs
are deployed, and are thought deployed, as well.

I also note that many additional (and unstated) characteristics between ROL= L and e.g. MANET are the same: mobile, wireless,
fragility, auto-configuration, IP routing, interface/link issues...


Arguing that, as does this I-D, despite the above impression "ROLL
is novel and different" invites asking "how, exactly?" I thi= nk that
this question is valid, and merits being answered, before the
evaluations in this I-D can be judged fairly.

Note that I come from a MANET background, and so I *could*
interpret from the ROLL discussion that where MANETs may aim for
"low power, low bandwidth, ....", ROLL may be able to quantify these as "below this firm threshold" -- i.e. as a sort of "e= xtreme"
or "constrained" MANET.

This is a personal observation, I note, which would allow me to comprehend = how ROLL and MANET are positioned relative to one
another -- but one which neither this I-D nor the requirements
document spell out or quantify -- or, for that matter, debunk.

I think it's critical to understand this, in order to understand
the need for a new protocol development. I think it is important to
 document this understanding in something with more persistency.

If what I suggest above makes sense as a way of positioning ROLL
and MANET relative to one another, I'd suggest including something
to this effect in the survey I-D, as this I-D is the one making a
*direct* reference to the applicability of MANET protocols to ROLL.


If what I suggest doesn't make sense at all, then I'd be happy to have it debunked and, hopefully, through that debunking a positioning/descr= iption that does ring true with us all can be
produced?

My second main concern is, that I still think that the choice of criteria i= s unfortunate (not the word, Phill has me convinced on
that front, but the actual criteria). Control cost is, by all
means, a rather meaningless criteria when taken in isolation. I've
sketched a "zero-control-cost" routing protocol (flood all data -=
say use SMF, also a MANET protocol, and also a rather "mature" I-= D
and wg item) which would score well on the control cost criteria,
but would likely be an extremely bad choice for delivering unicast
data.

The metric which matters, and which should matter to ROLL in particular, is= "the total cost of getting user data through the network, including c= ontrol cost necessary to set up paths" -- as we
 know, every packet sent and received costs bandwidth, energy and cycl= es -- user data no different from contro.

According to the criterions as set up by this I-D, a protocol producing &qu= ot;longer than shortest paths" at the benefit of slightly lower contro= l cost would score better than a protocol producing "shortest paths&qu= ot; with slightly higher control cost. This is not hypothetical, btw., ther= e are plenty of studies observing and reflecting upon this regarding the di= fferent MANET protocols, in academic literature -- and observed in real net= works as well.

I note that this trade-off (slightly longer paths for lower control
 cost) may be perfectly fair, assuming that very low amounts of
user data traffic transit through the network. However, I do not
see this assumption mentioned as a justification for focusing on
the control cost metric and discarding the "path length" or the "total cost of getting user data through the network".

I believe that either these assumptions should be made explicit ("ther= e's so little user data traffic in a ROLL network that we do
not care about shortest paths") or -- if these assumptions do not
hold, that the evaluation criteria are incomplete.

I note that it's true that we can always add another criteria ad infini= tum, and that's CLEARLY not what we want to do. However when
I say "incomplete" in the above, I simply suggest that based on what is presented one cannot draw conclusions based on the
evaluation criteria....or, worse, that one draws the wrong
conclusions based on the information presented.

So, in a nutshell, I suggest that we address (i) the positioning
issue and (ii) the criteria issue thus:

o    Describe as I proposed above if ROLL and MANETs position the= mselves as I have deducted. If my deduction is incorrect, then
let's quickly iterate on the list as to understand how to do
produce an alternative description. If we can't do this, then the
conclusion can be that "we do not know how ROLL and MANET position the= mselves wrt each other", and we could then state that clearly? It *sho= uld* not be more than a couple of paragraphs worth of text
to add, I gather?

o    To the criteria, either of:

-    Add the assumption that "user data traffic is so low th= at path
lengths do not matter nor does the cost of carrying user data
traffice"

-    Add a criteria & evaluation of "path length"
-    Add a criteria & evaluation of "total cost for gett= ing user
data through the network"

This would make a large chunk of my concerns and issues vanish, and
 allow correctly interpreting and evaluating the rest of the
document.

How does that sound as an approach forward?

Cheers,

Thomas

On Jan 27, 2009, at 1:00 AM, Internet-Drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line
Internet-Drafts directories. This draft is a work item of the
Routing Over Low power and Lossy networks Working Group of the
IETF.

Title        : Overview of Existing Routing Protocols f= or Low Power and Lossy Networks Author(s)    : A. Tavakoli, S. Dawson-Haggerty, P. Levis Filename    :
draft-ietf-roll-protocols-survey-05.txt Pages        : = 26 Date
: 2009-1-26 Networks of low power wireless devices introduce
novel IP routing issues.  Low-power wireless devices, such as
sensors, actuators and smart objects, have difficult constraints:
very limited memory, little processing power, and long sleep
periods.  As most of these devices are battery-powered, energy
efficiency is critically important.  Wireless link qualities can
vary significantly over time, requiring protocols to make agile
decisions yet minimize topology change energy costs.  Routing
over such low power and lossy networks has novel requirements
that existing protocols may not address.  This document provides
a brief survey of the strengths and weaknesses of existing
protocols with respect to this class of networks.  From this survey it= examines whether existing and mature IETF protocols can
be used without modification in these networks, or whether
further work is necessary. is necessary.

A URL for this Internet-Draft is: http://www= .ietf.org/internet-drafts/draft-ietf-roll-protocols-survey-05.txt



Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-= drafts/

Below is the data which will enable a MIME compliant mail reader implementa= tion to automatically retrieve the ASCII version of the
 Internet-Draft. Content-Type: text/plain Content-ID:
<2009-= 1-26155804.I-D@ietf.org>

_______________________________________________ Roll mailing list
 Roll@ietf.org = ht= tps://www.ietf.org/mailman/listinfo/roll

_______________________________________________ Roll mailing list Roll@ietf.org https://www.iet= f.org/mailman/listinfo/roll
_______________________________________________ Roll mailing list Roll@ietf.org https://www.iet= f.org/mailman/listinfo/roll



--0015174c14225b8fff0461f8030c-- --===============1802670391== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1802670391==-- From roll-bounces@ietf.org Tue Feb 3 04:24:27 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1414828C169; Tue, 3 Feb 2009 04:24:27 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 726733A6BA8 for ; Mon, 2 Feb 2009 16:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVtRrOMPqQsd for ; Mon, 2 Feb 2009 16:53:25 -0800 (PST) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by core3.amsl.com (Postfix) with ESMTP id AC2CA3A69C1 for ; Mon, 2 Feb 2009 16:53:24 -0800 (PST) Received: by ewy14 with SMTP id 14so2181461ewy.13 for ; Mon, 02 Feb 2009 16:53:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=gExzkWINnDYG12q5v+yGcc4UlABdJNcS3XPOIOSnY40=; b=aVjMZ69CbWfvrSnMJJCErTTMqh4FJwx2Z8p7GlSOR2vlhXBjZVBBu0B5K+s0ZLiwn1 uZpot4WnCUHB5Dbh80k9+8tgzL2Ral0ALI1QjeaT1txA8fvbC8joxcKZSWBvC0wPagBN /+eN8GRGk1NbfB09qWWdOzyuBJ+DPRCgVnClc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=JpkK/6nO4S2ouWSEdFiEdfZjpkk1BQHnVI//gtOuGyH68EAdxqhcJjlL5ubCOo52ei Ar3d3H4McoRH3+Hlr9mHJV5zK4PxbqULrN4BU7P5QQM3AiPd1O4WI91BaCOSEuELNwkF ClITn/6Uf1nFSChWVi7WAHcu2wTRif00HwMzQ= MIME-Version: 1.0 Received: by 10.210.10.1 with SMTP id 1mr3042705ebj.189.1233622384284; Mon, 02 Feb 2009 16:53:04 -0800 (PST) In-Reply-To: <49878E46.7050105@gmail.com> References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <69306dde0902021535i353b02fdie689bf78d6fce7f5@mail.gmail.com> <49878E46.7050105@gmail.com> Date: Mon, 2 Feb 2009 16:53:04 -0800 X-Google-Sender-Auth: 44cc96bb1be3b51c Message-ID: <69306dde0902021653u4e9e0b89kaba0515c65824df2@mail.gmail.com> From: Arsalan Tavakoli To: Alexandru Petrescu X-Mailman-Approved-At: Tue, 03 Feb 2009 04:24:25 -0800 Cc: Ross Callon , roll@ietf.org, "David E. Culler" Subject: Re: [Roll] requirements? (was: Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0671729682==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0671729682== Content-Type: multipart/alternative; boundary=0015174c0dd800966c0461f91871 --0015174c0dd800966c0461f91871 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Comments Inline. On Mon, Feb 2, 2009 at 4:22 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Arsalan Tavakoli a =E9crit : > >> As was discussed earlier, at the protocol design stage, the group will b= e >> soliciting specifications for a protocol that meets the ROLL >> requirements, whether it is an extension/modification of an existing >> protocol, or a specification written from scratch. Advancing to >> that stage simply implies that no such specification (in its current >> form) presently exists. >> > > The protocol-survey draft wouldn't impede going to the next > stage, were it silently updated every 6 months, away from LastCall. I don't particularly understand the need for such a move. By definition, holding up the protocol-survey draft IS holding up going to the next stage. The purpose of the protocol survey draft is to determine whether an existing specification, again in current form, satisfies the set of criteria. Our current charter is limited to answering this question. In order to move to the design stage, at which point we start discussing actua= l protocol and design, we need to recharter, and we can not do that until thi= s draft is finalized, hence why this draft impedes us from moving on. By definition, the protocol specified during the next stage will satisfy the ROLL requirements, and changes to existing protocol specifications (for those evaluated in the draft) to allow them to pass ROLL criteria, can be presented during the next stage, which would make an update of the document a moot point. > > > We could probably then discuss requirements. > > Let me humbly propose a 're-usability' requirement, common: "an important > requirement is to identify and reuse as much as > possible an existing protocol that pertains to this application domain; > this has the immediate advantage of software availability for first > prototypes". Again, as David has written frequently, these are all very important issues that will need to be discussed when we move to the protocol and design stage. However, this is completely outside the scope of the protocol surve= y draft, and hence I believe should not be discussed in the draft. The draft takes no position on such a requirement. If we can close on this draft, then we can recharter, and move on to the next stage, at which point all these issues that everybody is so anxious to get to can be discussed, rathe= r than having to continually to postpone them as we block on this document. > > > What do you think? > > Alex > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --0015174c0dd800966c0461f91871 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Comments Inline.

On Mon, Feb 2, 2009 at 4= :22 PM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
Arsalan Tavakoli a =E9crit :
As was discussed earlier, at the protocol design stage, the group will be s= oliciting specifications for a protocol that meets the ROLL
 requirements, whether it is an extension/modification of an existing<= br>  protocol, or a specification written from scratch.  Advancing to=
that stage simply implies that no such specification (in its current
form) presently exists.

The protocol-survey draft wouldn't impede going to the next
stage, were it silently updated every 6 months, away from LastCall.

I don't particularly understand the need for s= uch a move.  By definition, holding up the protocol-survey draft IS ho= lding up going to the next stage.  The purpose of the protocol survey = draft is to determine whether an existing specification, again in current f= orm, satisfies the set of criteria.  Our current charter is limited to= answering this question.  In order to move to the design stage, at wh= ich point we start discussing actual protocol and design, we need to rechar= ter, and we can not do that until this draft is finalized, hence why this d= raft impedes us from moving on.  By definition, the protocol specified= during the next stage will satisfy the ROLL requirements, and changes to e= xisting protocol specifications (for those evaluated in the draft) to allow= them to pass ROLL criteria, can be presented during the next stage, which = would make an update of the document a moot point.
 


We could probably then discuss requirements.

Let me humbly propose a 're-usability' requirement, common: "a= n important requirement is to identify and reuse as much as
possible an existing protocol that pertains to this application domain;
this has the immediate advantage of software availability for first
prototypes".

Again, as David has writt= en frequently, these are all very important issues that will need to be dis= cussed when we move to the protocol and design stage.  However, this i= s completely outside the scope of the protocol survey draft, and hence I be= lieve should not be discussed in the draft.  The draft takes no positi= on on such a requirement.  If we can close on this draft, then we can = recharter, and move on to the next stage, at which point all these issues t= hat everybody is so anxious to get to can be discussed, rather than having = to continually to postpone them as we block on this document.
 


What do you think?

Alex
_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

--0015174c0dd800966c0461f91871-- --===============0671729682== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0671729682==-- From roll-bounces@ietf.org Tue Feb 3 04:24:27 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 396DD28C19E; Tue, 3 Feb 2009 04:24:27 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA2FD3A68FF for ; Tue, 3 Feb 2009 04:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.495 X-Spam-Level: X-Spam-Status: No, score=-10.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhExJaVsejYG for ; Tue, 3 Feb 2009 04:20:23 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9309E3A67B2 for ; Tue, 3 Feb 2009 04:20:21 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,372,1231113600"; d="scan'208,217";a="32690111" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2009 12:20:01 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n13CK1YK008501; Tue, 3 Feb 2009 13:20:01 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n13CK1Wb027972; Tue, 3 Feb 2009 12:20:01 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 13:20:01 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 13:19:59 +0100 Message-Id: From: JP Vasseur To: ROLL WG , Thomas Heide Clausen , David Ward , Ross Callon , mtownsley@cisco.com, jari.arkko@piuha.net In-Reply-To: <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Feb 2009 13:19:59 +0100 References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Feb 2009 12:20:00.0321 (UTC) FILETIME=[BBF05310:01C985F9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=35843; t=1233663601; x=1234527601; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20*=20ALL=20PLEASE=20READ=20**=20TIME=20FOR=20CLO SURE=20?=20Re=3A=20[Roll]=20Review=20and=20comments=20draft- ietf-roll-protocols-survey-05.txt |Sender:=20; bh=J0w0K88Y1jrB6gArg3NTiuhRo0+HHmXlzbg4pYEKxFk=; b=cwMzcNy0lKbjyvhdV5NFGhl4PByTKpLCsIxC875Q2mCPrARyQOF2QQsoV6 24b6pz5+8fRej1j+D5azKCewIW7N4Q6tLuwsgZ7lhKxw/+xRVcIhjCMbc+pK XSwzqxDCOR; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Mailman-Approved-At: Tue, 03 Feb 2009 04:24:25 -0800 Cc: Arsalan Tavakoli , Geoff Mulligan , "David E. Culler" , stevedh@cs.berkeley.edu Subject: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review and comments draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1038554624==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1038554624== Content-Type: multipart/alternative; boundary=Apple-Mail-97--194154782 --Apple-Mail-97--194154782 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear WG and ADs, Two issues are raised here for which we would appreciate ADs' point of view and feed-back from the WG. Please see in line. Dear Thomas, At the risk of repeating myself, I'd like to make a few important statements before *hopefully* come to a closure ;-) -> As you know, many of the ROLL WG active participants have been working quite hard to produce a detailed set of requirements, discuss how to proceed on the protocol survey document, and other ID are in the works. -> We managed to get highly experienced contributors in the field that have designed and deployed solutions so they not only have an excellent expertise of the requirements but also on solutions, -> Yes we need to rush out. Why ? Because proprietary or semi-closed non-IP solutions are being deployed at a fairly large scale. I do not think that I have to convince anybody on this list that this is the WRONG approach for a number of reasons. The industry is asking for an IP solution *now*. -> No we do not want to re-invent the wheel (see our presentation at the routing plenary in Chicago). Anything that already exists MUST (rfc2119 ;-)) be used provided that it meets our requirements. And if we can adapt an existing protocol, we are all for it ! -> Yes these requirements are quite specifics and this is precisely why ROLL has been formed, 4 application-specific routing requirements have been produced (to reduce the scope). Even if at a first sight, it looks very much similar to a MANET issue (and there ARE similarities but also very different requirements), having to deal with a highly static network of hundreds of thousands of battery operated sleeping nodes with 4K of RAM is quite specific. Note that this is not a random example, but an on-going non-IP deployed network. And to conclude on this introduction ... after an outstanding progress on the WG during the first 6-8 months, we have been slowed down dramatically for the last 2 months, thus it is time to close and move on to quickly re-charter and start the protocol work (hopefully as light as possible) to see IP-based solution deployed. I know that we are on the same page, we just need to find a good compromise on both "sides". Nothing new so far, let's move to a proposed resolution - See in line, On Feb 2, 2009, at 7:37 PM, Thomas Heide Clausen wrote: > All, > > I promised a review, and I apologize that I wasn't able to do so > before the weekend as originally projected. > > Other than some typos that Chris and others have pointed out, I'll > try to offer my understanding of the problem space and suggest some > ways of addressing my main concerns.... > > My first main concern remain that it is not clear, still, how ROLL > positions itself with respect to MANET, 6LOW et. al, all of which > appear to be within the same space and within the IETF. This I-D > sees ROLL as presented with entirely new problems (the use of > "novel" in the abstract, the statement that "existing protocols were > not designed with these requirements in mind" seem to confirm this). > > Looking at the requirements listed, including "low power, low > bandwidth, low footprint", these appear similar to those which are > also brought forward in e.g. MANET and 6LOW. Reading (quickly, I > confess) the various requirements documents of the draft-ietf-roll > series present scenarios which are similar to those where MANETs are > deployed, and are thought deployed, as well. > > I also note that many additional (and unstated) characteristics > between ROLL and e.g. MANET are the same: mobile, wireless, > fragility, auto-configuration, IP routing, interface/link issues... > > Arguing that, as does this I-D, despite the above impression "ROLL > is novel and different" invites asking "how, exactly?" I think that > this question is valid, and merits being answered, before the > evaluations in this I-D can be judged fairly. > > Note that I come from a MANET background, and so I *could* interpret > from the ROLL discussion that where MANETs may aim for "low power, > low bandwidth, ....", ROLL may be able to quantify these as "below > this firm threshold" -- i.e. as a sort of "extreme" or "constrained" > MANET. > > This is a personal observation, I note, which would allow me to > comprehend how ROLL and MANET are positioned relative to one another > -- but one which neither this I-D nor the requirements document > spell out or quantify -- or, for that matter, debunk. > > I think it's critical to understand this, in order to understand the > need for a new protocol development. I think it is important to > document this understanding in something with more persistency. > > If what I suggest above makes sense as a way of positioning ROLL and > MANET relative to one another, I'd suggest including something to > this effect in the survey I-D, as this I-D is the one making a > *direct* reference to the applicability of MANET protocols to ROLL. > > If what I suggest doesn't make sense at all, then I'd be happy to > have it debunked and, hopefully, through that debunking a > positioning/description that does ring true with us all can be > produced? > > My second main concern is, that I still think that the choice of > criteria is unfortunate (not the word, Phill has me convinced on > that front, but the actual criteria). Control cost is, by all means, > a rather meaningless criteria when taken in isolation. I've sketched > a "zero-control-cost" routing protocol (flood all data - say use > SMF, also a MANET protocol, and also a rather "mature" I-D and wg > item) which would score well on the control cost criteria, but would > likely be an extremely bad choice for delivering unicast data. > > The metric which matters, and which should matter to ROLL in > particular, is "the total cost of getting user data through the > network, including control cost necessary to set up paths" -- as we > know, every packet sent and received costs bandwidth, energy and > cycles -- user data no different from contro. > > According to the criterions as set up by this I-D, a protocol > producing "longer than shortest paths" at the benefit of slightly > lower control cost would score better than a protocol producing > "shortest paths" with slightly higher control cost. This is not > hypothetical, btw., there are plenty of studies observing and > reflecting upon this regarding the different MANET protocols, in > academic literature -- and observed in real networks as well. > > I note that this trade-off (slightly longer paths for lower control > cost) may be perfectly fair, assuming that very low amounts of user > data traffic transit through the network. However, I do not see this > assumption mentioned as a justification for focusing on the control > cost metric and discarding the "path length" or the "total cost of > getting user data through the network". > > I believe that either these assumptions should be made explicit > ("there's so little user data traffic in a ROLL network that we do > not care about shortest paths") or -- if these assumptions do not > hold, that the evaluation criteria are incomplete. > > I note that it's true that we can always add another criteria ad > infinitum, and that's CLEARLY not what we want to do. However when I > say "incomplete" in the above, I simply suggest that based on what > is presented one cannot draw conclusions based on the evaluation > criteria....or, worse, that one draws the wrong conclusions based on > the information presented. It is not easy to answer each of your point without running the risk to start a debate that will never end. You raised some excellent points that I agree with and others that I firmly disagree with ... So let me try to make a few observations: 1) As pointed out earlier, yes there are similarities between MANET and ROLL. I do not see this as an issue. 2) The aim of the protocol survey IS NOT to exclude MANET protocols. As mentioned many times on the list, we *only* wanted to show that existing protocols, with no change, could not be used in LLNs. This has been clarified in the document as your request and it HAD to be clarified. 3) We could have used two different approaches for the survey: - Look at all MUST from the requirements documents - Try to derive a subset of necessary but not sufficient criteria, which the WG chose to do (consensus). Yes this list is not perfect, criteria could be changed, removed or added but looked good enough with excellent consensus until LC. 4) With regards to 6lowpan (I copy the chair), I do not see any overlap at all. Please refer to their charter and WG items. The only place that required clarification was the routing requirements and I was personally opposed to it but this was adopted as a 6lowpan WG item by consensus. We're are working together and managed to sort this out. This document will be 6lowpan specific. What I want to avoid is an endless discussion on the positioning of ROLL, MANET, 6lowpan and quite frankly we could add other WGs to the list. So what is the bottom line ? We just need to agree on the fact that there is no existing protocol that meets the ROLL requirements and move to the next step (re- chartering) to select one (hopefully not two) routing protocols in light of the routing requirement (NOT the protocol survey), which can either be an adapted MANET protocol or a new protocol. Now moving to your proposed resolution. > > > So, in a nutshell, I suggest that we address (i) the positioning > issue and (ii) the criteria issue thus: > > o Describe as I proposed above if ROLL and MANETs position > themselves as I > have deducted. If my deduction is incorrect, then let's quickly > iterate on the list > as to understand how to do produce an alternative description. If > we can't do this, > then the conclusion can be that "we do not know how ROLL and MANET > position > themselves wrt each other", and we could then state that clearly? > > It *should* not be more than a couple of paragraphs worth of text > to add, I gather? > If you find a way to word this, please feel free and I'd be happy to help but feel it as necessary ... Any opinion from our RTG and INT ADs ? > o To the criteria, either of: > > - Add the assumption that "user data traffic is so low that path > lengths do not > matter nor does the cost of carrying user data traffice" > The motivation for selecting a longer path is not tied to the amount of traffic here but the level of constraints. Note that this is also true for several other technologies such as MPLS-TE. You may have large amount of traffic and still require to follow a non-shortest path (constrained based routing). This is detailed in several requirements IDs. Criticality of data is of course different, thus the requirements for potentially different data paths according to packet marking using DSCP. > - Add a criteria & evaluation of "path length" > > - Add a criteria & evaluation of "total cost for getting user > data through the network" > And we can add many more but if the current protocol do not satisfy existing requirements, isn't it sufficient to answer the question on whether one can find an existing protocol? > This would make a large chunk of my concerns and issues vanish, and > allow correctly interpreting and evaluating the rest of the document. That said, question for the WG. Who think that such criteria should be added to move forward ? Please reply. > > > How does that sound as an approach forward? > Thanks for helping out. Cheers. JP. > Cheers, > > Thomas > > On Jan 27, 2009, at 1:00 AM, Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Routing Over Low power and Lossy >> networks Working Group of the IETF. >> >> Title : Overview of Existing Routing Protocols for Low Power and >> Lossy Networks >> Author(s) : A. Tavakoli, S. Dawson-Haggerty, P. Levis >> Filename : draft-ietf-roll-protocols-survey-05.txt >> Pages : 26 >> Date : 2009-1-26 >> >> Networks of low power wireless devices introduce novel IP routing >> issues. Low-power wireless devices, such as sensors, actuators and >> smart objects, have difficult constraints: very limited memory, >> little processing power, and long sleep periods. As most of these >> devices are battery-powered, energy efficiency is critically >> important. Wireless link qualities can vary significantly over >> time, >> requiring protocols to make agile decisions yet minimize topology >> change energy costs. Routing over such low power and lossy >> networks >> has novel requirements that existing protocols may not address. >> This >> document provides a brief survey of the strengths and weaknesses of >> existing protocols with respect to this class of networks. From >> this >> survey it examines whether existing and mature IETF protocols can >> be >> used without modification in these networks, or whether further >> work >> is necessary. >> is necessary. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-survey-05.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> Content-Type: text/plain >> Content-ID: <2009-1-26155804.I-D@ietf.org> >> >> _______________________________________________ >> 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 --Apple-Mail-97--194154782 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Dear WG and = ADs,

Two issues are raised here for which we = would appreciate ADs' point of view and feed-back from the WG. Please = see in line.


Dear = Thomas,

At the risk of repeating myself, I'd like to = make a few important statements before *hopefully* come to a closure = ;-)

-> As you know, many of the ROLL WG active = participants have been working quite hard to produce a detailed set of = requirements, discuss how to proceed on the protocol survey document, = and other ID are in the works.
-> We managed to get highly = experienced contributors in the field that have designed and = deployed solutions so they not only have an excellent expertise of the = requirements but also on solutions,
-> Yes we need to rush = out. Why ? Because proprietary or semi-closed non-IP solutions are being = deployed at a fairly large scale. I do not think that I have to convince = anybody on this list that this is the WRONG approach for a number of = reasons. The industry is asking for an IP solution = *now*.
-> No we do not want to re-invent the wheel (see = our presentation at the routing plenary in Chicago). Anything that = already exists MUST (rfc2119 ;-)) be used provided that it meets our = requirements. And if we can adapt an existing protocol, we are all for = it !
-> Yes these requirements are quite specifics and this is = precisely why ROLL has been formed, 4 application-specific routing = requirements have been produced (to reduce the scope). Even if at a = first sight, it looks very much similar to a MANET issue (and there ARE = similarities but also very different requirements), having to deal with = a highly static network of hundreds of thousands of battery operated = sleeping nodes with 4K of RAM is quite specific. Note that this is not a = random example, but an on-going non-IP deployed = network.

And to conclude on this introduction = ... after an outstanding progress on the WG during the first 6-8 months, = we have been slowed down dramatically for the last 2 months, thus it is = time to close and move on to quickly re-charter and start the protocol = work (hopefully as light as possible) to see IP-based solution deployed. = I know that we are on the same page, we just need to find a good = compromise on both "sides".

Nothing new so far, = let's move to a proposed resolution - See in = line,

On Feb 2, 2009, at 7:37 PM, = Thomas Heide Clausen wrote:

All,

I promised a review, and I apologize that = I wasn't able to do so before the weekend as originally = projected.

Other than some typos that Chris and others have = pointed out, I'll try to offer my understanding of the problem space and = suggest some ways of addressing my main concerns....

My first = main concern remain that it is not clear, still, how ROLL positions = itself with respect to MANET, 6LOW et. al, all of which appear to be = within the same space and within the IETF. This I-D sees ROLL as = presented with entirely new problems (the use of "novel" in the = abstract, the statement that "existing protocols were not designed with = these requirements in mind" seem to confirm this).

Looking at the =  requirements listed, including "low power, low bandwidth, low = footprint", these appear similar to those which are also brought forward = in e.g. MANET and 6LOW. Reading (quickly, I confess) the various = requirements documents  of the draft-ietf-roll series present = scenarios which are similar to those where MANETs are deployed, and are = thought deployed, as well.

I also note that many additional (and = unstated) characteristics between ROLL and e.g. MANET are the same: = mobile, wireless, fragility, auto-configuration, IP routing, = interface/link issues...

Arguing that, as does this I-D, despite = the above impression "ROLL is novel and different" invites asking "how, = exactly?" I think that this question is valid, and merits being = answered, before the evaluations in this I-D can be judged = fairly.

Note that I come from a MANET background, and so I = *could* interpret from the ROLL discussion that where MANETs may aim for = "low power, low bandwidth, ....", ROLL may be able to quantify these as = "below this firm threshold" -- i.e. as a sort of "extreme" or = "constrained" MANET.

This is a personal observation, I note, = which would allow me to comprehend how ROLL and MANET are positioned = relative to one another -- but one which neither this I-D nor the = requirements document spell out or quantify -- or, for that matter, = debunk.

I think it's critical to understand this, in order to = understand the need for a new protocol development. I think it is = important to document this understanding in something with more = persistency.

If what I suggest above makes sense as a way of = positioning ROLL and MANET relative to one another, I'd suggest = including something to this effect in the survey I-D, as this I-D is the = one making a *direct* reference to the applicability of MANET protocols = to ROLL.

If what I suggest doesn't make sense at all, then I'd be = happy to have it debunked and, hopefully, through that debunking a = positioning/description that does ring true with us all can be = produced?

My second main concern is, that I still think that the = choice of criteria is unfortunate (not the word, Phill has me convinced = on that front, but the actual criteria). Control cost is, by all means, = a rather meaningless criteria when taken in isolation. I've sketched a = "zero-control-cost" routing protocol (flood all data - say use SMF, also = a MANET protocol, and also a rather "mature" I-D and wg item) which = would score well on the control cost criteria, but would likely be an = extremely bad choice for delivering unicast data.

The metric = which matters, and which should matter to ROLL in particular, is "the = total cost of getting user data through the network, including control = cost necessary to set up paths" -- as we know, every packet sent and = received costs bandwidth, energy and cycles -- user data no different = from contro.

According to the criterions as set up by this I-D, a = protocol producing "longer than shortest paths" at the benefit of = slightly lower control cost would score better than a protocol producing = "shortest paths" with slightly higher control cost. This is not = hypothetical, btw., there are plenty of studies observing and reflecting = upon this regarding the different MANET protocols, in academic = literature -- and observed in real networks as well.

I note that = this trade-off (slightly longer paths for lower control cost) may be = perfectly fair, assuming that very low amounts of user data traffic = transit through the network. However, I do not see this assumption = mentioned as a justification for focusing on the control cost metric and = discarding the "path length" or the "total cost of getting user data = through the network".

I believe that either these assumptions = should be made explicit ("there's so little user data traffic in a ROLL = network that we do not care about shortest paths") or -- if these = assumptions do not hold, that the evaluation criteria are = incomplete.

I note that it's true that we can always add another = criteria ad infinitum, and that's CLEARLY not what we want to do. = However when I say "incomplete" in the above, I simply suggest that = based on what is presented one cannot draw conclusions based on the = evaluation criteria....or, worse, that one draws the wrong conclusions = based on the information = presented.

It is not easy to = answer each of your point without running the risk to start a debate = that will never end. You raised some excellent points that I agree with = and others that I firmly disagree with ... So let me try to make a few = observations:
1) As pointed out earlier, yes there are = similarities between MANET and ROLL. I do not see this as an = issue.
2) The aim of the protocol survey IS NOT to exclude = MANET protocols. As mentioned many times on the list, we *only* wanted = to show that existing protocols, with no change, could not be used in = LLNs. This has been clarified in the document as your request and it HAD = to be clarified.
3) We could have used two different = approaches for the survey:
- Look at all MUST from the = requirements documents
- Try to derive a subset of = necessary but not sufficient criteria, which the WG chose to do = (consensus). Yes this list is not perfect,
criteria = could be changed, removed or added but looked good enough with excellent = consensus until LC.
4) With regards to 6lowpan (I copy the = chair), I do not see any overlap at all. Please refer to their charter = and WG items. The only place that required clarification was the routing = requirements and I was personally opposed to it but this was adopted as = a 6lowpan WG item by consensus. We're are working together and = managed to sort this out. This document will be 6lowpan = specific.

What I want to avoid is an endless = discussion on the positioning of ROLL, MANET, 6lowpan and quite frankly = we could add other WGs to the list.

So what = is the bottom line ?

We just need to agree = on the fact that there is no existing protocol that meets the ROLL = requirements and move to the next step (re-chartering) to select one = (hopefully not two) routing protocols in light of the routing = requirement (NOT the protocol survey), which can either be an adapted = MANET protocol or a new protocol.

Now moving to = your proposed resolution.



So, in a nutshell, I suggest that we address = (i) the positioning issue and (ii) the criteria issue thus:

o Describe = as I proposed above if ROLL and MANETs position themselves as I
have = deducted. If my deduction is incorrect, then let's quickly iterate on = the list
= = as to understand how to do produce an alternative description. If = we can't do this,
then the conclusion can be that = "we do not know how ROLL and MANET position
= themselves wrt each other", and we could then state that = clearly?
= =
= = It *should* not be more than a couple of paragraphs worth of text = to add, I gather?


If you find a = way to word this, please feel free and I'd be happy to help but feel it = as necessary ... Any opinion from our RTG and INT ADs = ?

o To the = criteria, either of:

- Add the assumption that "user = data traffic is so low that path lengths do not
matter = nor does the cost of carrying user data = traffice"


The motivation = for selecting a longer path is not tied to the amount of traffic here = but the level of constraints. Note that this is also true for several = other technologies such as MPLS-TE. You may have large amount of traffic = and still require to follow a non-shortest path (constrained based = routing). This is detailed in several requirements IDs. Criticality of = data is of course different, thus the requirements for potentially = different data paths according to packet marking using = DSCP.

- Add a = criteria & evaluation of "path length"

- Add a = criteria & evaluation of "total cost for getting user data through = the network"


And we can = add many more but if the current protocol do not satisfy existing = requirements, isn't it sufficient to answer the question on whether one = can find an existing protocol?

This would make a large chunk of my concerns and = issues vanish, and allow correctly interpreting and evaluating the rest = of the document.

That said, = question for the WG. Who think that such criteria should be added to = move forward ? Please reply.



How does that sound as an approach = forward?


Thanks for = helping = out.

Cheers.

JP.
Cheers,

Thomas

On Jan 27, = 2009, at 1:00 AM, Internet-Drafts@ietf.org = wrote:

A New Internet-Draft is = available from the on-line Internet-Drafts
directories.
This = draft is a work item of the Routing Over Low power and Lossy networks = Working Group of the IETF.

= Title = = : Overview of Existing Routing Protocols for Low Power and Lossy = Networks
= Author(s) = : A. Tavakoli, S. Dawson-Haggerty, P. = Levis
= Filename = : = draft-ietf-roll-protocols-survey-05.txt
= Pages = = : 26
Date : = 2009-1-26
=
Networks of low power = wireless devices introduce novel IP routing
  issues.  Low-power wireless devices, = such as sensors, actuators and
=   smart objects, have difficult constraints: very limited = memory,
  little = processing power, and long sleep periods.  As most of = these
  devices are = battery-powered, energy efficiency is = critically
=   important.  Wireless link qualities can vary = significantly over time,
=   requiring protocols to make agile decisions yet minimize = topology
  change = energy costs.  Routing over such low power and lossy = networks
  has = novel requirements that existing protocols may not address. =  This
=   document provides a brief survey of the strengths and = weaknesses of
=   existing protocols with respect to this class of networks. =  =46rom this
=   survey it examines whether existing and mature IETF = protocols can be
=   used without modification in these networks, or whether = further work
  is = necessary.
  is = necessary.

A URL for this = Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-s= urvey-05.txt

Internet-Drafts = are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-d= rafts/

Below is the = data which will enable a MIME compliant mail = reader
implementation to = automatically retrieve the ASCII version of = the
Internet-Draft.
Content-Type: text/plain
Content-ID: <2009-1-26155804.I-D@ietf.org<= /a>>

_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

_____________________________= __________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-97--194154782-- --===============1038554624== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1038554624==-- From roll-bounces@ietf.org Tue Feb 3 05:21:17 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D61D03A68A1; Tue, 3 Feb 2009 05:21:17 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF9033A63EB for ; Tue, 3 Feb 2009 05:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AT45+t5P6NC3 for ; Tue, 3 Feb 2009 05:21:13 -0800 (PST) Received: from mho-01-bos.mailhop.org (mho-01-bos.mailhop.org [63.208.196.178]) by core3.amsl.com (Postfix) with ESMTP id 0EC1F3A68A1 for ; Tue, 3 Feb 2009 05:21:13 -0800 (PST) Received: from sphinx.lix.polytechnique.fr ([129.104.11.1] helo=[192.168.112.180]) by mho-01-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LULCu-000I2U-NE for roll@ietf.org; Tue, 03 Feb 2009 13:20:53 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 129.104.11.1 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/psx+ToVG3gc7TCW72rO5b Mime-Version: 1.0 (Apple Message framework v753.1) In-Reply-To: References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> Message-Id: From: Thomas Heide Clausen Date: Tue, 3 Feb 2009 14:19:12 +0100 To: ROLL WG X-Mailer: Apple Mail (2.753.1) Subject: Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review and comments draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0433484121==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0433484121== Content-Type: multipart/alternative; boundary=Apple-Mail-6--190601037 --Apple-Mail-6--190601037 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear JP, dear ADs, dear WG, For the record, I am not arguing that MANET protocols should be applied or be applicable -- as you seem to suggest in your email. I believe that I have stated so repeatedly. I submit, however, that as it is currently exposed, ROLL, MANET and 6LOW seem to be operating within the same space -- to the untrained eye, in exactly the same space. My position is that it would be very unfortunate having one WG creating confusion on the applicability of the work of itself and of other IETF wg's, by simple omission of suitable perimeter definitions. In that sort of situation, the IETF needs to be extra prudent to make sure to clearly spell out suitable perimeter definitions prior to, or conjointly with, the first publication cycle. In this case, before or with the survey I-D. Sincerely, Thomas On Feb 3, 2009, at 1:19 PM, JP Vasseur wrote: > Dear WG and ADs, > > Two issues are raised here for which we would appreciate ADs' point > of view and feed-back from the WG. Please see in line. > > > Dear Thomas, > > At the risk of repeating myself, I'd like to make a few important > statements before *hopefully* come to a closure ;-) > > -> As you know, many of the ROLL WG active participants have been > working quite hard to produce a detailed set of requirements, > discuss how to proceed on the protocol survey document, and other > ID are in the works. > -> We managed to get highly experienced contributors in the field > that have designed and deployed solutions so they not only have an > excellent expertise of the requirements but also on solutions, > -> Yes we need to rush out. Why ? Because proprietary or semi- > closed non-IP solutions are being deployed at a fairly large scale. > I do not think that I have to convince anybody on this list that > this is the WRONG approach for a number of reasons. The industry is > asking for an IP solution *now*. > -> No we do not want to re-invent the wheel (see our presentation > at the routing plenary in Chicago). Anything that already exists > MUST (rfc2119 ;-)) be used provided that it meets our requirements. > And if we can adapt an existing protocol, we are all for it ! > -> Yes these requirements are quite specifics and this is precisely > why ROLL has been formed, 4 application-specific routing > requirements have been produced (to reduce the scope). Even if at a > first sight, it looks very much similar to a MANET issue (and there > ARE similarities but also very different requirements), having to > deal with a highly static network of hundreds of thousands of > battery operated sleeping nodes with 4K of RAM is quite specific. > Note that this is not a random example, but an on-going non-IP > deployed network. > > And to conclude on this introduction ... after an outstanding > progress on the WG during the first 6-8 months, we have been slowed > down dramatically for the last 2 months, thus it is time to close > and move on to quickly re-charter and start the protocol work > (hopefully as light as possible) to see IP-based solution deployed. > I know that we are on the same page, we just need to find a good > compromise on both "sides". > > Nothing new so far, let's move to a proposed resolution - See in line, > > On Feb 2, 2009, at 7:37 PM, Thomas Heide Clausen wrote: > >> All, >> >> I promised a review, and I apologize that I wasn't able to do so >> before the weekend as originally projected. >> >> Other than some typos that Chris and others have pointed out, I'll >> try to offer my understanding of the problem space and suggest >> some ways of addressing my main concerns.... >> >> My first main concern remain that it is not clear, still, how ROLL >> positions itself with respect to MANET, 6LOW et. al, all of which >> appear to be within the same space and within the IETF. This I-D >> sees ROLL as presented with entirely new problems (the use of >> "novel" in the abstract, the statement that "existing protocols >> were not designed with these requirements in mind" seem to confirm >> this). >> >> Looking at the requirements listed, including "low power, low >> bandwidth, low footprint", these appear similar to those which are >> also brought forward in e.g. MANET and 6LOW. Reading (quickly, I >> confess) the various requirements documents of the draft-ietf- >> roll series present scenarios which are similar to those where >> MANETs are deployed, and are thought deployed, as well. >> >> I also note that many additional (and unstated) characteristics >> between ROLL and e.g. MANET are the same: mobile, wireless, >> fragility, auto-configuration, IP routing, interface/link issues... >> >> Arguing that, as does this I-D, despite the above impression "ROLL >> is novel and different" invites asking "how, exactly?" I think >> that this question is valid, and merits being answered, before the >> evaluations in this I-D can be judged fairly. >> >> Note that I come from a MANET background, and so I *could* >> interpret from the ROLL discussion that where MANETs may aim for >> "low power, low bandwidth, ....", ROLL may be able to quantify >> these as "below this firm threshold" -- i.e. as a sort of >> "extreme" or "constrained" MANET. >> >> This is a personal observation, I note, which would allow me to >> comprehend how ROLL and MANET are positioned relative to one >> another -- but one which neither this I-D nor the requirements >> document spell out or quantify -- or, for that matter, debunk. >> >> I think it's critical to understand this, in order to understand >> the need for a new protocol development. I think it is important >> to document this understanding in something with more persistency. >> >> If what I suggest above makes sense as a way of positioning ROLL >> and MANET relative to one another, I'd suggest including something >> to this effect in the survey I-D, as this I-D is the one making a >> *direct* reference to the applicability of MANET protocols to ROLL. >> >> If what I suggest doesn't make sense at all, then I'd be happy to >> have it debunked and, hopefully, through that debunking a >> positioning/description that does ring true with us all can be >> produced? >> >> My second main concern is, that I still think that the choice of >> criteria is unfortunate (not the word, Phill has me convinced on >> that front, but the actual criteria). Control cost is, by all >> means, a rather meaningless criteria when taken in isolation. I've >> sketched a "zero-control-cost" routing protocol (flood all data - >> say use SMF, also a MANET protocol, and also a rather "mature" I-D >> and wg item) which would score well on the control cost criteria, >> but would likely be an extremely bad choice for delivering unicast >> data. >> >> The metric which matters, and which should matter to ROLL in >> particular, is "the total cost of getting user data through the >> network, including control cost necessary to set up paths" -- as >> we know, every packet sent and received costs bandwidth, energy >> and cycles -- user data no different from contro. >> >> According to the criterions as set up by this I-D, a protocol >> producing "longer than shortest paths" at the benefit of slightly >> lower control cost would score better than a protocol producing >> "shortest paths" with slightly higher control cost. This is not >> hypothetical, btw., there are plenty of studies observing and >> reflecting upon this regarding the different MANET protocols, in >> academic literature -- and observed in real networks as well. >> >> I note that this trade-off (slightly longer paths for lower >> control cost) may be perfectly fair, assuming that very low >> amounts of user data traffic transit through the network. However, >> I do not see this assumption mentioned as a justification for >> focusing on the control cost metric and discarding the "path >> length" or the "total cost of getting user data through the network". >> >> I believe that either these assumptions should be made explicit >> ("there's so little user data traffic in a ROLL network that we do >> not care about shortest paths") or -- if these assumptions do not >> hold, that the evaluation criteria are incomplete. >> >> I note that it's true that we can always add another criteria ad >> infinitum, and that's CLEARLY not what we want to do. However when >> I say "incomplete" in the above, I simply suggest that based on >> what is presented one cannot draw conclusions based on the >> evaluation criteria....or, worse, that one draws the wrong >> conclusions based on the information presented. > > It is not easy to answer each of your point without running the > risk to start a debate that will never end. You raised some > excellent points that I agree with and others that I firmly > disagree with ... So let me try to make a few observations: > 1) As pointed out earlier, yes there are similarities between MANET > and ROLL. I do not see this as an issue. > 2) The aim of the protocol survey IS NOT to exclude MANET > protocols. As mentioned many times on the list, we *only* wanted to > show that existing protocols, with no change, could not be used in > LLNs. This has been clarified in the document as your request and > it HAD to be clarified. > 3) We could have used two different approaches for the survey: > - Look at all MUST from the requirements documents > - Try to derive a subset of necessary but not sufficient criteria, > which the WG chose to do (consensus). Yes this list is not perfect, > criteria could be changed, removed or added but looked good enough > with excellent consensus until LC. > 4) With regards to 6lowpan (I copy the chair), I do not see any > overlap at all. Please refer to their charter and WG items. The > only place that required clarification was the routing requirements > and I was personally opposed to it but this was adopted as a > 6lowpan WG item by consensus. We're are working together and > managed to sort this out. This document will be 6lowpan specific. > > What I want to avoid is an endless discussion on the positioning of > ROLL, MANET, 6lowpan and quite frankly we could add other WGs to > the list. > > So what is the bottom line ? > > We just need to agree on the fact that there is no existing > protocol that meets the ROLL requirements and move to the next step > (re-chartering) to select one (hopefully not two) routing protocols > in light of the routing requirement (NOT the protocol survey), > which can either be an adapted MANET protocol or a new protocol. > > Now moving to your proposed resolution. > >> >> >> So, in a nutshell, I suggest that we address (i) the positioning >> issue and (ii) the criteria issue thus: >> >> o Describe as I proposed above if ROLL and MANETs position >> themselves as I >> have deducted. If my deduction is incorrect, then let's quickly >> iterate on the list >> as to understand how to do produce an alternative description. >> If we can't do this, >> then the conclusion can be that "we do not know how ROLL and >> MANET position >> themselves wrt each other", and we could then state that clearly? >> >> It *should* not be more than a couple of paragraphs worth of >> text to add, I gather? >> > > If you find a way to word this, please feel free and I'd be happy > to help but feel it as necessary ... Any opinion from our RTG and > INT ADs ? > >> o To the criteria, either of: >> >> - Add the assumption that "user data traffic is so low that >> path lengths do not >> matter nor does the cost of carrying user data traffice" >> > > The motivation for selecting a longer path is not tied to the > amount of traffic here but the level of constraints. Note that this > is also true for several other technologies such as MPLS-TE. You > may have large amount of traffic and still require to follow a non- > shortest path (constrained based routing). This is detailed in > several requirements IDs. Criticality of data is of course > different, thus the requirements for potentially different data > paths according to packet marking using DSCP. > >> - Add a criteria & evaluation of "path length" >> >> - Add a criteria & evaluation of "total cost for getting user >> data through the network" >> > > And we can add many more but if the current protocol do not satisfy > existing requirements, isn't it sufficient to answer the question > on whether one can find an existing protocol? > >> This would make a large chunk of my concerns and issues vanish, >> and allow correctly interpreting and evaluating the rest of the >> document. > > That said, question for the WG. Who think that such criteria should > be added to move forward ? Please reply. > >> >> >> How does that sound as an approach forward? >> > > Thanks for helping out. > > Cheers. > > JP. > >> Cheers, >> >> Thomas >> >> On Jan 27, 2009, at 1:00 AM, Internet-Drafts@ietf.org wrote: >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Routing Over Low power and Lossy >>> networks Working Group of the IETF. >>> >>> Title : Overview of Existing Routing Protocols for Low Power >>> and Lossy Networks >>> Author(s) : A. Tavakoli, S. Dawson-Haggerty, P. Levis >>> Filename : draft-ietf-roll-protocols-survey-05.txt >>> Pages : 26 >>> Date : 2009-1-26 >>> >>> Networks of low power wireless devices introduce novel IP routing >>> issues. Low-power wireless devices, such as sensors, actuators >>> and >>> smart objects, have difficult constraints: very limited memory, >>> little processing power, and long sleep periods. As most of these >>> devices are battery-powered, energy efficiency is critically >>> important. Wireless link qualities can vary significantly over >>> time, >>> requiring protocols to make agile decisions yet minimize topology >>> change energy costs. Routing over such low power and lossy >>> networks >>> has novel requirements that existing protocols may not >>> address. This >>> document provides a brief survey of the strengths and >>> weaknesses of >>> existing protocols with respect to this class of networks. >>> From this >>> survey it examines whether existing and mature IETF protocols >>> can be >>> used without modification in these networks, or whether further >>> work >>> is necessary. >>> is necessary. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols- >>> survey-05.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> Content-Type: text/plain >>> Content-ID: <2009-1-26155804.I-D@ietf.org> >>> >>> _______________________________________________ >>> 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 > --Apple-Mail-6--190601037 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Dear JP, dear ADs, dear WG,

For the record, I am not = arguing that MANET protocols should be applied or be applicable -- as = you seem to suggest in your email.=A0I believe that I have stated so = repeatedly.

I submit, = however, that as it is currently exposed, ROLL, MANET and 6LOW seem to = be operating within the same space -- to the untrained eye, in exactly = the same space.=A0My position is that it would be very unfortunate = having one WG creating confusion on the applicability of the work of = itself and of other IETF wg's, by simple omission of suitable perimeter = definitions.=A0

In that sort of situation, the IETF needs to be = extra prudent to make sure to clearly spell out suitable perimeter = definitions prior to, or conjointly with, the first publication cycle. = In this case, before or with the survey I-D.


Thomas

On Feb 3, = 2009, at 1:19 PM, JP Vasseur wrote:

Dear = WG and ADs,

Two issues are raised here for = which we would appreciate ADs' point of view and feed-back from the WG. = Please see in line.


Dear = Thomas,

At the risk of repeating myself, I'd like to = make a few important statements before *hopefully* come to a closure = ;-)

-> As you know, many of the ROLL WG active = participants have been working quite hard to produce a detailed set of = requirements, discuss how to proceed on the protocol survey document, = and other ID are in the works.
-> We managed to get highly = experienced contributors in the field that have=A0designed=A0and = deployed solutions so they not only have an excellent expertise of the = requirements but also on solutions,
-> Yes we need to rush = out. Why ? Because proprietary or semi-closed non-IP solutions are being = deployed at a fairly large scale. I do not think that I have to convince = anybody on this list that this is the WRONG approach for a number of = reasons. The industry is asking for an IP solution = *now*.
-> No we do not want to re-invent the wheel (see = our presentation at the routing plenary in Chicago). Anything that = already exists MUST (rfc2119 ;-)) be used provided that it meets our = requirements. And if we can adapt an existing protocol, we are all for = it !
-> Yes these requirements are quite specifics and this is = precisely why ROLL has been formed, 4 application-specific routing = requirements have been produced (to reduce the scope). Even if at a = first sight, it looks very much similar to a MANET issue (and there ARE = similarities but also very different requirements), having to deal with = a highly static network of hundreds of thousands of battery operated = sleeping nodes with 4K of RAM is quite specific. Note that this is not a = random example, but an on-going non-IP deployed = network.

And to conclude on this introduction = ... after an outstanding progress on the WG during the first 6-8 months, = we have been slowed down dramatically for the last 2 months, thus it is = time to close and move on to quickly re-charter and start the protocol = work (hopefully as light as possible) to see IP-based solution deployed. = I know that we are on the same page, we just need to find a good = compromise on both "sides".

Nothing new so far, = let's move to a proposed resolution - See in = line,

On Feb 2, 2009, at 7:37 PM, = Thomas Heide Clausen wrote:

All,

I promised a review, and I apologize that = I wasn't able to do so before the weekend as originally = projected.

Other than some typos that Chris and others have = pointed out, I'll try to offer my understanding of the problem space and = suggest some ways of addressing my main concerns....

My first = main concern remain that it is not clear, still, how ROLL positions = itself with respect to MANET, 6LOW et. al, all of which appear to be = within the same space and within the IETF. This I-D sees ROLL as = presented with entirely new problems (the use of "novel" in the = abstract, the statement that "existing protocols were not designed with = these requirements in mind" seem to confirm this).

Looking at the = =A0requirements listed, including "low power, low bandwidth, low = footprint", these appear similar to those which are also brought forward = in e.g. MANET and 6LOW. Reading (quickly, I confess) the various = requirements documents =A0of the draft-ietf-roll series present = scenarios which are similar to those where MANETs are deployed, and are = thought deployed, as well.

I also note that many additional (and = unstated) characteristics between ROLL and e.g. MANET are the same: = mobile, wireless, fragility, auto-configuration, IP routing, = interface/link issues...

Arguing that, as does this I-D, despite = the above impression "ROLL is novel and different" invites asking "how, = exactly?" I think that this question is valid, and merits being = answered, before the evaluations in this I-D can be judged = fairly.

Note that I come from a MANET background, and so I = *could* interpret from the ROLL discussion that where MANETs may aim for = "low power, low bandwidth, ....", ROLL may be able to quantify these as = "below this firm threshold" -- i.e. as a sort of "extreme" or = "constrained" MANET.

This is a personal observation, I note, = which would allow me to comprehend how ROLL and MANET are positioned = relative to one another -- but one which neither this I-D nor the = requirements document spell out or quantify -- or, for that matter, = debunk.

I think it's critical to understand this, in order to = understand the need for a new protocol development. I think it is = important to document this understanding in something with more = persistency.

If what I suggest above makes sense as a way of = positioning ROLL and MANET relative to one another, I'd suggest = including something to this effect in the survey I-D, as this I-D is the = one making a *direct* reference to the applicability of MANET protocols = to ROLL.

If what I suggest doesn't make sense at all, then I'd be = happy to have it debunked and, hopefully, through that debunking a = positioning/description that does ring true with us all can be = produced?

My second main concern is, that I still think that the = choice of criteria is unfortunate (not the word, Phill has me convinced = on that front, but the actual criteria). Control cost is, by all means, = a rather meaningless criteria when taken in isolation. I've sketched a = "zero-control-cost" routing protocol (flood all data - say use SMF, also = a MANET protocol, and also a rather "mature" I-D and wg item) which = would score well on the control cost criteria, but would likely be an = extremely bad choice for delivering unicast data.

The metric = which matters, and which should matter to ROLL in particular, is "the = total cost of getting user data through the network, including control = cost necessary to set up paths" -- as we know, every packet sent and = received costs bandwidth, energy and cycles -- user data no different = from contro.

According to the criterions as set up by this I-D, a = protocol producing "longer than shortest paths" at the benefit of = slightly lower control cost would score better than a protocol producing = "shortest paths" with slightly higher control cost. This is not = hypothetical, btw., there are plenty of studies observing and reflecting = upon this regarding the different MANET protocols, in academic = literature -- and observed in real networks as well.

I note that = this trade-off (slightly longer paths for lower control cost) may be = perfectly fair, assuming that very low amounts of user data traffic = transit through the network. However, I do not see this assumption = mentioned as a justification for focusing on the control cost metric and = discarding the "path length" or the "total cost of getting user data = through the network".

I believe that either these assumptions = should be made explicit ("there's so little user data traffic in a ROLL = network that we do not care about shortest paths") or -- if these = assumptions do not hold, that the evaluation criteria are = incomplete.

I note that it's true that we can always add another = criteria ad infinitum, and that's CLEARLY not what we want to do. = However when I say "incomplete" in the above, I simply suggest that = based on what is presented one cannot draw conclusions based on the = evaluation criteria....or, worse, that one draws the wrong conclusions = based on the information = presented.

It is not easy to = answer each of your point without running the risk to start a debate = that will never end. You raised some excellent points that I agree with = and others that I firmly disagree with ... So let me try to make a few = observations:
1) As pointed out earlier, yes there are = similarities between MANET and ROLL. I do not see this as an = issue.
2) The aim of the protocol survey IS NOT to exclude = MANET protocols. As mentioned many times on the list, we *only* wanted = to show that existing protocols, with no change, could not be used in = LLNs. This has been clarified in the document as your request and it HAD = to be clarified.
3) We could have used two different = approaches for the survey:
- Look at all MUST from the = requirements documents
- Try to derive a subset of = necessary but not sufficient criteria, which the WG chose to do = (consensus). Yes this list is not perfect,
criteria = could be changed, removed or added but looked good enough with excellent = consensus until LC.
4) With regards to 6lowpan (I copy the = chair), I do not see any overlap at all. Please refer to their charter = and WG items. The only place that required clarification was the routing = requirements and I was personally opposed to it but this was adopted as = a 6lowpan WG item by consensus. We're are working together and = managed to sort this out. This document will be 6lowpan = specific.

What I want to avoid is an endless = discussion on the positioning of ROLL, MANET, 6lowpan and quite frankly = we could add other WGs to the list.

So what = is the bottom line ?

We just need to agree = on the fact that there is no existing protocol that meets the ROLL = requirements and move to the next step (re-chartering) to select one = (hopefully not two) routing protocols in light of the routing = requirement (NOT the protocol survey), which can either be an adapted = MANET protocol or a new protocol.

Now moving to = your proposed resolution.



So, in a nutshell, I suggest that we address = (i) the positioning issue and (ii) the criteria issue thus:

o Describe = as I proposed above if ROLL and MANETs position themselves as I
have = deducted. If my deduction is incorrect, then let's quickly iterate on = the list
= = as to understand how to do produce an alternative description. If = we can't do this,
then the conclusion can be that = "we do not know how ROLL and MANET position
= themselves wrt each other", and we could then state that = clearly?
= =
= = It *should* not be more than a couple of paragraphs worth of text = to add, I gather?


If you find a = way to word this, please feel free and I'd be happy to help but feel it = as necessary ... Any opinion from our RTG and INT ADs = ?

o To the = criteria, either of:

- Add the assumption that "user = data traffic is so low that path lengths do not
matter = nor does the cost of carrying user data = traffice"


The motivation = for selecting a longer path is not tied to the amount of traffic here = but the level of constraints. Note that this is also true for several = other technologies such as MPLS-TE. You may have large amount of traffic = and still require to follow a non-shortest path (constrained based = routing). This is detailed in several requirements IDs. Criticality of = data is of course different, thus the requirements for potentially = different data paths according to packet marking using = DSCP.

- Add a = criteria & evaluation of "path length"

- Add a = criteria & evaluation of "total cost for getting user data through = the network"


And we can = add many more but if the current protocol do not satisfy existing = requirements, isn't it sufficient to answer the question on whether one = can find an=A0existing=A0protocol?

This would make a large chunk of my concerns and = issues vanish, and allow correctly interpreting and evaluating the rest = of the document.

That said, = question for the WG. Who think that such criteria should be added to = move forward ? Please reply.



How does that sound as an approach = forward?


Thanks for = helping = out.

Cheers.

JP.
Cheers,

Thomas

On Jan 27, = 2009, at 1:00 AM, Internet-Drafts@ietf.org = wrote:

A New Internet-Draft is = available from the on-line Internet-Drafts
directories.
This = draft is a work item of the Routing Over Low power and Lossy networks = Working Group of the IETF.

= Title = = : Overview of Existing Routing Protocols for Low Power and Lossy = Networks
= Author(s) = : A. Tavakoli, S. Dawson-Haggerty, P. = Levis
= Filename = : = draft-ietf-roll-protocols-survey-05.txt
= Pages = = : 26
Date : = 2009-1-26
=
Networks of low power = wireless devices introduce novel IP routing
=A0=A0issues. =A0Low-power wireless devices, such as = sensors, actuators and
= =A0=A0smart objects, have difficult constraints: very limited = memory,
=A0=A0little = processing power, and long sleep periods. =A0As most of = these
=A0=A0devices are = battery-powered, energy efficiency is = critically
=A0=A0important. = =A0Wireless link qualities can vary significantly over = time,
=A0=A0requiring = protocols to make agile decisions yet minimize = topology
=A0=A0change energy = costs. =A0Routing over such low power and lossy = networks
=A0=A0has novel = requirements that existing protocols may not address. = =A0This
=A0=A0document = provides a brief survey of the strengths and weaknesses = of
=A0=A0existing protocols = with respect to this class of networks. =A0=46rom = this
=A0=A0survey it examines = whether existing and mature IETF protocols can = be
=A0=A0used without = modification in these networks, or whether further = work
=A0=A0is = necessary.
=A0=A0is = necessary.

A URL for this = Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-s= urvey-05.txt

Internet-Drafts = are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-d= rafts/

Below is the = data which will enable a MIME compliant mail = reader
implementation to = automatically retrieve the ASCII version of = the
Internet-Draft.
Content-Type: text/plain
Content-ID: <2009-1-26155804.I-D@ietf.org<= /a>>

_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

_____________________________= __________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll


= --Apple-Mail-6--190601037-- --===============0433484121== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0433484121==-- From roll-bounces@ietf.org Tue Feb 3 05:40:50 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B33D728C138; Tue, 3 Feb 2009 05:40:50 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E32E828C138 for ; Tue, 3 Feb 2009 05:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdYGE1yDMLUa for ; Tue, 3 Feb 2009 05:40:47 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 564E128C0DF for ; Tue, 3 Feb 2009 05:40:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,372,1231113600"; d="scan'208,217";a="32702724" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2009 13:40:25 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n13DePl6025886; Tue, 3 Feb 2009 14:40:25 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n13DeP33001029; Tue, 3 Feb 2009 13:40:25 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 14:40:24 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 14:40:23 +0100 Message-Id: From: JP Vasseur To: Thomas Heide Clausen In-Reply-To: Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Feb 2009 14:40:22 +0100 References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Feb 2009 13:40:23.0939 (UTC) FILETIME=[F70A0530:01C98604] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=42587; t=1233668425; x=1234532425; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20*=20ALL=20PLEASE=20READ=20**=2 0TIME=20FOR=20CLOSURE=20?=20Re=3A=20Review=20and=20comments= 20draft-ietf-roll-protocols-survey-05.txt |Sender:=20; bh=fPIJvYpbEhBghKzO9N0FQud9HZdZM7KTx+zOIRbd1wc=; b=ePK+uKVFJCDJZZbLOgk03FQx+B6ELh9HqQ1R39F8nW0D79ywlR2uY/G9+/ 0ErmBPeOElFlxNZZcv3sTCwPiLxvX7VvuzaWgXVCX3e3HvO8wc/JyQpIRsHk FQGuMQay0f; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Ross Callon , ROLL WG , jari.arkko@piuha.net Subject: Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review and comments draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1158996937==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1158996937== Content-Type: multipart/alternative; boundary=Apple-Mail-106--189331382 --Apple-Mail-106--189331382 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Thomas, On Feb 3, 2009, at 2:19 PM, Thomas Heide Clausen wrote: > Dear JP, dear ADs, dear WG, > > For the record, I am not arguing that MANET protocols should be > applied or be applicable -- as you seem to suggest in your email. I > believe that I have stated so repeatedly. > > I submit, however, that as it is currently exposed, ROLL, MANET and > 6LOW seem to be operating within the same space -- to the untrained > eye, in exactly the same space. We sort of operating in the same space, which is fine as long as we do *not* duplicate the work, do *not* overlap, do *not* reinvent the wheel. I think that we are on the same page. > My position is that it would be very unfortunate having one WG > creating confusion on the applicability of the work of itself and of > other IETF wg's, by simple omission of suitable perimeter definitions. > Quite frankly I do not see any confusion. * 6lowpan has a clear charter - no overlap with ROLL and we work well together * MANET works on several well defined protocols * ROLL has also a clear charter with a narrow scope: routing for LLN for which we have defined detailed requirements. Our next step is to have a routing protocol for LLN according to the requirements, which may or may not be a MANET protocol. I do not see any confusion. > In that sort of situation, the IETF needs to be extra prudent to > make sure to clearly spell out suitable perimeter definitions prior > to, or conjointly with, the first publication cycle. In this case, > before or with the survey I-D. > Are we back in sync ? Thanks. JP. > Sincerely, > > Thomas > > > On Feb 3, 2009, at 1:19 PM, JP Vasseur wrote: > >> Dear WG and ADs, >> >> Two issues are raised here for which we would appreciate ADs' point >> of view and feed-back from the WG. Please see in line. >> >> >> Dear Thomas, >> >> At the risk of repeating myself, I'd like to make a few important >> statements before *hopefully* come to a closure ;-) >> >> -> As you know, many of the ROLL WG active participants have been >> working quite hard to produce a detailed set of requirements, >> discuss how to proceed on the protocol survey document, and other >> ID are in the works. >> -> We managed to get highly experienced contributors in the field >> that have designed and deployed solutions so they not only have an >> excellent expertise of the requirements but also on solutions, >> -> Yes we need to rush out. Why ? Because proprietary or semi- >> closed non-IP solutions are being deployed at a fairly large scale. >> I do not think that I have to convince anybody on this list that >> this is the WRONG approach for a number of reasons. The industry is >> asking for an IP solution *now*. >> -> No we do not want to re-invent the wheel (see our presentation >> at the routing plenary in Chicago). Anything that already exists >> MUST (rfc2119 ;-)) be used provided that it meets our requirements. >> And if we can adapt an existing protocol, we are all for it ! >> -> Yes these requirements are quite specifics and this is precisely >> why ROLL has been formed, 4 application-specific routing >> requirements have been produced (to reduce the scope). Even if at a >> first sight, it looks very much similar to a MANET issue (and there >> ARE similarities but also very different requirements), having to >> deal with a highly static network of hundreds of thousands of >> battery operated sleeping nodes with 4K of RAM is quite specific. >> Note that this is not a random example, but an on-going non-IP >> deployed network. >> >> And to conclude on this introduction ... after an outstanding >> progress on the WG during the first 6-8 months, we have been slowed >> down dramatically for the last 2 months, thus it is time to close >> and move on to quickly re-charter and start the protocol work >> (hopefully as light as possible) to see IP-based solution deployed. >> I know that we are on the same page, we just need to find a good >> compromise on both "sides". >> >> Nothing new so far, let's move to a proposed resolution - See in >> line, >> >> On Feb 2, 2009, at 7:37 PM, Thomas Heide Clausen wrote: >> >>> All, >>> >>> I promised a review, and I apologize that I wasn't able to do so >>> before the weekend as originally projected. >>> >>> Other than some typos that Chris and others have pointed out, I'll >>> try to offer my understanding of the problem space and suggest >>> some ways of addressing my main concerns.... >>> >>> My first main concern remain that it is not clear, still, how ROLL >>> positions itself with respect to MANET, 6LOW et. al, all of which >>> appear to be within the same space and within the IETF. This I-D >>> sees ROLL as presented with entirely new problems (the use of >>> "novel" in the abstract, the statement that "existing protocols >>> were not designed with these requirements in mind" seem to confirm >>> this). >>> >>> Looking at the requirements listed, including "low power, low >>> bandwidth, low footprint", these appear similar to those which are >>> also brought forward in e.g. MANET and 6LOW. Reading (quickly, I >>> confess) the various requirements documents of the draft-ietf- >>> roll series present scenarios which are similar to those where >>> MANETs are deployed, and are thought deployed, as well. >>> >>> I also note that many additional (and unstated) characteristics >>> between ROLL and e.g. MANET are the same: mobile, wireless, >>> fragility, auto-configuration, IP routing, interface/link issues... >>> >>> Arguing that, as does this I-D, despite the above impression "ROLL >>> is novel and different" invites asking "how, exactly?" I think >>> that this question is valid, and merits being answered, before the >>> evaluations in this I-D can be judged fairly. >>> >>> Note that I come from a MANET background, and so I *could* >>> interpret from the ROLL discussion that where MANETs may aim for >>> "low power, low bandwidth, ....", ROLL may be able to quantify >>> these as "below this firm threshold" -- i.e. as a sort of >>> "extreme" or "constrained" MANET. >>> >>> This is a personal observation, I note, which would allow me to >>> comprehend how ROLL and MANET are positioned relative to one >>> another -- but one which neither this I-D nor the requirements >>> document spell out or quantify -- or, for that matter, debunk. >>> >>> I think it's critical to understand this, in order to understand >>> the need for a new protocol development. I think it is important >>> to document this understanding in something with more persistency. >>> >>> If what I suggest above makes sense as a way of positioning ROLL >>> and MANET relative to one another, I'd suggest including something >>> to this effect in the survey I-D, as this I-D is the one making a >>> *direct* reference to the applicability of MANET protocols to ROLL. >>> >>> If what I suggest doesn't make sense at all, then I'd be happy to >>> have it debunked and, hopefully, through that debunking a >>> positioning/description that does ring true with us all can be >>> produced? >>> >>> My second main concern is, that I still think that the choice of >>> criteria is unfortunate (not the word, Phill has me convinced on >>> that front, but the actual criteria). Control cost is, by all >>> means, a rather meaningless criteria when taken in isolation. I've >>> sketched a "zero-control-cost" routing protocol (flood all data - >>> say use SMF, also a MANET protocol, and also a rather "mature" I-D >>> and wg item) which would score well on the control cost criteria, >>> but would likely be an extremely bad choice for delivering unicast >>> data. >>> >>> The metric which matters, and which should matter to ROLL in >>> particular, is "the total cost of getting user data through the >>> network, including control cost necessary to set up paths" -- as >>> we know, every packet sent and received costs bandwidth, energy >>> and cycles -- user data no different from contro. >>> >>> According to the criterions as set up by this I-D, a protocol >>> producing "longer than shortest paths" at the benefit of slightly >>> lower control cost would score better than a protocol producing >>> "shortest paths" with slightly higher control cost. This is not >>> hypothetical, btw., there are plenty of studies observing and >>> reflecting upon this regarding the different MANET protocols, in >>> academic literature -- and observed in real networks as well. >>> >>> I note that this trade-off (slightly longer paths for lower >>> control cost) may be perfectly fair, assuming that very low >>> amounts of user data traffic transit through the network. However, >>> I do not see this assumption mentioned as a justification for >>> focusing on the control cost metric and discarding the "path >>> length" or the "total cost of getting user data through the >>> network". >>> >>> I believe that either these assumptions should be made explicit >>> ("there's so little user data traffic in a ROLL network that we do >>> not care about shortest paths") or -- if these assumptions do not >>> hold, that the evaluation criteria are incomplete. >>> >>> I note that it's true that we can always add another criteria ad >>> infinitum, and that's CLEARLY not what we want to do. However when >>> I say "incomplete" in the above, I simply suggest that based on >>> what is presented one cannot draw conclusions based on the >>> evaluation criteria....or, worse, that one draws the wrong >>> conclusions based on the information presented. >> >> It is not easy to answer each of your point without running the >> risk to start a debate that will never end. You raised some >> excellent points that I agree with and others that I firmly >> disagree with ... So let me try to make a few observations: >> 1) As pointed out earlier, yes there are similarities between MANET >> and ROLL. I do not see this as an issue. >> 2) The aim of the protocol survey IS NOT to exclude MANET >> protocols. As mentioned many times on the list, we *only* wanted to >> show that existing protocols, with no change, could not be used in >> LLNs. This has been clarified in the document as your request and >> it HAD to be clarified. >> 3) We could have used two different approaches for the survey: >> - Look at all MUST from the requirements documents >> - Try to derive a subset of necessary but not sufficient criteria, >> which the WG chose to do (consensus). Yes this list is not perfect, >> criteria could be changed, removed or added but looked good enough >> with excellent consensus until LC. >> 4) With regards to 6lowpan (I copy the chair), I do not see any >> overlap at all. Please refer to their charter and WG items. The >> only place that required clarification was the routing requirements >> and I was personally opposed to it but this was adopted as a >> 6lowpan WG item by consensus. We're are working together and >> managed to sort this out. This document will be 6lowpan specific. >> >> What I want to avoid is an endless discussion on the positioning of >> ROLL, MANET, 6lowpan and quite frankly we could add other WGs to >> the list. >> >> So what is the bottom line ? >> >> We just need to agree on the fact that there is no existing >> protocol that meets the ROLL requirements and move to the next step >> (re-chartering) to select one (hopefully not two) routing protocols >> in light of the routing requirement (NOT the protocol survey), >> which can either be an adapted MANET protocol or a new protocol. >> >> Now moving to your proposed resolution. >> >>> >>> >>> So, in a nutshell, I suggest that we address (i) the positioning >>> issue and (ii) the criteria issue thus: >>> >>> o Describe as I proposed above if ROLL and MANETs position >>> themselves as I >>> have deducted. If my deduction is incorrect, then let's quickly >>> iterate on the list >>> as to understand how to do produce an alternative description. >>> If we can't do this, >>> then the conclusion can be that "we do not know how ROLL and >>> MANET position >>> themselves wrt each other", and we could then state that clearly? >>> >>> It *should* not be more than a couple of paragraphs worth of >>> text to add, I gather? >>> >> >> If you find a way to word this, please feel free and I'd be happy >> to help but feel it as necessary ... Any opinion from our RTG and >> INT ADs ? >> >>> o To the criteria, either of: >>> >>> - Add the assumption that "user data traffic is so low that >>> path lengths do not >>> matter nor does the cost of carrying user data traffice" >>> >> >> The motivation for selecting a longer path is not tied to the >> amount of traffic here but the level of constraints. Note that this >> is also true for several other technologies such as MPLS-TE. You >> may have large amount of traffic and still require to follow a non- >> shortest path (constrained based routing). This is detailed in >> several requirements IDs. Criticality of data is of course >> different, thus the requirements for potentially different data >> paths according to packet marking using DSCP. >> >>> - Add a criteria & evaluation of "path length" >>> >>> - Add a criteria & evaluation of "total cost for getting user >>> data through the network" >>> >> >> And we can add many more but if the current protocol do not satisfy >> existing requirements, isn't it sufficient to answer the question >> on whether one can find an existing protocol? >> >>> This would make a large chunk of my concerns and issues vanish, >>> and allow correctly interpreting and evaluating the rest of the >>> document. >> >> That said, question for the WG. Who think that such criteria should >> be added to move forward ? Please reply. >> >>> >>> >>> How does that sound as an approach forward? >>> >> >> Thanks for helping out. >> >> Cheers. >> >> JP. >> >>> Cheers, >>> >>> Thomas >>> >>> On Jan 27, 2009, at 1:00 AM, Internet-Drafts@ietf.org wrote: >>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Routing Over Low power and Lossy >>>> networks Working Group of the IETF. >>>> >>>> Title : Overview of Existing Routing Protocols for Low Power >>>> and Lossy Networks >>>> Author(s) : A. Tavakoli, S. Dawson-Haggerty, P. Levis >>>> Filename : draft-ietf-roll-protocols-survey-05.txt >>>> Pages : 26 >>>> Date : 2009-1-26 >>>> >>>> Networks of low power wireless devices introduce novel IP routing >>>> issues. Low-power wireless devices, such as sensors, actuators >>>> and >>>> smart objects, have difficult constraints: very limited memory, >>>> little processing power, and long sleep periods. As most of >>>> these >>>> devices are battery-powered, energy efficiency is critically >>>> important. Wireless link qualities can vary significantly over >>>> time, >>>> requiring protocols to make agile decisions yet minimize topology >>>> change energy costs. Routing over such low power and lossy >>>> networks >>>> has novel requirements that existing protocols may not >>>> address. This >>>> document provides a brief survey of the strengths and >>>> weaknesses of >>>> existing protocols with respect to this class of networks. >>>> From this >>>> survey it examines whether existing and mature IETF protocols >>>> can be >>>> used without modification in these networks, or whether further >>>> work >>>> is necessary. >>>> is necessary. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-survey-05.txt >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>> Content-Type: text/plain >>>> Content-ID: <2009-1-26155804.I-D@ietf.org> >>>> >>>> _______________________________________________ >>>> 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 >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-106--189331382 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Thomas,

On = Feb 3, 2009, at 2:19 PM, Thomas Heide Clausen wrote:

Dear JP, dear ADs, dear = WG,

For the record, I am not arguing that MANET = protocols should be applied or be applicable -- as you seem to suggest = in your email. I believe that I have stated so = repeatedly.

I submit, = however, that as it is currently exposed, ROLL, MANET and 6LOW seem to = be operating within the same space -- to the untrained eye, in exactly = the same = space.

We sort = of operating in the same space, which is fine as long as we do *not* = duplicate the work, do *not* overlap, do *not* reinvent the wheel. I = think that we are on the same page.

 My position is that it would be very = unfortunate having one WG creating confusion on the applicability of the = work of itself and of other IETF wg's, by simple omission of suitable = perimeter definitions. 
In that sort of situation, the IETF needs to be = extra prudent to make sure to clearly spell out suitable perimeter = definitions prior to, or conjointly with, the first publication cycle. = In this case, before or with the survey I-D.
Sincerely,



On Feb 3, 2009, at 1:19 PM, JP = Vasseur wrote:

Dear WG and ADs,

Two issues = are raised here for which we would appreciate ADs' point of view and = feed-back from the WG. Please see in = line.


Dear = Thomas,

At the risk of repeating myself, I'd like to = make a few important statements before *hopefully* come to a closure = ;-)

-> As you know, many of the ROLL WG active = participants have been working quite hard to produce a detailed set of = requirements, discuss how to proceed on the protocol survey document, = and other ID are in the works.
-> We managed to get highly = experienced contributors in the field that have designed and = deployed solutions so they not only have an excellent expertise of the = requirements but also on solutions,
-> Yes we need to rush = out. Why ? Because proprietary or semi-closed non-IP solutions are being = deployed at a fairly large scale. I do not think that I have to convince = anybody on this list that this is the WRONG approach for a number of = reasons. The industry is asking for an IP solution = *now*.
-> No we do not want to re-invent the wheel (see = our presentation at the routing plenary in Chicago). Anything that = already exists MUST (rfc2119 ;-)) be used provided that it meets our = requirements. And if we can adapt an existing protocol, we are all for = it !
-> Yes these requirements are quite specifics and this is = precisely why ROLL has been formed, 4 application-specific routing = requirements have been produced (to reduce the scope). Even if at a = first sight, it looks very much similar to a MANET issue (and there ARE = similarities but also very different requirements), having to deal with = a highly static network of hundreds of thousands of battery operated = sleeping nodes with 4K of RAM is quite specific. Note that this is not a = random example, but an on-going non-IP deployed = network.

And to conclude on this introduction = ... after an outstanding progress on the WG during the first 6-8 months, = we have been slowed down dramatically for the last 2 months, thus it is = time to close and move on to quickly re-charter and start the protocol = work (hopefully as light as possible) to see IP-based solution deployed. = I know that we are on the same page, we just need to find a good = compromise on both "sides".

Nothing new so far, = let's move to a proposed resolution - See in = line,

On Feb 2, 2009, at 7:37 PM, = Thomas Heide Clausen wrote:

All,

I promised a review, and I apologize that = I wasn't able to do so before the weekend as originally = projected.

Other than some typos that Chris and others have = pointed out, I'll try to offer my understanding of the problem space and = suggest some ways of addressing my main concerns....

My first = main concern remain that it is not clear, still, how ROLL positions = itself with respect to MANET, 6LOW et. al, all of which appear to be = within the same space and within the IETF. This I-D sees ROLL as = presented with entirely new problems (the use of "novel" in the = abstract, the statement that "existing protocols were not designed with = these requirements in mind" seem to confirm this).

Looking at the =  requirements listed, including "low power, low bandwidth, low = footprint", these appear similar to those which are also brought forward = in e.g. MANET and 6LOW. Reading (quickly, I confess) the various = requirements documents  of the draft-ietf-roll series present = scenarios which are similar to those where MANETs are deployed, and are = thought deployed, as well.

I also note that many additional (and = unstated) characteristics between ROLL and e.g. MANET are the same: = mobile, wireless, fragility, auto-configuration, IP routing, = interface/link issues...

Arguing that, as does this I-D, despite = the above impression "ROLL is novel and different" invites asking "how, = exactly?" I think that this question is valid, and merits being = answered, before the evaluations in this I-D can be judged = fairly.

Note that I come from a MANET background, and so I = *could* interpret from the ROLL discussion that where MANETs may aim for = "low power, low bandwidth, ....", ROLL may be able to quantify these as = "below this firm threshold" -- i.e. as a sort of "extreme" or = "constrained" MANET.

This is a personal observation, I note, = which would allow me to comprehend how ROLL and MANET are positioned = relative to one another -- but one which neither this I-D nor the = requirements document spell out or quantify -- or, for that matter, = debunk.

I think it's critical to understand this, in order to = understand the need for a new protocol development. I think it is = important to document this understanding in something with more = persistency.

If what I suggest above makes sense as a way of = positioning ROLL and MANET relative to one another, I'd suggest = including something to this effect in the survey I-D, as this I-D is the = one making a *direct* reference to the applicability of MANET protocols = to ROLL.

If what I suggest doesn't make sense at all, then I'd be = happy to have it debunked and, hopefully, through that debunking a = positioning/description that does ring true with us all can be = produced?

My second main concern is, that I still think that the = choice of criteria is unfortunate (not the word, Phill has me convinced = on that front, but the actual criteria). Control cost is, by all means, = a rather meaningless criteria when taken in isolation. I've sketched a = "zero-control-cost" routing protocol (flood all data - say use SMF, also = a MANET protocol, and also a rather "mature" I-D and wg item) which = would score well on the control cost criteria, but would likely be an = extremely bad choice for delivering unicast data.

The metric = which matters, and which should matter to ROLL in particular, is "the = total cost of getting user data through the network, including control = cost necessary to set up paths" -- as we know, every packet sent and = received costs bandwidth, energy and cycles -- user data no different = from contro.

According to the criterions as set up by this I-D, a = protocol producing "longer than shortest paths" at the benefit of = slightly lower control cost would score better than a protocol producing = "shortest paths" with slightly higher control cost. This is not = hypothetical, btw., there are plenty of studies observing and reflecting = upon this regarding the different MANET protocols, in academic = literature -- and observed in real networks as well.

I note that = this trade-off (slightly longer paths for lower control cost) may be = perfectly fair, assuming that very low amounts of user data traffic = transit through the network. However, I do not see this assumption = mentioned as a justification for focusing on the control cost metric and = discarding the "path length" or the "total cost of getting user data = through the network".

I believe that either these assumptions = should be made explicit ("there's so little user data traffic in a ROLL = network that we do not care about shortest paths") or -- if these = assumptions do not hold, that the evaluation criteria are = incomplete.

I note that it's true that we can always add another = criteria ad infinitum, and that's CLEARLY not what we want to do. = However when I say "incomplete" in the above, I simply suggest that = based on what is presented one cannot draw conclusions based on the = evaluation criteria....or, worse, that one draws the wrong conclusions = based on the information = presented.

It is not easy to = answer each of your point without running the risk to start a debate = that will never end. You raised some excellent points that I agree with = and others that I firmly disagree with ... So let me try to make a few = observations:
1) As pointed out earlier, yes there are = similarities between MANET and ROLL. I do not see this as an = issue.
2) The aim of the protocol survey IS NOT to exclude = MANET protocols. As mentioned many times on the list, we *only* wanted = to show that existing protocols, with no change, could not be used in = LLNs. This has been clarified in the document as your request and it HAD = to be clarified.
3) We could have used two different = approaches for the survey:
- Look at all MUST from the = requirements documents
- Try to derive a subset of = necessary but not sufficient criteria, which the WG chose to do = (consensus). Yes this list is not perfect,
criteria = could be changed, removed or added but looked good enough with excellent = consensus until LC.
4) With regards to 6lowpan (I copy the = chair), I do not see any overlap at all. Please refer to their charter = and WG items. The only place that required clarification was the routing = requirements and I was personally opposed to it but this was adopted as = a 6lowpan WG item by consensus. We're are working together and = managed to sort this out. This document will be 6lowpan = specific.

What I want to avoid is an endless = discussion on the positioning of ROLL, MANET, 6lowpan and quite frankly = we could add other WGs to the list.

So what = is the bottom line ?

We just need to agree = on the fact that there is no existing protocol that meets the ROLL = requirements and move to the next step (re-chartering) to select one = (hopefully not two) routing protocols in light of the routing = requirement (NOT the protocol survey), which can either be an adapted = MANET protocol or a new protocol.

Now moving to = your proposed resolution.



So, in a nutshell, I suggest that we address = (i) the positioning issue and (ii) the criteria issue thus:

o Describe = as I proposed above if ROLL and MANETs position themselves as I
have = deducted. If my deduction is incorrect, then let's quickly iterate on = the list
= = as to understand how to do produce an alternative description. If = we can't do this,
then the conclusion can be that = "we do not know how ROLL and MANET position
= themselves wrt each other", and we could then state that = clearly?
= =
= = It *should* not be more than a couple of paragraphs worth of text = to add, I gather?


If you find a = way to word this, please feel free and I'd be happy to help but feel it = as necessary ... Any opinion from our RTG and INT ADs = ?

o To the = criteria, either of:

- Add the assumption that "user = data traffic is so low that path lengths do not
matter = nor does the cost of carrying user data = traffice"


The motivation = for selecting a longer path is not tied to the amount of traffic here = but the level of constraints. Note that this is also true for several = other technologies such as MPLS-TE. You may have large amount of traffic = and still require to follow a non-shortest path (constrained based = routing). This is detailed in several requirements IDs. Criticality of = data is of course different, thus the requirements for potentially = different data paths according to packet marking using = DSCP.

- Add a = criteria & evaluation of "path length"

- Add a = criteria & evaluation of "total cost for getting user data through = the network"


And we can = add many more but if the current protocol do not satisfy existing = requirements, isn't it sufficient to answer the question on whether one = can find an existing protocol?

This would make a large chunk of my concerns and = issues vanish, and allow correctly interpreting and evaluating the rest = of the document.

That said, = question for the WG. Who think that such criteria should be added to = move forward ? Please reply.



How does that sound as an approach = forward?


Thanks for = helping = out.

Cheers.

JP.
Cheers,

Thomas

On Jan 27, = 2009, at 1:00 AM, Internet-Drafts@ietf.org = wrote:

A New Internet-Draft is = available from the on-line Internet-Drafts
directories.
This = draft is a work item of the Routing Over Low power and Lossy networks = Working Group of the IETF.

= Title = = : Overview of Existing Routing Protocols for Low Power and Lossy = Networks
= Author(s) = : A. Tavakoli, S. Dawson-Haggerty, P. = Levis
= Filename = : = draft-ietf-roll-protocols-survey-05.txt
= Pages = = : 26
Date : = 2009-1-26
=
Networks of low power = wireless devices introduce novel IP routing
  issues.  Low-power wireless devices, = such as sensors, actuators and
=   smart objects, have difficult constraints: very limited = memory,
  little = processing power, and long sleep periods.  As most of = these
  devices are = battery-powered, energy efficiency is = critically
=   important.  Wireless link qualities can vary = significantly over time,
=   requiring protocols to make agile decisions yet minimize = topology
  change = energy costs.  Routing over such low power and lossy = networks
  has = novel requirements that existing protocols may not address. =  This
=   document provides a brief survey of the strengths and = weaknesses of
=   existing protocols with respect to this class of networks. =  =46rom this
=   survey it examines whether existing and mature IETF = protocols can be
=   used without modification in these networks, or whether = further work
  is = necessary.
  is = necessary.

A URL for this = Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-s= urvey-05.txt

Internet-Drafts = are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-d= rafts/

Below is the = data which will enable a MIME compliant mail = reader
implementation to = automatically retrieve the ASCII version of = the
Internet-Draft.
Content-Type: text/plain
Content-ID: <2009-1-26155804.I-D@ietf.org<= /a>>

_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

_____________________________= __________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll


_______________________________________________Roll mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-106--189331382-- --===============1158996937== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1158996937==-- From roll-bounces@ietf.org Tue Feb 3 06:11:57 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB93628C19A; Tue, 3 Feb 2009 06:11:57 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 445A728C12C for ; Tue, 3 Feb 2009 06:11:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1F6QPFIQp8nV for ; Tue, 3 Feb 2009 06:11:52 -0800 (PST) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.190]) by core3.amsl.com (Postfix) with ESMTP id C3B9628C1A3 for ; Tue, 3 Feb 2009 06:11:48 -0800 (PST) Received: by mu-out-0910.google.com with SMTP id w9so25794mue.9 for ; Tue, 03 Feb 2009 06:11:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=++J80cFmKQRbGGKGFCNmuJTmxNR9wCDjhUhjo0F5d20=; b=Q0vdxVBBYAnS+PcVRqe5+zfPLvmNQS+GFhN/DSiQCxS6A8M2yGNoRu7qFPMPRShbM3 pL0cfv0yeKTd6tQ7YvVF/VUH8QXB9U47613RLBEYirIHV2XHf2UTwUW1HlMsfltulKuR cYVQJ1NzhgKQXLlqmXel3gjiSXiKpi+olYx9I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=paoUnjH2/zeYng40aCFguq25zWrSt1cptTsXIqSfUitQ+O/tiLPNX5AXlqaCZSgBuA thKROn+P7rz/zdxnNy24VsDFoj/uftEFtczm9VIbN870xq8bGtrdmv8EfV20Hcncwlpc NqodYqlEl4NstxLoePC4rjGB5IzWolvF4auY8= MIME-Version: 1.0 Received: by 10.103.238.4 with SMTP id p4mr2439949mur.68.1233670287201; Tue, 03 Feb 2009 06:11:27 -0800 (PST) In-Reply-To: References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> Date: Tue, 3 Feb 2009 15:11:27 +0100 X-Google-Sender-Auth: b0167a4a0c209461 Message-ID: From: Emmanuel Baccelli To: ROLL WG Subject: Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review and comments draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1539945296==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1539945296== Content-Type: multipart/alternative; boundary=0016369fa3e03d163c0462043ffb --0016369fa3e03d163c0462043ffb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all, I have remained silent since others have been echoing the concerns I had pointed out earlier, about the survey document. I want nevertheless to reinforce Thomas' point of view now, since I think it is insightful and useful in order to move on constructively. Basically, everybody agrees that something special must be done for sensor ad hoc connectivity with IP, and everybody wants to reach the next phase ASAP (i.e. work on solutions). However, the lack of consensus on the precise space addressed by ROLL is backlashing lately, with the survey document. The blur indeed had a huge impact on the document so far, forcing the use of a too broad set of goals and evaluation criterias, and endless discussions about the scope of the survey. This lack of definition will continue to plague ROLL and the other WGs in the same field down the line if it is not addressed upfront, i.e. now. I thus also encourage everyone to participate in this urgent and needed effort. If the scope of the WG is clearly defined, it should be straightforward to write a couple of paragraphs that will get us out of this mess. So let's just do it! Cheers Emmanuel On Tue, Feb 3, 2009 at 2:19 PM, Thomas Heide Clausen wrote: > Dear JP, dear ADs, dear WG, > For the record, I am not arguing that MANET protocols should be applied or > be applicable -- as you seem to suggest in your email. I believe that I have > stated so repeatedly. > > I submit, however, that as it is currently exposed, ROLL, MANET and 6LOW > seem to be operating within the same space -- to the untrained eye, in > exactly the same space. My position is that it would be very unfortunate > having one WG creating confusion on the applicability of the work of itself > and of other IETF wg's, by simple omission of suitable perimeter > definitions. > > In that sort of situation, the IETF needs to be extra prudent to make sure > to clearly spell out suitable perimeter definitions prior to, or conjointly > with, the first publication cycle. In this case, before or with the survey > I-D. > > Sincerely, > > Thomas > > > On Feb 3, 2009, at 1:19 PM, JP Vasseur wrote: > > Dear WG and ADs, > > Two issues are raised here for which we would appreciate ADs' point of view > and feed-back from the WG. Please see in line. > > > Dear Thomas, > At the risk of repeating myself, I'd like to make a few important > statements before *hopefully* come to a closure ;-) > > -> As you know, many of the ROLL WG active participants have been working > quite hard to produce a detailed set of requirements, discuss how to proceed > on the protocol survey document, and other ID are in the works. > -> We managed to get highly experienced contributors in the field that > have designed and deployed solutions so they not only have an excellent > expertise of the requirements but also on solutions, > *-> Yes we need to rush out. Why ? Because proprietary or semi-closed > non-IP solutions are being deployed at a fairly large scale. I do not think > that I have to convince anybody on this list that this is the WRONG approach > for a number of reasons. The industry is asking for an IP solution *now*.* > -> No we do not want to re-invent the wheel (see our presentation at the > routing plenary in Chicago). Anything that already exists MUST (rfc2119 ;-)) > be used provided that it meets our requirements. And if we can adapt an > existing protocol, we are all for it ! > -> Yes these requirements are quite specifics and this is precisely why > ROLL has been formed, 4 application-specific routing requirements have been > produced (to reduce the scope). Even if at a first sight, it looks very much > similar to a MANET issue (and there ARE similarities but also very different > requirements), having to deal with a highly static network of hundreds of > thousands of battery operated sleeping nodes with 4K of RAM is quite > specific. Note that this is not a random example, but an on-going non-IP > deployed network. > > And to conclude on this introduction ... after an outstanding progress on > the WG during the first 6-8 months, we have been slowed down dramatically > for the last 2 months, thus it is time to close and move on to quickly > re-charter and start the protocol work (hopefully as light as possible) to > see IP-based solution deployed. I know that we are on the same page, we just > need to find a good compromise on both "sides". > > Nothing new so far, let's move to a proposed resolution - See in line, > > On Feb 2, 2009, at 7:37 PM, Thomas Heide Clausen wrote: > > All, > > I promised a review, and I apologize that I wasn't able to do so before the > weekend as originally projected. > > Other than some typos that Chris and others have pointed out, I'll try to > offer my understanding of the problem space and suggest some ways of > addressing my main concerns.... > > My first main concern remain that it is not clear, still, how ROLL > positions itself with respect to MANET, 6LOW et. al, all of which appear to > be within the same space and within the IETF. This I-D sees ROLL as > presented with entirely new problems (the use of "novel" in the abstract, > the statement that "existing protocols were not designed with these > requirements in mind" seem to confirm this). > > Looking at the requirements listed, including "low power, low bandwidth, > low footprint", these appear similar to those which are also brought forward > in e.g. MANET and 6LOW. Reading (quickly, I confess) the various > requirements documents of the draft-ietf-roll series present scenarios > which are similar to those where MANETs are deployed, and are thought > deployed, as well. > > I also note that many additional (and unstated) characteristics between > ROLL and e.g. MANET are the same: mobile, wireless, fragility, > auto-configuration, IP routing, interface/link issues... > > Arguing that, as does this I-D, despite the above impression "ROLL is novel > and different" invites asking "how, exactly?" I think that this question is > valid, and merits being answered, before the evaluations in this I-D can be > judged fairly. > > Note that I come from a MANET background, and so I *could* interpret from > the ROLL discussion that where MANETs may aim for "low power, low bandwidth, > ....", ROLL may be able to quantify these as "below this firm threshold" -- > i.e. as a sort of "extreme" or "constrained" MANET. > > This is a personal observation, I note, which would allow me to comprehend > how ROLL and MANET are positioned relative to one another -- but one which > neither this I-D nor the requirements document spell out or quantify -- or, > for that matter, debunk. > > I think it's critical to understand this, in order to understand the need > for a new protocol development. I think it is important to document this > understanding in something with more persistency. > > If what I suggest above makes sense as a way of positioning ROLL and MANET > relative to one another, I'd suggest including something to this effect in > the survey I-D, as this I-D is the one making a *direct* reference to the > applicability of MANET protocols to ROLL. > > If what I suggest doesn't make sense at all, then I'd be happy to have it > debunked and, hopefully, through that debunking a positioning/description > that does ring true with us all can be produced? > > My second main concern is, that I still think that the choice of criteria > is unfortunate (not the word, Phill has me convinced on that front, but the > actual criteria). Control cost is, by all means, a rather meaningless > criteria when taken in isolation. I've sketched a "zero-control-cost" > routing protocol (flood all data - say use SMF, also a MANET protocol, and > also a rather "mature" I-D and wg item) which would score well on the > control cost criteria, but would likely be an extremely bad choice for > delivering unicast data. > > The metric which matters, and which should matter to ROLL in particular, is > "the total cost of getting user data through the network, including control > cost necessary to set up paths" -- as we know, every packet sent and > received costs bandwidth, energy and cycles -- user data no different from > contro. > > According to the criterions as set up by this I-D, a protocol producing > "longer than shortest paths" at the benefit of slightly lower control cost > would score better than a protocol producing "shortest paths" with slightly > higher control cost. This is not hypothetical, btw., there are plenty of > studies observing and reflecting upon this regarding the different MANET > protocols, in academic literature -- and observed in real networks as well. > > I note that this trade-off (slightly longer paths for lower control cost) > may be perfectly fair, assuming that very low amounts of user data traffic > transit through the network. However, I do not see this assumption mentioned > as a justification for focusing on the control cost metric and discarding > the "path length" or the "total cost of getting user data through the > network". > > I believe that either these assumptions should be made explicit ("there's > so little user data traffic in a ROLL network that we do not care about > shortest paths") or -- if these assumptions do not hold, that the evaluation > criteria are incomplete. > > I note that it's true that we can always add another criteria ad infinitum, > and that's CLEARLY not what we want to do. However when I say "incomplete" > in the above, I simply suggest that based on what is presented one cannot > draw conclusions based on the evaluation criteria....or, worse, that one > draws the wrong conclusions based on the information presented. > > > It is not easy to answer each of your point without running the risk to > start a debate that will never end. You raised some excellent points that I > agree with and others that I firmly disagree with ... So let me try to make > a few observations: > 1) As pointed out earlier, yes there are similarities between MANET and > ROLL. I do not see this as an issue. > 2) The aim of the protocol survey IS NOT to exclude MANET protocols. As > mentioned many times on the list, we *only* wanted to show that existing > protocols, with no change, could not be used in LLNs. This has been > clarified in the document as your request and it HAD to be clarified. > 3) We could have used two different approaches for the survey: > - Look at all MUST from the requirements documents > - Try to derive a subset of necessary but not sufficient criteria, which > the WG chose to do (consensus). Yes this list is not perfect, > criteria could be changed, removed or added but looked good enough with > excellent consensus until LC. > 4) With regards to 6lowpan (I copy the chair), I do not see any overlap at > all. Please refer to their charter and WG items. The only place that > required clarification was the routing requirements and I was personally > opposed to it but this was adopted as a 6lowpan WG item *by consensus*. > We're are working together and managed to sort this out. This document will > be 6lowpan specific. > > What I want to avoid is an endless discussion on the positioning of ROLL, > MANET, 6lowpan and quite frankly we could add other WGs to the list. > > *So what is the bottom line ?* > > We just need to agree on the fact that there is no existing protocol that > meets the ROLL requirements and move to the next step (re-chartering) to > select one (hopefully not two) routing protocols in light of the routing > requirement (NOT the protocol survey), which can either be an adapted MANET > protocol or a new protocol. > > Now moving to your proposed resolution. > > > > So, in a nutshell, I suggest that we address (i) the positioning issue and > (ii) the criteria issue thus: > > o Describe as I proposed above if ROLL and MANETs position themselves as I > have deducted. If my deduction is incorrect, then let's quickly iterate > on the list > as to understand how to do produce an alternative description. If we > can't do this, > then the conclusion can be that "we do not know how ROLL and MANET > position > themselves wrt each other", and we could then state that clearly? > > It *should* not be more than a couple of paragraphs worth of text to add, > I gather? > > > If you find a way to word this, please feel free and I'd be happy to help > but feel it as necessary ... Any opinion from our RTG and INT ADs ? > > o To the criteria, either of: > > - Add the assumption that "user data traffic is so low that path lengths > do not > matter nor does the cost of carrying user data traffice" > > > The motivation for selecting a longer path is not tied to the amount of > traffic here but the level of constraints. Note that this is also true for > several other technologies such as MPLS-TE. You may have large amount of > traffic and still require to follow a non-shortest path (constrained based > routing). This is detailed in several requirements IDs. Criticality of data > is of course different, thus the requirements for potentially different data > paths according to packet marking using DSCP. > > - Add a criteria & evaluation of "path length" > > - Add a criteria & evaluation of "total cost for getting user data > through the network" > > > And we can add many more but if the current protocol do not satisfy > existing requirements, isn't it sufficient to answer the question on whether > one can find an existing protocol? > > This would make a large chunk of my concerns and issues vanish, and allow > correctly interpreting and evaluating the rest of the document. > > > That said, question for the WG. Who think that such criteria should be > added to move forward ? Please reply. > > > > How does that sound as an approach forward? > > > Thanks for helping out. > > Cheers. > > JP. > > Cheers, > > Thomas > > On Jan 27, 2009, at 1:00 AM, Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Routing Over Low power and Lossy networks > Working Group of the IETF. > > > Title : Overview of Existing Routing Protocols for Low Power and Lossy > Networks > > Author(s) : A. Tavakoli, S. Dawson-Haggerty, P. Levis > > Filename : draft-ietf-roll-protocols-survey-05.txt > > Pages : 26 > > Date : 2009-1-26 > > > Networks of low power wireless devices introduce novel IP routing > > issues. Low-power wireless devices, such as sensors, actuators and > > smart objects, have difficult constraints: very limited memory, > > little processing power, and long sleep periods. As most of these > > devices are battery-powered, energy efficiency is critically > > important. Wireless link qualities can vary significantly over time, > > requiring protocols to make agile decisions yet minimize topology > > change energy costs. Routing over such low power and lossy networks > > has novel requirements that existing protocols may not address. This > > document provides a brief survey of the strengths and weaknesses of > > existing protocols with respect to this class of networks. From this > > survey it examines whether existing and mature IETF protocols can be > > used without modification in these networks, or whether further work > > is necessary. > > is necessary. > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-survey-05.txt > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > Content-Type: text/plain > > Content-ID: <2009-1-26155804.I-D@ietf.org> > > > _______________________________________________ > > 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 > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > On Tue, Feb 3, 2009 at 2:19 PM, Thomas Heide Clausen wrote: > Dear JP, dear ADs, dear WG, > For the record, I am not arguing that MANET protocols should be applied or > be applicable -- as you seem to suggest in your email. I believe that I have > stated so repeatedly. > > I submit, however, that as it is currently exposed, ROLL, MANET and 6LOW > seem to be operating within the same space -- to the untrained eye, in > exactly the same space. My position is that it would be very unfortunate > having one WG creating confusion on the applicability of the work of itself > and of other IETF wg's, by simple omission of suitable perimeter > definitions. > > In that sort of situation, the IETF needs to be extra prudent to make sure > to clearly spell out suitable perimeter definitions prior to, or conjointly > with, the first publication cycle. In this case, before or with the survey > I-D. > > Sincerely, > > Thomas > > > On Feb 3, 2009, at 1:19 PM, JP Vasseur wrote: > > Dear WG and ADs, > > Two issues are raised here for which we would appreciate ADs' point of view > and feed-back from the WG. Please see in line. > > > Dear Thomas, > At the risk of repeating myself, I'd like to make a few important > statements before *hopefully* come to a closure ;-) > > -> As you know, many of the ROLL WG active participants have been working > quite hard to produce a detailed set of requirements, discuss how to proceed > on the protocol survey document, and other ID are in the works. > -> We managed to get highly experienced contributors in the field that > have designed and deployed solutions so they not only have an excellent > expertise of the requirements but also on solutions, > *-> Yes we need to rush out. Why ? Because proprietary or semi-closed > non-IP solutions are being deployed at a fairly large scale. I do not think > that I have to convince anybody on this list that this is the WRONG approach > for a number of reasons. The industry is asking for an IP solution *now*.* > -> No we do not want to re-invent the wheel (see our presentation at the > routing plenary in Chicago). Anything that already exists MUST (rfc2119 ;-)) > be used provided that it meets our requirements. And if we can adapt an > existing protocol, we are all for it ! > -> Yes these requirements are quite specifics and this is precisely why > ROLL has been formed, 4 application-specific routing requirements have been > produced (to reduce the scope). Even if at a first sight, it looks very much > similar to a MANET issue (and there ARE similarities but also very different > requirements), having to deal with a highly static network of hundreds of > thousands of battery operated sleeping nodes with 4K of RAM is quite > specific. Note that this is not a random example, but an on-going non-IP > deployed network. > > And to conclude on this introduction ... after an outstanding progress on > the WG during the first 6-8 months, we have been slowed down dramatically > for the last 2 months, thus it is time to close and move on to quickly > re-charter and start the protocol work (hopefully as light as possible) to > see IP-based solution deployed. I know that we are on the same page, we just > need to find a good compromise on both "sides". > > Nothing new so far, let's move to a proposed resolution - See in line, > > On Feb 2, 2009, at 7:37 PM, Thomas Heide Clausen wrote: > > All, > > I promised a review, and I apologize that I wasn't able to do so before the > weekend as originally projected. > > Other than some typos that Chris and others have pointed out, I'll try to > offer my understanding of the problem space and suggest some ways of > addressing my main concerns.... > > My first main concern remain that it is not clear, still, how ROLL > positions itself with respect to MANET, 6LOW et. al, all of which appear to > be within the same space and within the IETF. This I-D sees ROLL as > presented with entirely new problems (the use of "novel" in the abstract, > the statement that "existing protocols were not designed with these > requirements in mind" seem to confirm this). > > Looking at the requirements listed, including "low power, low bandwidth, > low footprint", these appear similar to those which are also brought forward > in e.g. MANET and 6LOW. Reading (quickly, I confess) the various > requirements documents of the draft-ietf-roll series present scenarios > which are similar to those where MANETs are deployed, and are thought > deployed, as well. > > I also note that many additional (and unstated) characteristics between > ROLL and e.g. MANET are the same: mobile, wireless, fragility, > auto-configuration, IP routing, interface/link issues... > > Arguing that, as does this I-D, despite the above impression "ROLL is novel > and different" invites asking "how, exactly?" I think that this question is > valid, and merits being answered, before the evaluations in this I-D can be > judged fairly. > > Note that I come from a MANET background, and so I *could* interpret from > the ROLL discussion that where MANETs may aim for "low power, low bandwidth, > ....", ROLL may be able to quantify these as "below this firm threshold" -- > i.e. as a sort of "extreme" or "constrained" MANET. > > This is a personal observation, I note, which would allow me to comprehend > how ROLL and MANET are positioned relative to one another -- but one which > neither this I-D nor the requirements document spell out or quantify -- or, > for that matter, debunk. > > I think it's critical to understand this, in order to understand the need > for a new protocol development. I think it is important to document this > understanding in something with more persistency. > > If what I suggest above makes sense as a way of positioning ROLL and MANET > relative to one another, I'd suggest including something to this effect in > the survey I-D, as this I-D is the one making a *direct* reference to the > applicability of MANET protocols to ROLL. > > If what I suggest doesn't make sense at all, then I'd be happy to have it > debunked and, hopefully, through that debunking a positioning/description > that does ring true with us all can be produced? > > My second main concern is, that I still think that the choice of criteria > is unfortunate (not the word, Phill has me convinced on that front, but the > actual criteria). Control cost is, by all means, a rather meaningless > criteria when taken in isolation. I've sketched a "zero-control-cost" > routing protocol (flood all data - say use SMF, also a MANET protocol, and > also a rather "mature" I-D and wg item) which would score well on the > control cost criteria, but would likely be an extremely bad choice for > delivering unicast data. > > The metric which matters, and which should matter to ROLL in particular, is > "the total cost of getting user data through the network, including control > cost necessary to set up paths" -- as we know, every packet sent and > received costs bandwidth, energy and cycles -- user data no different from > contro. > > According to the criterions as set up by this I-D, a protocol producing > "longer than shortest paths" at the benefit of slightly lower control cost > would score better than a protocol producing "shortest paths" with slightly > higher control cost. This is not hypothetical, btw., there are plenty of > studies observing and reflecting upon this regarding the different MANET > protocols, in academic literature -- and observed in real networks as well. > > I note that this trade-off (slightly longer paths for lower control cost) > may be perfectly fair, assuming that very low amounts of user data traffic > transit through the network. However, I do not see this assumption mentioned > as a justification for focusing on the control cost metric and discarding > the "path length" or the "total cost of getting user data through the > network". > > I believe that either these assumptions should be made explicit ("there's > so little user data traffic in a ROLL network that we do not care about > shortest paths") or -- if these assumptions do not hold, that the evaluation > criteria are incomplete. > > I note that it's true that we can always add another criteria ad infinitum, > and that's CLEARLY not what we want to do. However when I say "incomplete" > in the above, I simply suggest that based on what is presented one cannot > draw conclusions based on the evaluation criteria....or, worse, that one > draws the wrong conclusions based on the information presented. > > > It is not easy to answer each of your point without running the risk to > start a debate that will never end. You raised some excellent points that I > agree with and others that I firmly disagree with ... So let me try to make > a few observations: > 1) As pointed out earlier, yes there are similarities between MANET and > ROLL. I do not see this as an issue. > 2) The aim of the protocol survey IS NOT to exclude MANET protocols. As > mentioned many times on the list, we *only* wanted to show that existing > protocols, with no change, could not be used in LLNs. This has been > clarified in the document as your request and it HAD to be clarified. > 3) We could have used two different approaches for the survey: > - Look at all MUST from the requirements documents > - Try to derive a subset of necessary but not sufficient criteria, which > the WG chose to do (consensus). Yes this list is not perfect, > criteria could be changed, removed or added but looked good enough with > excellent consensus until LC. > 4) With regards to 6lowpan (I copy the chair), I do not see any overlap at > all. Please refer to their charter and WG items. The only place that > required clarification was the routing requirements and I was personally > opposed to it but this was adopted as a 6lowpan WG item *by consensus*. > We're are working together and managed to sort this out. This document will > be 6lowpan specific. > > What I want to avoid is an endless discussion on the positioning of ROLL, > MANET, 6lowpan and quite frankly we could add other WGs to the list. > > *So what is the bottom line ?* > > We just need to agree on the fact that there is no existing protocol that > meets the ROLL requirements and move to the next step (re-chartering) to > select one (hopefully not two) routing protocols in light of the routing > requirement (NOT the protocol survey), which can either be an adapted MANET > protocol or a new protocol. > > Now moving to your proposed resolution. > > > > So, in a nutshell, I suggest that we address (i) the positioning issue and > (ii) the criteria issue thus: > > o Describe as I proposed above if ROLL and MANETs position themselves as I > have deducted. If my deduction is incorrect, then let's quickly iterate > on the list > as to understand how to do produce an alternative description. If we > can't do this, > then the conclusion can be that "we do not know how ROLL and MANET > position > themselves wrt each other", and we could then state that clearly? > > It *should* not be more than a couple of paragraphs worth of text to add, > I gather? > > > If you find a way to word this, please feel free and I'd be happy to help > but feel it as necessary ... Any opinion from our RTG and INT ADs ? > > o To the criteria, either of: > > - Add the assumption that "user data traffic is so low that path lengths > do not > matter nor does the cost of carrying user data traffice" > > > The motivation for selecting a longer path is not tied to the amount of > traffic here but the level of constraints. Note that this is also true for > several other technologies such as MPLS-TE. You may have large amount of > traffic and still require to follow a non-shortest path (constrained based > routing). This is detailed in several requirements IDs. Criticality of data > is of course different, thus the requirements for potentially different data > paths according to packet marking using DSCP. > > - Add a criteria & evaluation of "path length" > > - Add a criteria & evaluation of "total cost for getting user data > through the network" > > > And we can add many more but if the current protocol do not satisfy > existing requirements, isn't it sufficient to answer the question on whether > one can find an existing protocol? > > This would make a large chunk of my concerns and issues vanish, and allow > correctly interpreting and evaluating the rest of the document. > > > That said, question for the WG. Who think that such criteria should be > added to move forward ? Please reply. > > > > How does that sound as an approach forward? > > > Thanks for helping out. > > Cheers. > > JP. > > Cheers, > > Thomas > > On Jan 27, 2009, at 1:00 AM, Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Routing Over Low power and Lossy networks > Working Group of the IETF. > > > Title : Overview of Existing Routing Protocols for Low Power and Lossy > Networks > > Author(s) : A. Tavakoli, S. Dawson-Haggerty, P. Levis > > Filename : draft-ietf-roll-protocols-survey-05.txt > > Pages : 26 > > Date : 2009-1-26 > > > Networks of low power wireless devices introduce novel IP routing > > issues. Low-power wireless devices, such as sensors, actuators and > > smart objects, have difficult constraints: very limited memory, > > little processing power, and long sleep periods. As most of these > > devices are battery-powered, energy efficiency is critically > > important. Wireless link qualities can vary significantly over time, > > requiring protocols to make agile decisions yet minimize topology > > change energy costs. Routing over such low power and lossy networks > > has novel requirements that existing protocols may not address. This > > document provides a brief survey of the strengths and weaknesses of > > existing protocols with respect to this class of networks. From this > > survey it examines whether existing and mature IETF protocols can be > > used without modification in these networks, or whether further work > > is necessary. > > is necessary. > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-survey-05.txt > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > Content-Type: text/plain > > Content-ID: <2009-1-26155804.I-D@ietf.org> > > > _______________________________________________ > > 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 > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --0016369fa3e03d163c0462043ffb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear al= l,

I have remained silent since others have been echoing the co= ncerns I had pointed out earlier, about the survey document. I want ne= vertheless to reinforce Thomas' point of view now, since I think it is = insightful and useful in order to move on constructively.

Basically, everybody agrees that something special= must be done for sensor ad hoc connectivity with IP, and everybody wants t= o reach the next phase ASAP (i.e. work on solutions). 

<= /div>
However, the lack of consensus on the precise space addressed by ROLL is ba= cklashing lately, with the survey document. The blur indeed had a huge impa= ct on the document so far, forcing the use of a too broad set of goals and = evaluation criterias, and endless discussions about the scope of the survey= .

This lack of definition will continue to plague ROLL an= d the other WGs in the same field down the line if it is not addressed upfr= ont, i.e. now. I thus also encourage everyone to participate in this u= rgent and needed effort.

If the scope of the WG is clearly defined, it should be= straightforward to write a couple of paragraphs that will get us out of th= is mess. So let's just do it!

Cheers
Emmanuel




On Tue, Feb 3, 2009 at 2:19 PM, Thomas Heide Clausen&nb= sp;<ietf@tho= masclausen.org> wrote:
Dear JP, dear ADs, dear WG,

=
For the record, I am not arguing that MANET protocols should be = applied or be applicable -- as you seem to suggest in your email. I be= lieve that I have stated so repeatedly.

I submit, however, that as it is cu= rrently exposed, ROLL, MANET and 6LOW seem to be operating within the same = space -- to the untrained eye, in exactly the same space. My position = is that it would be very unfortunate having one WG creating confusion on th= e applicability of the work of itself and of other IETF wg's, by simple= omission of suitable perimeter definitions. 

In that sort of situation, the IETF= needs to be extra prudent to make sure to clearly spell out suitable perim= eter definitions prior to, or conjointly with, the first publication cycle.= In this case, before or with the survey I-D.

Sincerely,

Thomas


On Feb 3, 2009, at 1:19 PM, JP Vasseur wrote:

Dear WG and ADs,

Two issues are raised here f= or which we would appreciate ADs' point of view and feed-back from the = WG. Please see in line.


Dear Thomas,
At the risk of repeating myself, I'd like to make a few = important statements before *hopefully* come to a closure ;-)
-> As you know, many of the ROLL WG active participants have= been working quite hard to produce a detailed set of requirements, discuss= how to proceed on the protocol survey document, and other ID are in the wo= rks.
-> We managed to get highly experienced contributors in the field t= hat have designed and deployed solutions so they not only have an= excellent expertise of the requirements but also on solutions,
<= b>-> Yes we need to rush out. Why ? Because proprietary or semi-closed n= on-IP solutions are being deployed at a fairly large scale. I do not think = that I have to convince anybody on this list that this is the WRONG approac= h for a number of reasons. The industry is asking for an IP solution *now*.=
-> No we do not want to re-invent the wheel (see our presentation a= t the routing plenary in Chicago). Anything that already exists MUST (rfc21= 19 ;-)) be used provided that it meets our requirements. And if we can adap= t an existing protocol, we are all for it !
-> Yes these requirements are quite specifics and this is precisely= why ROLL has been formed, 4 application-specific routing requirements have= been produced (to reduce the scope). Even if at a first sight, it looks ve= ry much similar to a MANET issue (and there ARE similarities but also very = different requirements), having to deal with a highly static network of hun= dreds of thousands of battery operated sleeping nodes with 4K of RAM is qui= te specific. Note that this is not a random example, but an on-going non-IP= deployed network.

And to conclude on this introduction ... after an outst= anding progress on the WG during the first 6-8 months, we have been slowed = down dramatically for the last 2 months, thus it is time to close and move = on to quickly re-charter and start the protocol work (hopefully as light as= possible) to see IP-based solution deployed. I know that we are on the sam= e page, we just need to find a good compromise on both "sides".

Nothing new so far, let's move to a proposed resolu= tion - See in line,

On Feb 2, 2009, at 7= :37 PM, Thomas Heide Clausen wrote:

All,

I promised a review, and I apologize that I wasn't able to = do so before the weekend as originally projected.

Other than some ty= pos that Chris and others have pointed out, I'll try to offer my unders= tanding of the problem space and suggest some ways of addressing my main co= ncerns....

My first main concern remain that it is not clear, still, how ROLL posi= tions itself with respect to MANET, 6LOW et. al, all of which appear to be = within the same space and within the IETF. This I-D sees ROLL as presented = with entirely new problems (the use of "novel" in the abstract, t= he statement that "existing protocols were not designed with these req= uirements in mind" seem to confirm this).

Looking at the  requirements listed, including "low power, lo= w bandwidth, low footprint", these appear similar to those which are a= lso brought forward in e.g. MANET and 6LOW. Reading (quickly, I confess) th= e various requirements documents  of the draft-ietf-roll series presen= t scenarios which are similar to those where MANETs are deployed, and are t= hought deployed, as well.

I also note that many additional (and unstated) characteristics between= ROLL and e.g. MANET are the same: mobile, wireless, fragility, auto-config= uration, IP routing, interface/link issues...

Arguing that, as does = this I-D, despite the above impression "ROLL is novel and different&qu= ot; invites asking "how, exactly?" I think that this question is = valid, and merits being answered, before the evaluations in this I-D can be= judged fairly.

Note that I come from a MANET background, and so I *could* interpret fr= om the ROLL discussion that where MANETs may aim for "low power, low b= andwidth, ....", ROLL may be able to quantify these as "below thi= s firm threshold" -- i.e. as a sort of "extreme" or "co= nstrained" MANET.

This is a personal observation, I note, which would allow me to compreh= end how ROLL and MANET are positioned relative to one another -- but one wh= ich neither this I-D nor the requirements document spell out or quantify --= or, for that matter, debunk.

I think it's critical to understand this, in order to understand th= e need for a new protocol development. I think it is important to document = this understanding in something with more persistency.

If what I sug= gest above makes sense as a way of positioning ROLL and MANET relative to o= ne another, I'd suggest including something to this effect in the surve= y I-D, as this I-D is the one making a *direct* reference to the applicabil= ity of MANET protocols to ROLL.

If what I suggest doesn't make sense at all, then I'd be happy = to have it debunked and, hopefully, through that debunking a positioning/de= scription that does ring true with us all can be produced?

My second= main concern is, that I still think that the choice of criteria is unfortu= nate (not the word, Phill has me convinced on that front, but the actual cr= iteria). Control cost is, by all means, a rather meaningless criteria when = taken in isolation. I've sketched a "zero-control-cost" routi= ng protocol (flood all data - say use SMF, also a MANET protocol, and also = a rather "mature" I-D and wg item) which would score well on the = control cost criteria, but would likely be an extremely bad choice for deli= vering unicast data.

The metric which matters, and which should matter to ROLL in particular= , is "the total cost of getting user data through the network, includi= ng control cost necessary to set up paths" -- as we know, every packet= sent and received costs bandwidth, energy and cycles -- user data no diffe= rent from contro.

According to the criterions as set up by this I-D, a protocol producing= "longer than shortest paths" at the benefit of slightly lower co= ntrol cost would score better than a protocol producing "shortest path= s" with slightly higher control cost. This is not hypothetical, btw., = there are plenty of studies observing and reflecting upon this regarding th= e different MANET protocols, in academic literature -- and observed in real= networks as well.

I note that this trade-off (slightly longer paths for lower control cos= t) may be perfectly fair, assuming that very low amounts of user data traff= ic transit through the network. However, I do not see this assumption menti= oned as a justification for focusing on the control cost metric and discard= ing the "path length" or the "total cost of getting user dat= a through the network".

I believe that either these assumptions should be made explicit ("= there's so little user data traffic in a ROLL network that we do not ca= re about shortest paths") or -- if these assumptions do not hold, that= the evaluation criteria are incomplete.

I note that it's true that we can always add another criteria ad in= finitum, and that's CLEARLY not what we want to do. However when I say = "incomplete" in the above, I simply suggest that based on what is= presented one cannot draw conclusions based on the evaluation criteria....= or, worse, that one draws the wrong conclusions based on the information pr= esented.

It is not easy to answer each of your poin= t without running the risk to start a debate that will never end. You raise= d some excellent points that I agree with and others that I firmly disagree= with ... So let me try to make a few observations:
1) As pointed out earlier, yes there are similarities between MANET an= d ROLL. I do not see this as an issue.
2) The aim of the protocol= survey IS NOT to exclude MANET protocols. As mentioned many times on the l= ist, we *only* wanted to show that existing protocols, with no change, coul= d not be used in LLNs. This has been clarified in the document as your requ= est and it HAD to be clarified.
3) We could have used two different approaches for the survey:
- Look at all MUST from the r= equirements documents
- Try to derive a subset of necessary but not sufficient criteria, whic= h the WG chose to do (consensus). Yes this list is not perfect,
criteria could be cha= nged, removed or added but looked good enough with excellent consensus unti= l LC.
4) With regards to 6lowpan (I copy the chair), I do not= see any overlap at all. Please refer to their charter and WG items. The on= ly place that required clarification was the routing requirements and I was= personally opposed to it but this was adopted as a 6lowpan WG item by consensus. We're are working together and managed to sort this = out. This document will be 6lowpan specific.

What I want to avoid is an endless discussion on the po= sitioning of ROLL, MANET, 6lowpan and quite frankly we could add other WGs = to the list.

So what is the bottom line ?

We just need to agree on the fact that there is no exis= ting protocol that meets the ROLL requirements and move to the next step (r= e-chartering) to select one (hopefully not two) routing protocols in light = of the routing requirement (NOT the protocol survey), which can either be a= n adapted MANET protocol or a new protocol.

Now moving to your proposed resolution.



So, in a nutshell, I suggest that we addre= ss (i) the positioning issue and (ii) the criteria issue thus:

o = Describe as I proposed above if ROLL and MANETs position themselves = as I
as to understand how to do produce an= alternative description. If we can't do this,
themselves wrt each other", and we cou= ld then state that clearly?
It *should* not be more than a couple of paragrap= hs worth of text to add, I gather?


If you find a way to word this, pleas= e feel free and I'd be happy to help but feel it as necessary ... Any o= pinion from our RTG and INT ADs ?

o To the criteria, either of:

- Add the assumption that "user data traffic is so low that path length= s do not
matter nor does the cost of carrying user data traffi= ce"


The motivation for selecting a l= onger path is not tied to the amount of traffic here but the level of const= raints. Note that this is also true for several other technologies such as = MPLS-TE. You may have large amount of traffic and still require to follow a= non-shortest path (constrained based routing). This is detailed in several= requirements IDs. Criticality of data is of course different, thus the req= uirements for potentially different data paths according to packet marking = using DSCP.

- Add a criteria &a= mp; evaluation of "path length"

- Add a criteria & evaluation of "total c= ost for getting user data through the network"


And we can add many more but if = the current protocol do not satisfy existing requirements, isn't it suf= ficient to answer the question on whether one can find an existing&nbs= p;protocol?

This would make a large chunk of my conc= erns and issues vanish, and allow correctly interpreting and evaluating the= rest of the document.

That said, que= stion for the WG. Who think that such criteria should be added to move forw= ard ? Please reply.



How does that sound as an approa= ch forward?


Thanks for helpin= g out.

Cheers.

JP.

Cheers,

Thomas

On Jan 27, = 2009, at 1:00 AM, Internet-Drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Draf= ts
directories.
This draft is a work item of the Routing Over Low power = and Lossy networks Working Group of the IETF.

: Overview of Existing Routing Protocols for Low= Power and Lossy Networks
= Author(s) : A. Tavakoli, S= . Dawson-Haggerty, P. Levis
Filename : draft-ietf-roll-protocols-survey-05.txt
= Pages : 26
Date : 2009-1-26
=
Networks of low power wir= eless devices introduce novel IP routing
  issues.  Low-power wireless devices, such as sensors, actu= ators and
  smart objec= ts, have difficult constraints: very limited memory,
  little processing power, and long sleep per= iods.  As most of these
  devices are battery-powe= red, energy efficiency is critically
  important.  Wireless link qualities can vary significa= ntly over time,
  requiring protocols to make agile dec= isions yet minimize topology
&nbs= p; change energy costs.  Routing over such low power and lossy ne= tworks
  has novel requirements that existing protocols may not address.=  This
  document = provides a brief survey of the strengths and weaknesses of
=
  existing protocols with respect to this class of networks. &nbs= p;From this
  survey it= examines whether existing and mature IETF protocols can be
  used without modification in these networks, or whether further= work
  is necessary.
  is necessary.

A URL for this Internet-Draft is= :
= http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-survey-05.txt=

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
=
implementation to automatically retr= ieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID: <2009-1-26155804.I-D@ietf.org>

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/rol= l

_______________________________________________
Roll ma= iling list
Roll@ietf.= org
https://www.ietf.org/mailman/listinfo/roll



_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.iet= f.org/mailman/listinfo/roll


On Tue, = Feb 3, 2009 at 2:19 PM, Thomas Heide Clausen <ietf@thomasclausen.org> wr= ote:
Dear JP, dear ADs, dear WG,

For the record, I am not ar= guing that MANET protocols should be applied or be applicable -- as you see= m to suggest in your email. I believe that I have stated so repeatedly= .

I submit, however, that as it is currently e= xposed, ROLL, MANET and 6LOW seem to be operating within the same space -- = to the untrained eye, in exactly the same space. My position is that i= t would be very unfortunate having one WG creating confusion on the applica= bility of the work of itself and of other IETF wg's, by simple omission= of suitable perimeter definitions. 

In that sort of situation, the IETF needs to be extra= prudent to make sure to clearly spell out suitable perimeter definitions p= rior to, or conjointly with, the first publication cycle. In this case, bef= ore or with the survey I-D.

Sincerely,

Thomas


On Feb 3,= 2009, at 1:19 PM, JP Vasseur wrote:

Dear WG and ADs,

Two issues are raised here for = which we would appreciate ADs' point of view and feed-back from the WG.= Please see in line.


Dear Thomas,

At the risk o= f repeating myself, I'd like to make a few important statements before = *hopefully* come to a closure ;-)

-> As you kno= w, many of the ROLL WG active participants have been working quite hard to = produce a detailed set of requirements, discuss how to proceed on the proto= col survey document, and other ID are in the works.
-> We managed to get highly experienced contributors in the field t= hat have designed and deployed solutions so they not only have an= excellent expertise of the requirements but also on solutions,
<= b>-> Yes we need to rush out. Why ? Because proprietary or semi-closed n= on-IP solutions are being deployed at a fairly large scale. I do not think = that I have to convince anybody on this list that this is the WRONG approac= h for a number of reasons. The industry is asking for an IP solution *now*.=
-> No we do not want to re-invent the wheel (see our presentation a= t the routing plenary in Chicago). Anything that already exists MUST (rfc21= 19 ;-)) be used provided that it meets our requirements. And if we can adap= t an existing protocol, we are all for it !
-> Yes these requirements are quite specifics and this is precisely= why ROLL has been formed, 4 application-specific routing requirements have= been produced (to reduce the scope). Even if at a first sight, it looks ve= ry much similar to a MANET issue (and there ARE similarities but also very = different requirements), having to deal with a highly static network of hun= dreds of thousands of battery operated sleeping nodes with 4K of RAM is qui= te specific. Note that this is not a random example, but an on-going non-IP= deployed network.

And to conclude on this introduction ... after an outst= anding progress on the WG during the first 6-8 months, we have been slowed = down dramatically for the last 2 months, thus it is time to close and move = on to quickly re-charter and start the protocol work (hopefully as light as= possible) to see IP-based solution deployed. I know that we are on the sam= e page, we just need to find a good compromise on both "sides".

Nothing new so far, let's move to a proposed resolu= tion - See in line,

On Feb 2, 2009, at 7= :37 PM, Thomas Heide Clausen wrote:

All,

I promised a review, and I apologize that I wasn't able to = do so before the weekend as originally projected.

Other than some ty= pos that Chris and others have pointed out, I'll try to offer my unders= tanding of the problem space and suggest some ways of addressing my main co= ncerns....

My first main concern remain that it is not clear, still, how ROLL posi= tions itself with respect to MANET, 6LOW et. al, all of which appear to be = within the same space and within the IETF. This I-D sees ROLL as presented = with entirely new problems (the use of "novel" in the abstract, t= he statement that "existing protocols were not designed with these req= uirements in mind" seem to confirm this).

Looking at the  requirements listed, including "low power, lo= w bandwidth, low footprint", these appear similar to those which are a= lso brought forward in e.g. MANET and 6LOW. Reading (quickly, I confess) th= e various requirements documents  of the draft-ietf-roll series presen= t scenarios which are similar to those where MANETs are deployed, and are t= hought deployed, as well.

I also note that many additional (and unstated) characteristics between= ROLL and e.g. MANET are the same: mobile, wireless, fragility, auto-config= uration, IP routing, interface/link issues...

Arguing that, as does = this I-D, despite the above impression "ROLL is novel and different&qu= ot; invites asking "how, exactly?" I think that this question is = valid, and merits being answered, before the evaluations in this I-D can be= judged fairly.

Note that I come from a MANET background, and so I *could* interpret fr= om the ROLL discussion that where MANETs may aim for "low power, low b= andwidth, ....", ROLL may be able to quantify these as "below thi= s firm threshold" -- i.e. as a sort of "extreme" or "co= nstrained" MANET.

This is a personal observation, I note, which would allow me to compreh= end how ROLL and MANET are positioned relative to one another -- but one wh= ich neither this I-D nor the requirements document spell out or quantify --= or, for that matter, debunk.

I think it's critical to understand this, in order to understand th= e need for a new protocol development. I think it is important to document = this understanding in something with more persistency.

If what I sug= gest above makes sense as a way of positioning ROLL and MANET relative to o= ne another, I'd suggest including something to this effect in the surve= y I-D, as this I-D is the one making a *direct* reference to the applicabil= ity of MANET protocols to ROLL.

If what I suggest doesn't make sense at all, then I'd be happy = to have it debunked and, hopefully, through that debunking a positioning/de= scription that does ring true with us all can be produced?

My second= main concern is, that I still think that the choice of criteria is unfortu= nate (not the word, Phill has me convinced on that front, but the actual cr= iteria). Control cost is, by all means, a rather meaningless criteria when = taken in isolation. I've sketched a "zero-control-cost" routi= ng protocol (flood all data - say use SMF, also a MANET protocol, and also = a rather "mature" I-D and wg item) which would score well on the = control cost criteria, but would likely be an extremely bad choice for deli= vering unicast data.

The metric which matters, and which should matter to ROLL in particular= , is "the total cost of getting user data through the network, includi= ng control cost necessary to set up paths" -- as we know, every packet= sent and received costs bandwidth, energy and cycles -- user data no diffe= rent from contro.

According to the criterions as set up by this I-D, a protocol producing= "longer than shortest paths" at the benefit of slightly lower co= ntrol cost would score better than a protocol producing "shortest path= s" with slightly higher control cost. This is not hypothetical, btw., = there are plenty of studies observing and reflecting upon this regarding th= e different MANET protocols, in academic literature -- and observed in real= networks as well.

I note that this trade-off (slightly longer paths for lower control cos= t) may be perfectly fair, assuming that very low amounts of user data traff= ic transit through the network. However, I do not see this assumption menti= oned as a justification for focusing on the control cost metric and discard= ing the "path length" or the "total cost of getting user dat= a through the network".

I believe that either these assumptions should be made explicit ("= there's so little user data traffic in a ROLL network that we do not ca= re about shortest paths") or -- if these assumptions do not hold, that= the evaluation criteria are incomplete.

I note that it's true that we can always add another criteria ad in= finitum, and that's CLEARLY not what we want to do. However when I say = "incomplete" in the above, I simply suggest that based on what is= presented one cannot draw conclusions based on the evaluation criteria....= or, worse, that one draws the wrong conclusions based on the information pr= esented.

It is not easy to answer each of your poin= t without running the risk to start a debate that will never end. You raise= d some excellent points that I agree with and others that I firmly disagree= with ... So let me try to make a few observations:
1) As pointed out earlier, yes there are similarities between MANET an= d ROLL. I do not see this as an issue.
2) The aim of the protocol= survey IS NOT to exclude MANET protocols. As mentioned many times on the l= ist, we *only* wanted to show that existing protocols, with no change, coul= d not be used in LLNs. This has been clarified in the document as your requ= est and it HAD to be clarified.
3) We could have used two different approaches for the survey:
- Look at all MUST from the requ= irements documents
- = Try to derive a subset of necessary but not sufficient criteria, which the = WG chose to do (consensus). Yes this list is not perfect,
criteria could be change= d, removed or added but looked good enough with excellent consensus until L= C.
4) With regards to 6lowpan (I copy the chair), I do not se= e any overlap at all. Please refer to their charter and WG items. The only = place that required clarification was the routing requirements and I was pe= rsonally opposed to it but this was adopted as a 6lowpan WG item by cons= ensus. We're are working together and managed to sort this out. Thi= s document will be 6lowpan specific.

What I want to avoid is an endless discussion on the po= sitioning of ROLL, MANET, 6lowpan and quite frankly we could add other WGs = to the list.

So what is the bottom line ?

We just need to agree on the fact that there is no exis= ting protocol that meets the ROLL requirements and move to the next step (r= e-chartering) to select one (hopefully not two) routing protocols in light = of the routing requirement (NOT the protocol survey), which can either be a= n adapted MANET protocol or a new protocol.

Now moving to your proposed resolution.



So, in a nutshell, I suggest that we addre= ss (i) the positioning issue and (ii) the criteria issue thus:

o Describe as I proposed above if ROLL and MANETs position themselves as I have deducted. If my deduction is incorrect, then let's quickly it= erate on the list
as to understand how to do produce an alternative= description. If we can't do this,
then the conclusion can be that "we do not know how ROLL and MANE= T position
themselves wrt each other", and we could then state= that clearly?

It *should* not be more than a couple of paragraphs worth of = text to add, I gather?


If you find a way to word this, pleas= e feel free and I'd be happy to help but feel it as necessary ... Any o= pinion from our RTG and INT ADs ?

o To the criteria, either of:

- Add the assumption= that "user data traffic is so low that path lengths do not
matter nor does the cost of carrying user data traffice"
=

The motivation for selecting a longe= r path is not tied to the amount of traffic here but the level of constrain= ts. Note that this is also true for several other technologies such as MPLS= -TE. You may have large amount of traffic and still require to follow a non= -shortest path (constrained based routing). This is detailed in several req= uirements IDs. Criticality of data is of course different, thus the require= ments for potentially different data paths according to packet marking usin= g DSCP.

= - Add a criteria & evaluati= on of "path length"

- Add a criteria & evaluation of "total cost for gett= ing user data through the network"


And we can add many more but if = the current protocol do not satisfy existing requirements, isn't it suf= ficient to answer the question on whether one can find an existing&nbs= p;protocol?

This would make a large chunk of my conc= erns and issues vanish, and allow correctly interpreting and evaluating the= rest of the document.

That said, que= stion for the WG. Who think that such criteria should be added to move forw= ard ? Please reply.



How does that sound as an approa= ch forward?


Thanks for helpin= g out.

Cheers.

JP.

Cheers,

Thomas

On Jan 27, = 2009, at 1:00 AM, Internet-Drafts@ietf.org wrote:

A= New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Routing Over Low power = and Lossy networks Working Group of the IETF.

= Title : Overview of Existing Routing Protocols for Low Power an= d Lossy Networks
Author(s) : A. Tavakoli, S. Daws= on-Haggerty, P. Levis
Filename : draft-ietf-roll-protocols-survey-05.txt
Pages : 26
Date : 2009-1-26

Networks of low power wirele= ss devices introduce novel IP routing
  issues.  Low-power wireless devices, such as sensors, act= uators and
  smart obj= ects, have difficult constraints: very limited memory,
  little processing power, and long sleep = periods.  As most of these
  devices are battery-pow= ered, energy efficiency is critically
  important.  Wireless link qualities can vary signifi= cantly over time,
  requiring protocols to make agile de= cisions yet minimize topology
&n= bsp; change energy costs.  Routing over such low power and lossy = networks
  has novel requirements that existing= protocols may not address.  This
  document provides a brief survey of the strengths and we= aknesses of
  existing protocols with respect to t= his class of networks.  From this
  survey it examines whether existing and mature IETF prot= ocols can be
  used without modification in these n= etworks, or whether further work
=   is necessary.
 = ; is necessary.

A URL = for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ro= ll-protocols-survey-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
=
implementation to automatically retr= ieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID: <2009-1-26155804.I-D@ietf.org>

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/rol= l

_______________________________________________
Roll ma= iling list
Roll@ietf.= org
https://www.ietf.org/mailman/listinfo/roll



_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll


--0016369fa3e03d163c0462043ffb-- --===============1539945296== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1539945296==-- From roll-bounces@ietf.org Tue Feb 3 06:42:37 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CF9E3A6B5A; Tue, 3 Feb 2009 06:42:37 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5809C3A6B5A for ; Tue, 3 Feb 2009 06:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MrPXNwCDK34 for ; Tue, 3 Feb 2009 06:42:35 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 41D1B3A69B1 for ; Tue, 3 Feb 2009 06:42:35 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n13EgBPI009945; Tue, 3 Feb 2009 15:42:13 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n13EeDCZ012295; Tue, 3 Feb 2009 15:40:29 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n13Ee4NI014233; Tue, 3 Feb 2009 15:40:04 +0100 Message-ID: <49885744.3050603@gmail.com> Date: Tue, 03 Feb 2009 15:40:04 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: JP Vasseur References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <4987899C.3090708@gmail.com> <7C6DC187-681B-48DF-AFF1-FE329EA93CA8@cisco.com> In-Reply-To: <7C6DC187-681B-48DF-AFF1-FE329EA93CA8@cisco.com> Cc: roll@ietf.org Subject: Re: [Roll] 6lowpan WG items and ROLL WG activities X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org JP Vasseur a =E9crit : > = > On Feb 3, 2009, at 1:02 AM, Alexandru Petrescu wrote: > = >> Mischa Dohler a =E9crit : [...] >>> 6LoWPAN: - mainly specifies IPv6 header compression but not = >>> (optimized) routing per se; >> = >> Not only Header Compression, 6lowpan WG seems to also be looking at >> Neighbor Discovery for 802.15.4, which is quite relevant here I = >> believe, because ZigBee was mentioned recently here. > = > HOLD-ON ... We are NOT working on ZIGBEE here. Let's not go there. = > This is the IETF, we work on IP. I think it is good to mention all link-layers which are addressed by ROLL. The link layer characteristics are of paramount importance on the subnetting and addressing architecture, and thus on the kind of protocol needed. (I agree though at IETF we work on IP, independently of the link-layer, and some times dependently on the link-layer: IP-over-foo are typical.) >>> - [6lowpan] is stuck to IEEE 802.15.4 radios. >> = >> I think it is good to list the radios ROLL looks at: >> = >> IEEE 802.15.4 SP100 http://tinyurl.com/4d3j64 ZigBee HART = >> http://tinyurl.com/4d3j64 >> = > = > There is quite a bit of confusion. Zigbee is non-IP and build above = > 15.4. We are designing IP-solution and indeed 15.4 is one of the = > PHY/MAC LLN may run onto. I think in the cases a wireless network is made of ZigBee nodes, or 802.15.4 nodes, the entire network is actually a single subnet. And in these cases Neighbor Discovery protocol is very pertinent for ROLL. This would contradict all the inconvenients cited in section 8.1. "IPv6 ND" of protocols-survey draft. HEnce I disagree with this section. I disagree with it for more reasons, one being: protocols-survey draft: > The fact that all routers must respond to a Router Solicitation = > requires that the number of routers with a 1-hop neighborhood is = > small, or there will be a reply implosion. Such reply implosion is avoided by the IPv6 ND spec, because it requires the RAs responding to an RS are spaced randomly in time: RFC4861 "ND for IPv6": > 6.2.6. Processing Router Solicitations [...] > In all cases, Router Advertisements sent in response to a Router = > Solicitation MUST be delayed by a random time between 0 and = > MAX_RA_DELAY_TIME seconds. Alex _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Feb 3 06:52:27 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6EA3A6BFF; Tue, 3 Feb 2009 06:52:26 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 012CA3A6BFF for ; Tue, 3 Feb 2009 06:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pB4U4NmhhW3Y for ; Tue, 3 Feb 2009 06:52:24 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id E32053A69E4 for ; Tue, 3 Feb 2009 06:52:23 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n13Eq20x022030; Tue, 3 Feb 2009 15:52:02 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n13EpxYH006711; Tue, 3 Feb 2009 15:52:00 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n13Epxrw025087; Tue, 3 Feb 2009 15:51:59 +0100 Message-ID: <49885A0F.4040605@gmail.com> Date: Tue, 03 Feb 2009 15:51:59 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: JP Vasseur References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> In-Reply-To: Cc: ROLL WG Subject: Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review and comments draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org JP Vasseur a =E9crit : [...] > -> Yes these requirements are quite specifics and this is precisely = > why ROLL has been formed, 4 application-specific routing requirements > have been produced (to reduce the scope). Good complete requirements lists =3D=3D good engineering approach, I agree. Side note, in MEXT WG there are also 3 sets of requirements, for three different spaces (automotive, aeronautics and consumer electronics). We have not yet embarked on designing that Mobile IP or ND extension for dealing with Route Optimization for NEMO-based moving networks. Alex Even if at a first sight, it looks > very much similar to a MANET issue (and there ARE similarities but = > also very different requirements), having to deal with a highly = > static network of hundreds of thousands of battery operated sleeping = > nodes with 4K of RAM is quite specific. Note that this is not a = > random example, but an on-going non-IP deployed network. > = > And to conclude on this introduction ... after an outstanding = > progress on the WG during the first 6-8 months, we have been slowed = > down dramatically for the last 2 months, thus it is time to close and > move on to quickly re-charter and start the protocol work (hopefully > as light as possible) to see IP-based solution deployed. I know that > we are on the same page, we just need to find a good compromise on = > both "sides". > = > Nothing new so far, let's move to a proposed resolution - See in = > line, > = > On Feb 2, 2009, at 7:37 PM, Thomas Heide Clausen wrote: > = >> All, >> = >> I promised a review, and I apologize that I wasn't able to do so before the weekend as originally projected. >> = >> Other than some typos that Chris and others have pointed out, I'll = >> try to offer my understanding of the problem space and suggest some >> ways of addressing my main concerns.... >> = >> My first main concern remain that it is not clear, still, how ROLL = >> positions itself with respect to MANET, 6LOW et. al, all of which = >> appear to be within the same space and within the IETF. This I-D = >> sees ROLL as presented with entirely new problems (the use of = >> "novel" in the abstract, the statement that "existing protocols = >> were not designed with these requirements in mind" seem to confirm = >> this). >> = >> Looking at the requirements listed, including "low power, low bandwidth, low footprint", these appear similar to those which are >> also brought forward in e.g. MANET and 6LOW. Reading (quickly, I confess) the various requirements documents of the draft-ietf-roll >> series present scenarios which are similar to those where MANETs = >> are deployed, and are thought deployed, as well. >> = >> I also note that many additional (and unstated) characteristics between ROLL and e.g. MANET are the same: mobile, wireless, >> fragility, auto-configuration, IP routing, interface/link issues... >> = >> = >> = >> Arguing that, as does this I-D, despite the above impression "ROLL = >> is novel and different" invites asking "how, exactly?" I think that >> this question is valid, and merits being answered, before the = >> evaluations in this I-D can be judged fairly. >> = >> Note that I come from a MANET background, and so I *could* = >> interpret from the ROLL discussion that where MANETs may aim for = >> "low power, low bandwidth, ....", ROLL may be able to quantify = >> these as "below this firm threshold" -- i.e. as a sort of "extreme" >> or "constrained" MANET. >> = >> This is a personal observation, I note, which would allow me to comprehend how ROLL and MANET are positioned relative to one >> another -- but one which neither this I-D nor the requirements = >> document spell out or quantify -- or, for that matter, debunk. >> = >> I think it's critical to understand this, in order to understand = >> the need for a new protocol development. I think it is important to >> document this understanding in something with more persistency. >> = >> If what I suggest above makes sense as a way of positioning ROLL = >> and MANET relative to one another, I'd suggest including something = >> to this effect in the survey I-D, as this I-D is the one making a = >> *direct* reference to the applicability of MANET protocols to ROLL. >> = >> = >> = >> If what I suggest doesn't make sense at all, then I'd be happy to = >> have it debunked and, hopefully, through that debunking a positioning/description that does ring true with us all can be >> produced? >> = >> My second main concern is, that I still think that the choice of criteria is unfortunate (not the word, Phill has me convinced on >> that front, but the actual criteria). Control cost is, by all = >> means, a rather meaningless criteria when taken in isolation. I've = >> sketched a "zero-control-cost" routing protocol (flood all data - = >> say use SMF, also a MANET protocol, and also a rather "mature" I-D = >> and wg item) which would score well on the control cost criteria, = >> but would likely be an extremely bad choice for delivering unicast = >> data. >> = >> The metric which matters, and which should matter to ROLL in particular, is "the total cost of getting user data through the network, including control cost necessary to set up paths" -- as we >> know, every packet sent and received costs bandwidth, energy and cycles -- user data no different from contro. >> = >> According to the criterions as set up by this I-D, a protocol producing "longer than shortest paths" at the benefit of slightly lower control cost would score better than a protocol producing "shortest paths" with slightly higher control cost. This is not hypothetical, btw., there are plenty of studies observing and reflecting upon this regarding the different MANET protocols, in academic literature -- and observed in real networks as well. >> = >> I note that this trade-off (slightly longer paths for lower control >> cost) may be perfectly fair, assuming that very low amounts of = >> user data traffic transit through the network. However, I do not = >> see this assumption mentioned as a justification for focusing on = >> the control cost metric and discarding the "path length" or the = >> "total cost of getting user data through the network". >> = >> I believe that either these assumptions should be made explicit ("there's so little user data traffic in a ROLL network that we do >> not care about shortest paths") or -- if these assumptions do not = >> hold, that the evaluation criteria are incomplete. >> = >> I note that it's true that we can always add another criteria ad infinitum, and that's CLEARLY not what we want to do. However when >> I say "incomplete" in the above, I simply suggest that based on = >> what is presented one cannot draw conclusions based on the = >> evaluation criteria....or, worse, that one draws the wrong = >> conclusions based on the information presented. > = > It is not easy to answer each of your point without running the risk = > to start a debate that will never end. You raised some excellent = > points that I agree with and others that I firmly disagree with ... = > So let me try to make a few observations: 1) As pointed out earlier, = > yes there are similarities between MANET and ROLL. I do not see this = > as an issue. 2) The aim of the protocol survey IS NOT to exclude = > MANET protocols. As mentioned many times on the list, we *only* = > wanted to show that existing protocols, with no change, could not be = > used in LLNs. This has been clarified in the document as your request > and it HAD to be clarified. 3) We could have used two different = > approaches for the survey: - Look at all MUST from the requirements = > documents - Try to derive a subset of necessary but not sufficient = > criteria, which the WG chose to do (consensus). Yes this list is not = > perfect, criteria could be changed, removed or added but looked good = > enough with excellent consensus until LC. 4) With regards to 6lowpan = > (I copy the chair), I do not see any overlap at all. Please refer to = > their charter and WG items. The only place that required = > clarification was the routing requirements and I was personally opposed to it but this was adopted as a 6lowpan WG item *by > consensus*. We're are working together and managed to sort this out. = > This document will be 6lowpan specific. > = > What I want to avoid is an endless discussion on the positioning of ROLL, MANET, 6lowpan and quite frankly we could add other WGs to the > list. > = > /So what is the bottom line ?/ > = > We just need to agree on the fact that there is no existing protocol = > that meets the ROLL requirements and move to the next step (re-chartering) to select one (hopefully not two) routing protocols > in light of the routing requirement (NOT the protocol survey), which = > can either be an adapted MANET protocol or a new protocol. > = > Now moving to your proposed resolution. > = >> = >> = >> So, in a nutshell, I suggest that we address (i) the positioning = >> issue and (ii) the criteria issue thus: >> = >> o Describe as I proposed above if ROLL and MANETs position = >> themselves as I have deducted. If my deduction is incorrect, then = >> let's quickly iterate on the list as to understand how to do = >> produce an alternative description. If we can't do this, then the = >> conclusion can be that "we do not know how ROLL and MANET position themselves wrt each other", and we could then state that clearly? >> = >> It *should* not be more than a couple of paragraphs worth of text = >> to add, I gather? >> = > = > If you find a way to word this, please feel free and I'd be happy to = > help but feel it as necessary ... Any opinion from our RTG and INT = > ADs ? > = >> o To the criteria, either of: >> = >> - Add the assumption that "user data traffic is so low that path lengths do not matter nor does the cost of carrying user data >> traffice" >> = > = > The motivation for selecting a longer path is not tied to the amount = > of traffic here but the level of constraints. Note that this is also = > true for several other technologies such as MPLS-TE. You may have = > large amount of traffic and still require to follow a non-shortest = > path (constrained based routing). This is detailed in several = > requirements IDs. Criticality of data is of course different, thus = > the requirements for potentially different data paths according to = > packet marking using DSCP. > = >> - Add a criteria & evaluation of "path length" >> = >> - Add a criteria & evaluation of "total cost for getting user data = >> through the network" >> = > = > And we can add many more but if the current protocol do not satisfy existing requirements, isn't it sufficient to answer the question on > whether one can find an existing protocol? > = >> This would make a large chunk of my concerns and issues vanish, and >> allow correctly interpreting and evaluating the rest of the = >> document. > = > That said, question for the WG. Who think that such criteria should = > be added to move forward ? Please reply. > = >> = >> = >> How does that sound as an approach forward? >> = > = > Thanks for helping out. > = > Cheers. > = > JP. > = >> Cheers, >> = >> Thomas >> = >> On Jan 27, 2009, at 1:00 AM, Internet-Drafts@ietf.org wrote: >> = >>> A New Internet-Draft is available from the on-line = >>> Internet-Drafts directories. This draft is a work item of the = >>> Routing Over Low power and Lossy networks Working Group of the = >>> IETF. >>> = >>> Title : Overview of Existing Routing Protocols for Low Power and = >>> Lossy Networks Author(s) : A. Tavakoli, S. Dawson-Haggerty, P. = >>> Levis Filename : draft-ietf-roll-protocols-survey-05.txt Pages : = >>> 26 Date : 2009-1-26 >>> = >>> Networks of low power wireless devices introduce novel IP routing >>> issues. Low-power wireless devices, such as sensors, actuators = >>> and smart objects, have difficult constraints: very limited = >>> memory, little processing power, and long sleep periods. As most >>> of these devices are battery-powered, energy efficiency is = >>> critically important. Wireless link qualities can vary = >>> significantly over time, requiring protocols to make agile = >>> decisions yet minimize topology change energy costs. Routing = >>> over such low power and lossy networks has novel requirements = >>> that existing protocols may not address. This document provides = >>> a brief survey of the strengths and weaknesses of existing = >>> protocols with respect to this class of networks. From this >>> survey it examines whether existing and mature IETF protocols can >>> be used without modification in these networks, or whether = >>> further work is necessary. is necessary. >>> = >>> A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-survey-05.txt >>> = >>> = >>> Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ >>> = >>> Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. Content-Type: text/plain Content-ID: = >>> <2009-1-26155804.I-D@ietf.org >>> > >>> = >>> _______________________________________________ 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 > = > = > ------------------------------------------------------------------------ > = > = > = > _______________________________________________ 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 From roll-bounces@ietf.org Tue Feb 3 06:55:42 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A561D3A6C37; Tue, 3 Feb 2009 06:55:42 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EB4E3A6C37 for ; Tue, 3 Feb 2009 06:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.497 X-Spam-Level: X-Spam-Status: No, score=-10.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9oVkK4av0Kr for ; Tue, 3 Feb 2009 06:55:40 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 4B5153A6C2E for ; Tue, 3 Feb 2009 06:55:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,372,1231113600"; d="scan'208";a="32715809" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2009 14:55:20 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n13EtJOl024290; Tue, 3 Feb 2009 15:55:19 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n13EtJOL005087; Tue, 3 Feb 2009 14:55:19 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 15:55:19 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 15:55:19 +0100 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <49885744.3050603@gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Feb 2009 15:55:18 +0100 References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <4987899C.3090708@gmail.com> <7C6DC187-681B-48DF-AFF1-FE329EA93CA8@cisco.com> <49885744.3050603@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Feb 2009 14:55:19.0337 (UTC) FILETIME=[6E815190:01C9860F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3057; t=1233672919; x=1234536919; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=206lowpan=20WG=20items=20and=20R OLL=20WG=20activities |Sender:=20; bh=fHwHf27WMm7PJzJpZ09AeZx5NBoPzj/NfECvGsmNCZo=; b=T3xsH0QDxTPr0yIa2OiQhkO75uIiOauvwVr1IoCQW4TVGmiv3VwIuMPlDS Jn5ND4KIReQITonReux15mJsC3H2gW+dR2FqaqnLSmTMRcm2CTWRTnNYTj/f rsQSRYyNrA; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] 6lowpan WG items and ROLL WG activities X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Feb 3, 2009, at 3:40 PM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> On Feb 3, 2009, at 1:02 AM, Alexandru Petrescu wrote: >>> Mischa Dohler a =E9crit : [...] >>>> 6LoWPAN: - mainly specifies IPv6 header compression but not = >>>> (optimized) routing per se; >>> Not only Header Compression, 6lowpan WG seems to also be looking at >>> Neighbor Discovery for 802.15.4, which is quite relevant here I = >>> believe, because ZigBee was mentioned recently here. >> HOLD-ON ... We are NOT working on ZIGBEE here. Let's not go there. = >> This is the IETF, we work on IP. > > I think it is good to mention all link-layers which are addressed by > ROLL. The link layer characteristics are of paramount importance on = > the > subnetting and addressing architecture, and thus on the kind of = > protocol > needed. > > (I agree though at IETF we work on IP, independently of the link- = > layer, > and some times dependently on the link-layer: IP-over-foo are = > typical.) I do not think that this is the appropriate ML to have such = discussion. But no we are not here to list all possible link layers (glad we did not do this 20 years ago !). New = link layers will be designed in a near future (especially true for LLN). And by the way Zigbee is not a = PHY/MAC ... > > >>>> - [6lowpan] is stuck to IEEE 802.15.4 radios. >>> I think it is good to list the radios ROLL looks at: >>> IEEE 802.15.4 SP100 http://tinyurl.com/4d3j64 ZigBee HART http://tinyur= l.com/4d3j64 >> There is quite a bit of confusion. Zigbee is non-IP and build above = >> 15.4. We are designing IP-solution and indeed 15.4 is one of the = >> PHY/MAC LLN may run onto. > > I think in the cases a wireless network is made of ZigBee nodes, or > 802.15.4 nodes, the entire network is actually a single subnet. And = > in > these cases Neighbor Discovery protocol is very pertinent for ROLL. Sorry Alex but there is a lot of confusion. Zigbee nodes are NOT = running IP. Out of context here. > > > This would contradict all the inconvenients cited in section 8.1. = > "IPv6 > ND" of protocols-survey draft. HEnce I disagree with this section. I > disagree with it for more reasons, one being: > > protocols-survey draft: >> The fact that all routers must respond to a Router Solicitation = >> requires that the number of routers with a 1-hop neighborhood is = >> small, or there will be a reply implosion. > > Such reply implosion is avoided by the IPv6 ND spec, because it = > requires > the RAs responding to an RS are spaced randomly in time: > > RFC4861 "ND for IPv6": >> 6.2.6. Processing Router Solicitations > [...] >> In all cases, Router Advertisements sent in response to a Router = >> Solicitation MUST be delayed by a random time between 0 and = >> MAX_RA_DELAY_TIME seconds. > > Alex > > > _______________________________________________ > 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 From roll-bounces@ietf.org Tue Feb 3 07:10:59 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5942A3A6BE8; Tue, 3 Feb 2009 07:10:59 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49A553A69BB for ; Tue, 3 Feb 2009 07:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDYKWC5iDwbi for ; Tue, 3 Feb 2009 07:10:57 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 313AB3A6C37 for ; Tue, 3 Feb 2009 07:10:56 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n13F8lH7024823; Tue, 3 Feb 2009 16:08:54 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n13F3ghx004004; Tue, 3 Feb 2009 16:03:55 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n13F29G7001181; Tue, 3 Feb 2009 16:02:09 +0100 Message-ID: <49885C71.7090009@gmail.com> Date: Tue, 03 Feb 2009 16:02:09 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: JP Vasseur References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <4987899C.3090708@gmail.com> <7C6DC187-681B-48DF-AFF1-FE329EA93CA8@cisco.com> <49885744.3050603@gmail.com> In-Reply-To: Cc: roll@ietf.org Subject: Re: [Roll] link-layers for ROLL (was: 6lowpan WG items and ROLL WG activities) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org JP, in previous messages you're suggesting my text about link-layers are = out of context. But I consider perfectly legitimate the following questions: which = link-layers are considered for ROLL WG? How do they present themselves = to the IP stack? Do they all use the typical Ethernet MAC interface? = Or point-to-point links? Do these link-layer offer hints for defining ROLL energy-oriented metrics? Alex JP Vasseur a =E9crit : > = > On Feb 3, 2009, at 3:40 PM, Alexandru Petrescu wrote: > = >> JP Vasseur a =E9crit : >>> On Feb 3, 2009, at 1:02 AM, Alexandru Petrescu wrote: >>>> Mischa Dohler a =E9crit : [...] >>>>> 6LoWPAN: - mainly specifies IPv6 header compression but not = >>>>> (optimized) routing per se; >>>> Not only Header Compression, 6lowpan WG seems to also be looking at >>>> Neighbor Discovery for 802.15.4, which is quite relevant here I = >>>> believe, because ZigBee was mentioned recently here. >>> HOLD-ON ... We are NOT working on ZIGBEE here. Let's not go there. = >>> This is the IETF, we work on IP. >> >> I think it is good to mention all link-layers which are addressed by >> ROLL. The link layer characteristics are of paramount importance on the >> subnetting and addressing architecture, and thus on the kind of protocol >> needed. >> >> (I agree though at IETF we work on IP, independently of the link-layer, >> and some times dependently on the link-layer: IP-over-foo are typical.) > = > I do not think that this is the appropriate ML to have such discussion. = > But no we are not here to list > all possible link layers (glad we did not do this 20 years ago !). New = > link layers will be designed in a > near future (especially true for LLN). And by the way Zigbee is not a = > PHY/MAC ... > = >> >> >>>>> - [6lowpan] is stuck to IEEE 802.15.4 radios. >>>> I think it is good to list the radios ROLL looks at: >>>> IEEE 802.15.4 SP100 http://tinyurl.com/4d3j64 ZigBee HART = >>>> http://tinyurl.com/4d3j64 >>> There is quite a bit of confusion. Zigbee is non-IP and build above = >>> 15.4. We are designing IP-solution and indeed 15.4 is one of the = >>> PHY/MAC LLN may run onto. >> >> I think in the cases a wireless network is made of ZigBee nodes, or >> 802.15.4 nodes, the entire network is actually a single subnet. And in >> these cases Neighbor Discovery protocol is very pertinent for ROLL. > = > Sorry Alex but there is a lot of confusion. Zigbee nodes are NOT running = > IP. > Out of context here. > = >> >> >> This would contradict all the inconvenients cited in section 8.1. "IPv6 >> ND" of protocols-survey draft. HEnce I disagree with this section. I >> disagree with it for more reasons, one being: >> >> protocols-survey draft: >>> The fact that all routers must respond to a Router Solicitation = >>> requires that the number of routers with a 1-hop neighborhood is = >>> small, or there will be a reply implosion. >> >> Such reply implosion is avoided by the IPv6 ND spec, because it requires >> the RAs responding to an RS are spaced randomly in time: >> >> RFC4861 "ND for IPv6": >>> 6.2.6. Processing Router Solicitations >> [...] >>> In all cases, Router Advertisements sent in response to a Router = >>> Solicitation MUST be delayed by a random time between 0 and = >>> MAX_RA_DELAY_TIME seconds. >> >> Alex >> >> >> _______________________________________________ >> 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 From roll-bounces@ietf.org Tue Feb 3 07:20:59 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32AE828C0E1; Tue, 3 Feb 2009 07:20:59 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03EDD28C0E1 for ; Tue, 3 Feb 2009 07:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.498 X-Spam-Level: X-Spam-Status: No, score=-10.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IuszlEhcGCU for ; Tue, 3 Feb 2009 07:20:56 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 39ED028C0CE for ; Tue, 3 Feb 2009 07:20:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,372,1231113600"; d="scan'208";a="32719735" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2009 15:20:33 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n13FKXQp001422; Tue, 3 Feb 2009 16:20:33 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n13FKXGg015245; Tue, 3 Feb 2009 15:20:33 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 16:20:33 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 16:20:32 +0100 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <49885C71.7090009@gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Feb 2009 16:20:32 +0100 References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <4987899C.3090708@gmail.com> <7C6DC187-681B-48DF-AFF1-FE329EA93CA8@cisco.com> <49885744.3050603@gmail.com> <49885C71.7090009@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Feb 2009 15:20:33.0163 (UTC) FILETIME=[F4D0D5B0:01C98612] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4457; t=1233674433; x=1234538433; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20link-layers=20for=20ROLL=20(wa s=3A=206lowpan=20WG=20items=20and=20ROLL=20WG=20activities) |Sender:=20; bh=/ArEuT85F1mi1rW7hxhUUhkMuAqGx1Ki7pb1GZv2x8A=; b=r1emI3ERYGtR3dFFRd85cK+usrcTJYueI+qhIQA6EnHIjJD/vZqK9Vl6BI HH0oIQfrVxGLGaldDymkLnl8NYZSOIw0sESUrI0slEuaO1zDrXUhxMvLO19w LCjYb8L2kQ; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] link-layers for ROLL (was: 6lowpan WG items and ROLL WG activities) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Alex, See how easy to get off-track ... still enjoying the discussion but I = would like to stay a bit focussed on closing the protocol survey ID. On Feb 3, 2009, at 4:02 PM, Alexandru Petrescu wrote: > JP, in previous messages you're suggesting my text about link-layers = > are out of context. > > But I consider perfectly legitimate the following questions: which = > link-layers are considered for ROLL WG? How do they present = > themselves to the IP stack? Do they all use the typical Ethernet = > MAC interface? Or point-to-point links? > > Do these link-layer offer hints for defining ROLL energy-oriented = > metrics? > Look at what I wrote below ... no we do not want to become dependent = of a specific layer of course and list all layers, otherwise why IP ? That said, yes we do want to take into account some of their = properties in routing, the abstraction being performed thanks to = routing metrics. I'm co-authoring this draft to be posted soon, comment welcome. JP. > Alex > > JP Vasseur a =E9crit : >> On Feb 3, 2009, at 3:40 PM, Alexandru Petrescu wrote: >>> JP Vasseur a =E9crit : >>>> On Feb 3, 2009, at 1:02 AM, Alexandru Petrescu wrote: >>>>> Mischa Dohler a =E9crit : [...] >>>>>> 6LoWPAN: - mainly specifies IPv6 header compression but not = >>>>>> (optimized) routing per se; >>>>> Not only Header Compression, 6lowpan WG seems to also be looking = >>>>> at >>>>> Neighbor Discovery for 802.15.4, which is quite relevant here I = >>>>> believe, because ZigBee was mentioned recently here. >>>> HOLD-ON ... We are NOT working on ZIGBEE here. Let's not go = >>>> there. This is the IETF, we work on IP. >>> >>> I think it is good to mention all link-layers which are addressed by >>> ROLL. The link layer characteristics are of paramount importance = >>> on the >>> subnetting and addressing architecture, and thus on the kind of = >>> protocol >>> needed. >>> >>> (I agree though at IETF we work on IP, independently of the link- = >>> layer, >>> and some times dependently on the link-layer: IP-over-foo are = >>> typical.) >> I do not think that this is the appropriate ML to have such = >> discussion. But no we are not here to list >> all possible link layers (glad we did not do this 20 years ago !). = >> New link layers will be designed in a >> near future (especially true for LLN). And by the way Zigbee is not = >> a PHY/MAC ... >>> >>> >>>>>> - [6lowpan] is stuck to IEEE 802.15.4 radios. >>>>> I think it is good to list the radios ROLL looks at: >>>>> IEEE 802.15.4 SP100 http://tinyurl.com/4d3j64 ZigBee HART http://tiny= url.com/4d3j64 >>>> There is quite a bit of confusion. Zigbee is non-IP and build = >>>> above 15.4. We are designing IP-solution and indeed 15.4 is one = >>>> of the PHY/MAC LLN may run onto. >>> >>> I think in the cases a wireless network is made of ZigBee nodes, or >>> 802.15.4 nodes, the entire network is actually a single subnet. = >>> And in >>> these cases Neighbor Discovery protocol is very pertinent for ROLL. >> Sorry Alex but there is a lot of confusion. Zigbee nodes are NOT = >> running IP. >> Out of context here. >>> >>> >>> This would contradict all the inconvenients cited in section 8.1. = >>> "IPv6 >>> ND" of protocols-survey draft. HEnce I disagree with this = >>> section. I >>> disagree with it for more reasons, one being: >>> >>> protocols-survey draft: >>>> The fact that all routers must respond to a Router Solicitation = >>>> requires that the number of routers with a 1-hop neighborhood is = >>>> small, or there will be a reply implosion. >>> >>> Such reply implosion is avoided by the IPv6 ND spec, because it = >>> requires >>> the RAs responding to an RS are spaced randomly in time: >>> >>> RFC4861 "ND for IPv6": >>>> 6.2.6. Processing Router Solicitations >>> [...] >>>> In all cases, Router Advertisements sent in response to a Router = >>>> Solicitation MUST be delayed by a random time between 0 and = >>>> MAX_RA_DELAY_TIME seconds. >>> >>> Alex >>> >>> >>> _______________________________________________ >>> 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 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Feb 3 07:29:34 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A5203A6BE5; Tue, 3 Feb 2009 07:29:34 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28C473A6BE5 for ; Tue, 3 Feb 2009 07:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fk8iD1uts8Vf for ; Tue, 3 Feb 2009 07:29:31 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 81C7F3A6B20 for ; Tue, 3 Feb 2009 07:29:30 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n13FTAeR006785; Tue, 3 Feb 2009 16:29:10 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n13EgPLA016564; Tue, 3 Feb 2009 15:42:38 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n13EgMHe016725; Tue, 3 Feb 2009 15:42:22 +0100 Message-ID: <498857CE.10705@gmail.com> Date: Tue, 03 Feb 2009 15:42:22 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Emmanuel Baccelli References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> In-Reply-To: Cc: ROLL WG Subject: Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review and comments draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Emmanuel, +1 here. Alex Emmanuel Baccelli a =E9crit : > Dear all, > = > I have remained silent since others have been echoing the concerns I had = > pointed out earlier, about the survey document. I want nevertheless to = > reinforce Thomas' point of view now, since I think it is insightful and = > useful in order to move on constructively. > = > Basically, everybody agrees that something special must be done for = > sensor ad hoc connectivity with IP, and everybody wants to reach the = > next phase ASAP (i.e. work on solutions). = > = > However, the lack of consensus on the precise space addressed by ROLL is = > backlashing lately, with the survey document. The blur indeed had a huge = > impact on the document so far, forcing the use of a too broad set of = > goals and evaluation criterias, and endless discussions about the scope = > of the survey. > = > This lack of definition will continue to plague ROLL and the other WGs = > in the same field down the line if it is not addressed upfront, i.e. = > now. I thus also encourage everyone to participate in this urgent and = > needed effort. > = > If the scope of the WG is clearly defined, it should be straightforward = > to write a couple of paragraphs that will get us out of this mess. So = > let's just do it! > = > Cheers > Emmanuel > = > = > = > = > On Tue, Feb 3, 2009 at 2:19 PM, Thomas Heide = > Clausen > wrote: > = > Dear JP, dear ADs, dear WG, > = > For the record, I am not arguing that MANET protocols should be > applied or be applicable -- as you seem to suggest in your email. I > believe that I have stated so repeatedly. > = > I submit, however, that as it is currently exposed, ROLL, MANET and > 6LOW seem to be operating within the same space -- to the untrained > eye, in exactly the same space. My position is that it would be very > unfortunate having one WG creating confusion on the applicability of > the work of itself and of other IETF wg's, by simple omission of > suitable perimeter definitions. = > = > In that sort of situation, the IETF needs to be extra prudent to > make sure to clearly spell out suitable perimeter definitions prior > to, or conjointly with, the first publication cycle. In this case, > before or with the survey I-D. > = > Sincerely, > = > Thomas > = > = > On Feb 3, 2009, at 1:19 PM, JP Vasseur wrote: > = >> Dear WG and ADs, >> >> Two issues are raised here for which we would appreciate ADs' >> point of view and feed-back from the WG. Please see in line. >> >> >> Dear Thomas, >> >> At the risk of repeating myself, I'd like to make a few important >> statements before *hopefully* come to a closure ;-) >> >> -> As you know, many of the ROLL WG active participants have been >> working quite hard to produce a detailed set of requirements, >> discuss how to proceed on the protocol survey document, and other >> ID are in the works. >> -> We managed to get highly experienced contributors in the field >> that have designed and deployed solutions so they not only have an >> excellent expertise of the requirements but also on solutions, >> *-> Yes we need to rush out. Why ? Because proprietary or >> semi-closed non-IP solutions are being deployed at a fairly large >> scale. I do not think that I have to convince anybody on this list >> that this is the WRONG approach for a number of reasons. The >> industry is asking for an IP solution *now*.* >> -> No we do not want to re-invent the wheel (see our presentation >> at the routing plenary in Chicago). Anything that already exists >> MUST (rfc2119 ;-)) be used provided that it meets our >> requirements. And if we can adapt an existing protocol, we are all >> for it ! >> -> Yes these requirements are quite specifics and this is >> precisely why ROLL has been formed, 4 application-specific routing >> requirements have been produced (to reduce the scope). Even if at >> a first sight, it looks very much similar to a MANET issue (and >> there ARE similarities but also very different requirements), >> having to deal with a highly static network of hundreds of >> thousands of battery operated sleeping nodes with 4K of RAM is >> quite specific. Note that this is not a random example, but an >> on-going non-IP deployed network. >> >> And to conclude on this introduction ... after an outstanding >> progress on the WG during the first 6-8 months, we have been >> slowed down dramatically for the last 2 months, thus it is time to >> close and move on to quickly re-charter and start the protocol >> work (hopefully as light as possible) to see IP-based solution >> deployed. I know that we are on the same page, we just need to >> find a good compromise on both "sides". >> >> Nothing new so far, let's move to a proposed resolution - See in lin= e, >> >> On Feb 2, 2009, at 7:37 PM, Thomas Heide Clausen wrote: >> >>> All, >>> >>> I promised a review, and I apologize that I wasn't able to do so >>> before the weekend as originally projected. >>> >>> Other than some typos that Chris and others have pointed out, >>> I'll try to offer my understanding of the problem space and >>> suggest some ways of addressing my main concerns.... >>> >>> My first main concern remain that it is not clear, still, how >>> ROLL positions itself with respect to MANET, 6LOW et. al, all of >>> which appear to be within the same space and within the IETF. >>> This I-D sees ROLL as presented with entirely new problems (the >>> use of "novel" in the abstract, the statement that "existing >>> protocols were not designed with these requirements in mind" seem >>> to confirm this). >>> >>> Looking at the requirements listed, including "low power, low >>> bandwidth, low footprint", these appear similar to those which >>> are also brought forward in e.g. MANET and 6LOW. Reading >>> (quickly, I confess) the various requirements documents of the >>> draft-ietf-roll series present scenarios which are similar to >>> those where MANETs are deployed, and are thought deployed, as well. >>> >>> I also note that many additional (and unstated) characteristics >>> between ROLL and e.g. MANET are the same: mobile, wireless, >>> fragility, auto-configuration, IP routing, interface/link issues... >>> >>> Arguing that, as does this I-D, despite the above impression >>> "ROLL is novel and different" invites asking "how, exactly?" I >>> think that this question is valid, and merits being answered, >>> before the evaluations in this I-D can be judged fairly. >>> >>> Note that I come from a MANET background, and so I *could* >>> interpret from the ROLL discussion that where MANETs may aim for >>> "low power, low bandwidth, ....", ROLL may be able to quantify >>> these as "below this firm threshold" -- i.e. as a sort of >>> "extreme" or "constrained" MANET. >>> >>> This is a personal observation, I note, which would allow me to >>> comprehend how ROLL and MANET are positioned relative to one >>> another -- but one which neither this I-D nor the requirements >>> document spell out or quantify -- or, for that matter, debunk. >>> >>> I think it's critical to understand this, in order to understand >>> the need for a new protocol development. I think it is important >>> to document this understanding in something with more persistency. >>> >>> If what I suggest above makes sense as a way of positioning ROLL >>> and MANET relative to one another, I'd suggest including >>> something to this effect in the survey I-D, as this I-D is the >>> one making a *direct* reference to the applicability of MANET >>> protocols to ROLL. >>> >>> If what I suggest doesn't make sense at all, then I'd be happy to >>> have it debunked and, hopefully, through that debunking a >>> positioning/description that does ring true with us all can be >>> produced? >>> >>> My second main concern is, that I still think that the choice of >>> criteria is unfortunate (not the word, Phill has me convinced on >>> that front, but the actual criteria). Control cost is, by all >>> means, a rather meaningless criteria when taken in isolation. >>> I've sketched a "zero-control-cost" routing protocol (flood all >>> data - say use SMF, also a MANET protocol, and also a rather >>> "mature" I-D and wg item) which would score well on the control >>> cost criteria, but would likely be an extremely bad choice for >>> delivering unicast data. >>> >>> The metric which matters, and which should matter to ROLL in >>> particular, is "the total cost of getting user data through the >>> network, including control cost necessary to set up paths" -- as >>> we know, every packet sent and received costs bandwidth, energy >>> and cycles -- user data no different from contro. >>> >>> According to the criterions as set up by this I-D, a protocol >>> producing "longer than shortest paths" at the benefit of slightly >>> lower control cost would score better than a protocol producing >>> "shortest paths" with slightly higher control cost. This is not >>> hypothetical, btw., there are plenty of studies observing and >>> reflecting upon this regarding the different MANET protocols, in >>> academic literature -- and observed in real networks as well. >>> >>> I note that this trade-off (slightly longer paths for lower >>> control cost) may be perfectly fair, assuming that very low >>> amounts of user data traffic transit through the network. >>> However, I do not see this assumption mentioned as a >>> justification for focusing on the control cost metric and >>> discarding the "path length" or the "total cost of getting user >>> data through the network". >>> >>> I believe that either these assumptions should be made explicit >>> ("there's so little user data traffic in a ROLL network that we >>> do not care about shortest paths") or -- if these assumptions do >>> not hold, that the evaluation criteria are incomplete. >>> >>> I note that it's true that we can always add another criteria ad >>> infinitum, and that's CLEARLY not what we want to do. However >>> when I say "incomplete" in the above, I simply suggest that based >>> on what is presented one cannot draw conclusions based on the >>> evaluation criteria....or, worse, that one draws the wrong >>> conclusions based on the information presented. >> >> It is not easy to answer each of your point without running the >> risk to start a debate that will never end. You raised some >> excellent points that I agree with and others that I firmly >> disagree with ... So let me try to make a few observations: >> 1) As pointed out earlier, yes there are similarities between >> MANET and ROLL. I do not see this as an issue. >> 2) The aim of the protocol survey IS NOT to exclude MANET >> protocols. As mentioned many times on the list, we *only* wanted >> to show that existing protocols, with no change, could not be used >> in LLNs. This has been clarified in the document as your request >> and it HAD to be clarified. >> 3) We could have used two different approaches for the survey: >> - Look at all MUST from the requirements documents >> - Try to derive a subset of necessary but not sufficient criteria, >> which the WG chose to do (consensus). Yes this list is not perfect, >> criteria could be changed, removed or added but looked good enough >> with excellent consensus until LC. >> 4) With regards to 6lowpan (I copy the chair), I do not see any >> overlap at all. Please refer to their charter and WG items. The >> only place that required clarification was the routing >> requirements and I was personally opposed to it but this was >> adopted as a 6lowpan WG item *by consensus*. We're are working >> together and managed to sort this out. This document will be >> 6lowpan specific. >> >> What I want to avoid is an endless discussion on the positioning >> of ROLL, MANET, 6lowpan and quite frankly we could add other WGs >> to the list. >> >> /So what is the bottom line ?/ >> >> We just need to agree on the fact that there is no existing >> protocol that meets the ROLL requirements and move to the next >> step (re-chartering) to select one (hopefully not two) routing >> protocols in light of the routing requirement (NOT the protocol >> survey), which can either be an adapted MANET protocol or a new >> protocol. >> >> Now moving to your proposed resolution. >> >>> >>> >>> So, in a nutshell, I suggest that we address (i) the positioning >>> issue and (ii) the criteria issue thus: >>> >>> o Describe as I proposed above if ROLL and MANETs position >>> themselves as I >>> have deducted. If my deduction is incorrect, then let's quickly >>> iterate on the list >>> as to understand how to do produce an alternative description. If >>> we can't do this, >>> then the conclusion can be that "we do not know how ROLL and >>> MANET position >>> themselves wrt each other", and we could then state that clearly? >>> >>> It *should* not be more than a couple of paragraphs worth of text >>> to add, I gather? >>> >> >> If you find a way to word this, please feel free and I'd be happy >> to help but feel it as necessary ... Any opinion from our RTG and >> INT ADs ? >> >>> o To the criteria, either of: >>> >>> - Add the assumption that "user data traffic is so low that path >>> lengths do not >>> matter nor does the cost of carrying user data traffice" >>> >> >> The motivation for selecting a longer path is not tied to the >> amount of traffic here but the level of constraints. Note that >> this is also true for several other technologies such as MPLS-TE. >> You may have large amount of traffic and still require to follow a >> non-shortest path (constrained based routing). This is detailed in >> several requirements IDs. Criticality of data is of course >> different, thus the requirements for potentially different data >> paths according to packet marking using DSCP. >> >>> - Add a criteria & evaluation of "path length" >>> >>> - Add a criteria & evaluation of "total cost for getting user >>> data through the network" >>> >> >> And we can add many more but if the current protocol do not >> satisfy existing requirements, isn't it sufficient to answer the >> question on whether one can find an existing protocol? >> >>> This would make a large chunk of my concerns and issues vanish, >>> and allow correctly interpreting and evaluating the rest of the >>> document. >> >> That said, question for the WG. Who think that such criteria >> should be added to move forward ? Please reply. >> >>> >>> >>> How does that sound as an approach forward? >>> >> >> Thanks for helping out. >> >> Cheers. >> >> JP. >> >>> Cheers, >>> >>> Thomas >>> >>> On Jan 27, 2009, at 1:00 AM, Internet-Drafts@ietf.org >>> wrote: >>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Routing Over Low power and >>>> Lossy networks Working Group of the IETF. >>>> >>>> Title : Overview of Existing Routing Protocols for Low Power and >>>> Lossy Networks >>>> Author(s) : A. Tavakoli, S. Dawson-Haggerty, P. Levis >>>> Filename : draft-ietf-roll-protocols-survey-05.txt >>>> Pages : 26 >>>> Date : 2009-1-26 >>>> >>>> Networks of low power wireless devices introduce novel IP routing >>>> issues. Low-power wireless devices, such as sensors, >>>> actuators and >>>> smart objects, have difficult constraints: very limited memory, >>>> little processing power, and long sleep periods. As most of the= se >>>> devices are battery-powered, energy efficiency is critically >>>> important. Wireless link qualities can vary significantly >>>> over time, >>>> requiring protocols to make agile decisions yet minimize topology >>>> change energy costs. Routing over such low power and lossy >>>> networks >>>> has novel requirements that existing protocols may not >>>> address. This >>>> document provides a brief survey of the strengths and >>>> weaknesses of >>>> existing protocols with respect to this class of networks. >>>> From this >>>> survey it examines whether existing and mature IETF protocols >>>> can be >>>> used without modification in these networks, or whether >>>> further work >>>> is necessary. >>>> is necessary. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-surv= ey-05.txt >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>> Content-Type: text/plain >>>> Content-ID: <2009-1-26155804.I-D@ietf.org >>>> > >>>> >>>> _______________________________________________ >>>> 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 >> > = > = > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > = > = > On Tue, Feb 3, 2009 at 2:19 PM, Thomas Heide Clausen = > > wrote: > = > Dear JP, dear ADs, dear WG, > = > For the record, I am not arguing that MANET protocols should be > applied or be applicable -- as you seem to suggest in your email. I > believe that I have stated so repeatedly. > = > I submit, however, that as it is currently exposed, ROLL, MANET and > 6LOW seem to be operating within the same space -- to the untrained > eye, in exactly the same space. My position is that it would be very > unfortunate having one WG creating confusion on the applicability of > the work of itself and of other IETF wg's, by simple omission of > suitable perimeter definitions. = > = > In that sort of situation, the IETF needs to be extra prudent to > make sure to clearly spell out suitable perimeter definitions prior > to, or conjointly with, the first publication cycle. In this case, > before or with the survey I-D. > = > Sincerely, > = > Thomas > = > = > On Feb 3, 2009, at 1:19 PM, JP Vasseur wrote: > = >> Dear WG and ADs, >> >> Two issues are raised here for which we would appreciate ADs' >> point of view and feed-back from the WG. Please see in line. >> >> >> Dear Thomas, >> >> At the risk of repeating myself, I'd like to make a few important >> statements before *hopefully* come to a closure ;-) >> >> -> As you know, many of the ROLL WG active participants have been >> working quite hard to produce a detailed set of requirements, >> discuss how to proceed on the protocol survey document, and other >> ID are in the works. >> -> We managed to get highly experienced contributors in the field >> that have designed and deployed solutions so they not only have an >> excellent expertise of the requirements but also on solutions, >> *-> Yes we need to rush out. Why ? Because proprietary or >> semi-closed non-IP solutions are being deployed at a fairly large >> scale. I do not think that I have to convince anybody on this list >> that this is the WRONG approach for a number of reasons. The >> industry is asking for an IP solution *now*.* >> -> No we do not want to re-invent the wheel (see our presentation >> at the routing plenary in Chicago). Anything that already exists >> MUST (rfc2119 ;-)) be used provided that it meets our >> requirements. And if we can adapt an existing protocol, we are all >> for it ! >> -> Yes these requirements are quite specifics and this is >> precisely why ROLL has been formed, 4 application-specific routing >> requirements have been produced (to reduce the scope). Even if at >> a first sight, it looks very much similar to a MANET issue (and >> there ARE similarities but also very different requirements), >> having to deal with a highly static network of hundreds of >> thousands of battery operated sleeping nodes with 4K of RAM is >> quite specific. Note that this is not a random example, but an >> on-going non-IP deployed network. >> >> And to conclude on this introduction ... after an outstanding >> progress on the WG during the first 6-8 months, we have been >> slowed down dramatically for the last 2 months, thus it is time to >> close and move on to quickly re-charter and start the protocol >> work (hopefully as light as possible) to see IP-based solution >> deployed. I know that we are on the same page, we just need to >> find a good compromise on both "sides". >> >> Nothing new so far, let's move to a proposed resolution - See in lin= e, >> >> On Feb 2, 2009, at 7:37 PM, Thomas Heide Clausen wrote: >> >>> All, >>> >>> I promised a review, and I apologize that I wasn't able to do so >>> before the weekend as originally projected. >>> >>> Other than some typos that Chris and others have pointed out, >>> I'll try to offer my understanding of the problem space and >>> suggest some ways of addressing my main concerns.... >>> >>> My first main concern remain that it is not clear, still, how >>> ROLL positions itself with respect to MANET, 6LOW et. al, all of >>> which appear to be within the same space and within the IETF. >>> This I-D sees ROLL as presented with entirely new problems (the >>> use of "novel" in the abstract, the statement that "existing >>> protocols were not designed with these requirements in mind" seem >>> to confirm this). >>> >>> Looking at the requirements listed, including "low power, low >>> bandwidth, low footprint", these appear similar to those which >>> are also brought forward in e.g. MANET and 6LOW. Reading >>> (quickly, I confess) the various requirements documents of the >>> draft-ietf-roll series present scenarios which are similar to >>> those where MANETs are deployed, and are thought deployed, as well. >>> >>> I also note that many additional (and unstated) characteristics >>> between ROLL and e.g. MANET are the same: mobile, wireless, >>> fragility, auto-configuration, IP routing, interface/link issues... >>> >>> Arguing that, as does this I-D, despite the above impression >>> "ROLL is novel and different" invites asking "how, exactly?" I >>> think that this question is valid, and merits being answered, >>> before the evaluations in this I-D can be judged fairly. >>> >>> Note that I come from a MANET background, and so I *could* >>> interpret from the ROLL discussion that where MANETs may aim for >>> "low power, low bandwidth, ....", ROLL may be able to quantify >>> these as "below this firm threshold" -- i.e. as a sort of >>> "extreme" or "constrained" MANET. >>> >>> This is a personal observation, I note, which would allow me to >>> comprehend how ROLL and MANET are positioned relative to one >>> another -- but one which neither this I-D nor the requirements >>> document spell out or quantify -- or, for that matter, debunk. >>> >>> I think it's critical to understand this, in order to understand >>> the need for a new protocol development. I think it is important >>> to document this understanding in something with more persistency. >>> >>> If what I suggest above makes sense as a way of positioning ROLL >>> and MANET relative to one another, I'd suggest including >>> something to this effect in the survey I-D, as this I-D is the >>> one making a *direct* reference to the applicability of MANET >>> protocols to ROLL. >>> >>> If what I suggest doesn't make sense at all, then I'd be happy to >>> have it debunked and, hopefully, through that debunking a >>> positioning/description that does ring true with us all can be >>> produced? >>> >>> My second main concern is, that I still think that the choice of >>> criteria is unfortunate (not the word, Phill has me convinced on >>> that front, but the actual criteria). Control cost is, by all >>> means, a rather meaningless criteria when taken in isolation. >>> I've sketched a "zero-control-cost" routing protocol (flood all >>> data - say use SMF, also a MANET protocol, and also a rather >>> "mature" I-D and wg item) which would score well on the control >>> cost criteria, but would likely be an extremely bad choice for >>> delivering unicast data. >>> >>> The metric which matters, and which should matter to ROLL in >>> particular, is "the total cost of getting user data through the >>> network, including control cost necessary to set up paths" -- as >>> we know, every packet sent and received costs bandwidth, energy >>> and cycles -- user data no different from contro. >>> >>> According to the criterions as set up by this I-D, a protocol >>> producing "longer than shortest paths" at the benefit of slightly >>> lower control cost would score better than a protocol producing >>> "shortest paths" with slightly higher control cost. This is not >>> hypothetical, btw., there are plenty of studies observing and >>> reflecting upon this regarding the different MANET protocols, in >>> academic literature -- and observed in real networks as well. >>> >>> I note that this trade-off (slightly longer paths for lower >>> control cost) may be perfectly fair, assuming that very low >>> amounts of user data traffic transit through the network. >>> However, I do not see this assumption mentioned as a >>> justification for focusing on the control cost metric and >>> discarding the "path length" or the "total cost of getting user >>> data through the network". >>> >>> I believe that either these assumptions should be made explicit >>> ("there's so little user data traffic in a ROLL network that we >>> do not care about shortest paths") or -- if these assumptions do >>> not hold, that the evaluation criteria are incomplete. >>> >>> I note that it's true that we can always add another criteria ad >>> infinitum, and that's CLEARLY not what we want to do. However >>> when I say "incomplete" in the above, I simply suggest that based >>> on what is presented one cannot draw conclusions based on the >>> evaluation criteria....or, worse, that one draws the wrong >>> conclusions based on the information presented. >> >> It is not easy to answer each of your point without running the >> risk to start a debate that will never end. You raised some >> excellent points that I agree with and others that I firmly >> disagree with ... So let me try to make a few observations: >> 1) As pointed out earlier, yes there are similarities between >> MANET and ROLL. I do not see this as an issue. >> 2) The aim of the protocol survey IS NOT to exclude MANET >> protocols. As mentioned many times on the list, we *only* wanted >> to show that existing protocols, with no change, could not be used >> in LLNs. This has been clarified in the document as your request >> and it HAD to be clarified. >> 3) We could have used two different approaches for the survey: >> - Look at all MUST from the requirements documents >> - Try to derive a subset of necessary but not sufficient criteria, >> which the WG chose to do (consensus). Yes this list is not perfect, >> criteria could be changed, removed or added but looked good enough >> with excellent consensus until LC. >> 4) With regards to 6lowpan (I copy the chair), I do not see any >> overlap at all. Please refer to their charter and WG items. The >> only place that required clarification was the routing >> requirements and I was personally opposed to it but this was >> adopted as a 6lowpan WG item *by consensus*. We're are working >> together and managed to sort this out. This document will be >> 6lowpan specific. >> >> What I want to avoid is an endless discussion on the positioning >> of ROLL, MANET, 6lowpan and quite frankly we could add other WGs >> to the list. >> >> /So what is the bottom line ?/ >> >> We just need to agree on the fact that there is no existing >> protocol that meets the ROLL requirements and move to the next >> step (re-chartering) to select one (hopefully not two) routing >> protocols in light of the routing requirement (NOT the protocol >> survey), which can either be an adapted MANET protocol or a new >> protocol. >> >> Now moving to your proposed resolution. >> >>> >>> >>> So, in a nutshell, I suggest that we address (i) the positioning >>> issue and (ii) the criteria issue thus: >>> >>> o Describe as I proposed above if ROLL and MANETs position >>> themselves as I >>> have deducted. If my deduction is incorrect, then let's quickly >>> iterate on the list >>> as to understand how to do produce an alternative description. If >>> we can't do this, >>> then the conclusion can be that "we do not know how ROLL and >>> MANET position >>> themselves wrt each other", and we could then state that clearly? >>> >>> It *should* not be more than a couple of paragraphs worth of text >>> to add, I gather? >>> >> >> If you find a way to word this, please feel free and I'd be happy >> to help but feel it as necessary ... Any opinion from our RTG and >> INT ADs ? >> >>> o To the criteria, either of: >>> >>> - Add the assumption that "user data traffic is so low that path >>> lengths do not >>> matter nor does the cost of carrying user data traffice" >>> >> >> The motivation for selecting a longer path is not tied to the >> amount of traffic here but the level of constraints. Note that >> this is also true for several other technologies such as MPLS-TE. >> You may have large amount of traffic and still require to follow a >> non-shortest path (constrained based routing). This is detailed in >> several requirements IDs. Criticality of data is of course >> different, thus the requirements for potentially different data >> paths according to packet marking using DSCP. >> >>> - Add a criteria & evaluation of "path length" >>> >>> - Add a criteria & evaluation of "total cost for getting user >>> data through the network" >>> >> >> And we can add many more but if the current protocol do not >> satisfy existing requirements, isn't it sufficient to answer the >> question on whether one can find an existing protocol? >> >>> This would make a large chunk of my concerns and issues vanish, >>> and allow correctly interpreting and evaluating the rest of the >>> document. >> >> That said, question for the WG. Who think that such criteria >> should be added to move forward ? Please reply. >> >>> >>> >>> How does that sound as an approach forward? >>> >> >> Thanks for helping out. >> >> Cheers. >> >> JP. >> >>> Cheers, >>> >>> Thomas >>> >>> On Jan 27, 2009, at 1:00 AM, Internet-Drafts@ietf.org >>> wrote: >>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Routing Over Low power and >>>> Lossy networks Working Group of the IETF. >>>> >>>> Title : Overview of Existing Routing Protocols for Low Power and >>>> Lossy Networks >>>> Author(s) : A. Tavakoli, S. Dawson-Haggerty, P. Levis >>>> Filename : draft-ietf-roll-protocols-survey-05.txt >>>> Pages : 26 >>>> Date : 2009-1-26 >>>> >>>> Networks of low power wireless devices introduce novel IP routing >>>> issues. Low-power wireless devices, such as sensors, >>>> actuators and >>>> smart objects, have difficult constraints: very limited memory, >>>> little processing power, and long sleep periods. As most of the= se >>>> devices are battery-powered, energy efficiency is critically >>>> important. Wireless link qualities can vary significantly >>>> over time, >>>> requiring protocols to make agile decisions yet minimize topology >>>> change energy costs. Routing over such low power and lossy >>>> networks >>>> has novel requirements that existing protocols may not >>>> address. This >>>> document provides a brief survey of the strengths and >>>> weaknesses of >>>> existing protocols with respect to this class of networks. >>>> From this >>>> survey it examines whether existing and mature IETF protocols >>>> can be >>>> used without modification in these networks, or whether >>>> further work >>>> is necessary. >>>> is necessary. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-surv= ey-05.txt >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>> Content-Type: text/plain >>>> Content-ID: <2009-1-26155804.I-D@ietf.org >>>> > >>>> >>>> _______________________________________________ >>>> 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 >> > = > = > _______________________________________________ > 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 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Feb 3 07:38:09 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77C7D3A68B1; Tue, 3 Feb 2009 07:38:09 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0F123A672F for ; Tue, 3 Feb 2009 07:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFejs5GX6QCV for ; Tue, 3 Feb 2009 07:38:07 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id A5DA03A68EF for ; Tue, 3 Feb 2009 07:38:06 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n13Fb2ag011274; Tue, 3 Feb 2009 16:37:28 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n13EKvC4031169; Tue, 3 Feb 2009 15:20:57 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n13EKrQo027777; Tue, 3 Feb 2009 15:20:54 +0100 Message-ID: <498852C5.1050503@gmail.com> Date: Tue, 03 Feb 2009 15:20:53 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: JP Vasseur References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> In-Reply-To: <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> Cc: Arsalan Tavakoli , "David E. Culler" , stevedh@cs.berkeley.edu, roll@ietf.org, Ross Callon Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org JP Vasseur a =E9crit : > Hi Alex, > = > On Feb 3, 2009, at 12:21 AM, Alexandru Petrescu wrote: > = >> Mischa Dohler a =E9crit : [...] >>> As for your proposition, I have another one: Why don't we stop = >>> here and get on with the actual protocol design stage, >> = >> Sorry, which protocol do we mean to go on to protocol design stage? >> = >> = >> = >> Could one imagine starting from scratch designing a new protocol? >> = > = > We have detailed routing requirements documents. Should we = > re-charter, the process gets quite simple. Look at different = > candidates and how close they are to the requirements. Then select = > one or two (in which case we need clear applicability statement). And > yes if we can use an adapted existing protocol, then great. I agree in principle. But what's then the implication of of the protocols-survey draft on the = next-stage developments? The protocols-survey draft clearly puts NEMO protocol out of scope: > This document does not examine the Network Mobility Basic Support = > Protocol (NEMO RFC 3963 [RFC3963]) because it is not a routing = > protocol. If protocols-survey draft gets published as is, now, this means NEMO = protocol is not going to be considered. Regardless of the mentioning of = the "mobility" aspects in the requirements. Alex _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Feb 3 07:38:36 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4CF23A6C3F; Tue, 3 Feb 2009 07:38:36 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24EAF3A68EF for ; Tue, 3 Feb 2009 07:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80geJSYXbUVJ for ; Tue, 3 Feb 2009 07:38:30 -0800 (PST) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by core3.amsl.com (Postfix) with ESMTP id 7FD9C3A6C3F for ; Tue, 3 Feb 2009 07:38:29 -0800 (PST) Received: by ewy14 with SMTP id 14so2503623ewy.13 for ; Tue, 03 Feb 2009 07:38:08 -0800 (PST) Received: by 10.210.19.16 with SMTP id 16mr396778ebs.73.1233675488066; Tue, 03 Feb 2009 07:38:08 -0800 (PST) Received: from ?192.168.112.243? (sphinx.lix.polytechnique.fr [129.104.11.1]) by mx.google.com with ESMTPS id 28sm109724eye.59.2009.02.03.07.38.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 03 Feb 2009 07:38:06 -0800 (PST) Message-ID: <498864DB.6070203@polytechnique.edu> Date: Tue, 03 Feb 2009 16:38:03 +0100 From: Ulrich Herberg Organization: Ecole Polytechnique User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 To: Alexandru Petrescu References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498857CE.10705@gmail.com> In-Reply-To: <498857CE.10705@gmail.com> X-Enigmail-Version: 0.95.7 Cc: ROLL WG Subject: Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review and comments draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi, I agree with Emmanuel and Alex. I think it is very important to define the "role of ROLL" with respect to similar working groups such as 6lowpan and MANET. If this is delayed, it might backfire very soon when going into the protocol design phase. As said in one of my former emails, it is possible that the protocol survey ID is not the right place, but somewhere -- either in another document or in the charter -- ROLL should place itself (before the protocol survey is published) Cheers, Ulrich Alexandru Petrescu wrote: > Emmanuel, +1 here. > > Alex > > Emmanuel Baccelli a =E9crit : >> Dear all, >> >> I have remained silent since others have been echoing the concerns I >> had pointed out earlier, about the survey document. I want >> nevertheless to reinforce Thomas' point of view now, since I think it >> is insightful and useful in order to move on constructively. >> >> Basically, everybody agrees that something special must be done for >> sensor ad hoc connectivity with IP, and everybody wants to reach the >> next phase ASAP (i.e. work on solutions). >> However, the lack of consensus on the precise space addressed by ROLL >> is backlashing lately, with the survey document. The blur indeed had >> a huge impact on the document so far, forcing the use of a too broad >> set of goals and evaluation criterias, and endless discussions about >> the scope of the survey. >> >> This lack of definition will continue to plague ROLL and the other >> WGs in the same field down the line if it is not addressed upfront, >> i.e. now. I thus also encourage everyone to participate in this >> urgent and needed effort. >> >> If the scope of the WG is clearly defined, it should be >> straightforward to write a couple of paragraphs that will get us out >> of this mess. So let's just do it! >> >> Cheers >> Emmanuel >> >> >> >> >> On Tue, Feb 3, 2009 at 2:19 PM, Thomas Heide Clausen >> > wrote: >> >> Dear JP, dear ADs, dear WG, >> >> For the record, I am not arguing that MANET protocols should be >> applied or be applicable -- as you seem to suggest in your email. I >> believe that I have stated so repeatedly. >> >> I submit, however, that as it is currently exposed, ROLL, MANET and >> 6LOW seem to be operating within the same space -- to the untrained >> eye, in exactly the same space. My position is that it would be very >> unfortunate having one WG creating confusion on the applicability of >> the work of itself and of other IETF wg's, by simple omission of >> suitable perimeter definitions. >> In that sort of situation, the IETF needs to be extra prudent to >> make sure to clearly spell out suitable perimeter definitions prior >> to, or conjointly with, the first publication cycle. In this case, >> before or with the survey I-D. >> >> Sincerely, >> >> Thomas >> >> >> On Feb 3, 2009, at 1:19 PM, JP Vasseur wrote: >> >>> Dear WG and ADs, >>> >>> Two issues are raised here for which we would appreciate ADs' >>> point of view and feed-back from the WG. Please see in line. >>> >>> >>> Dear Thomas, >>> >>> At the risk of repeating myself, I'd like to make a few important >>> statements before *hopefully* come to a closure ;-) >>> >>> -> As you know, many of the ROLL WG active participants have been >>> working quite hard to produce a detailed set of requirements, >>> discuss how to proceed on the protocol survey document, and other >>> ID are in the works. >>> -> We managed to get highly experienced contributors in the field >>> that have designed and deployed solutions so they not only have an >>> excellent expertise of the requirements but also on solutions, >>> *-> Yes we need to rush out. Why ? Because proprietary or >>> semi-closed non-IP solutions are being deployed at a fairly large >>> scale. I do not think that I have to convince anybody on this list >>> that this is the WRONG approach for a number of reasons. The >>> industry is asking for an IP solution *now*.* >>> -> No we do not want to re-invent the wheel (see our presentation >>> at the routing plenary in Chicago). Anything that already exists >>> MUST (rfc2119 ;-)) be used provided that it meets our >>> requirements. And if we can adapt an existing protocol, we are all >>> for it ! >>> -> Yes these requirements are quite specifics and this is >>> precisely why ROLL has been formed, 4 application-specific routing >>> requirements have been produced (to reduce the scope). Even if at >>> a first sight, it looks very much similar to a MANET issue (and >>> there ARE similarities but also very different requirements), >>> having to deal with a highly static network of hundreds of >>> thousands of battery operated sleeping nodes with 4K of RAM is >>> quite specific. Note that this is not a random example, but an >>> on-going non-IP deployed network. >>> >>> And to conclude on this introduction ... after an outstanding >>> progress on the WG during the first 6-8 months, we have been >>> slowed down dramatically for the last 2 months, thus it is time to >>> close and move on to quickly re-charter and start the protocol >>> work (hopefully as light as possible) to see IP-based solution >>> deployed. I know that we are on the same page, we just need to >>> find a good compromise on both "sides". >>> >>> Nothing new so far, let's move to a proposed resolution - See in >>> line, >>> >>> On Feb 2, 2009, at 7:37 PM, Thomas Heide Clausen wrote: >>> >>>> All, >>>> >>>> I promised a review, and I apologize that I wasn't able to do so >>>> before the weekend as originally projected. >>>> >>>> Other than some typos that Chris and others have pointed out, >>>> I'll try to offer my understanding of the problem space and >>>> suggest some ways of addressing my main concerns.... >>>> >>>> My first main concern remain that it is not clear, still, how >>>> ROLL positions itself with respect to MANET, 6LOW et. al, all of >>>> which appear to be within the same space and within the IETF. >>>> This I-D sees ROLL as presented with entirely new problems (the >>>> use of "novel" in the abstract, the statement that "existing >>>> protocols were not designed with these requirements in mind" seem >>>> to confirm this). >>>> >>>> Looking at the requirements listed, including "low power, low >>>> bandwidth, low footprint", these appear similar to those which >>>> are also brought forward in e.g. MANET and 6LOW. Reading >>>> (quickly, I confess) the various requirements documents of the >>>> draft-ietf-roll series present scenarios which are similar to >>>> those where MANETs are deployed, and are thought deployed, as >>>> well. >>>> >>>> I also note that many additional (and unstated) characteristics >>>> between ROLL and e.g. MANET are the same: mobile, wireless, >>>> fragility, auto-configuration, IP routing, interface/link >>>> issues... >>>> >>>> Arguing that, as does this I-D, despite the above impression >>>> "ROLL is novel and different" invites asking "how, exactly?" I >>>> think that this question is valid, and merits being answered, >>>> before the evaluations in this I-D can be judged fairly. >>>> >>>> Note that I come from a MANET background, and so I *could* >>>> interpret from the ROLL discussion that where MANETs may aim for >>>> "low power, low bandwidth, ....", ROLL may be able to quantify >>>> these as "below this firm threshold" -- i.e. as a sort of >>>> "extreme" or "constrained" MANET. >>>> >>>> This is a personal observation, I note, which would allow me to >>>> comprehend how ROLL and MANET are positioned relative to one >>>> another -- but one which neither this I-D nor the requirements >>>> document spell out or quantify -- or, for that matter, debunk. >>>> >>>> I think it's critical to understand this, in order to understand >>>> the need for a new protocol development. I think it is important >>>> to document this understanding in something with more persistency. >>>> >>>> If what I suggest above makes sense as a way of positioning ROLL >>>> and MANET relative to one another, I'd suggest including >>>> something to this effect in the survey I-D, as this I-D is the >>>> one making a *direct* reference to the applicability of MANET >>>> protocols to ROLL. >>>> >>>> If what I suggest doesn't make sense at all, then I'd be happy to >>>> have it debunked and, hopefully, through that debunking a >>>> positioning/description that does ring true with us all can be >>>> produced? >>>> >>>> My second main concern is, that I still think that the choice of >>>> criteria is unfortunate (not the word, Phill has me convinced on >>>> that front, but the actual criteria). Control cost is, by all >>>> means, a rather meaningless criteria when taken in isolation. >>>> I've sketched a "zero-control-cost" routing protocol (flood all >>>> data - say use SMF, also a MANET protocol, and also a rather >>>> "mature" I-D and wg item) which would score well on the control >>>> cost criteria, but would likely be an extremely bad choice for >>>> delivering unicast data. >>>> >>>> The metric which matters, and which should matter to ROLL in >>>> particular, is "the total cost of getting user data through the >>>> network, including control cost necessary to set up paths" -- as >>>> we know, every packet sent and received costs bandwidth, energy >>>> and cycles -- user data no different from contro. >>>> >>>> According to the criterions as set up by this I-D, a protocol >>>> producing "longer than shortest paths" at the benefit of slightly >>>> lower control cost would score better than a protocol producing >>>> "shortest paths" with slightly higher control cost. This is not >>>> hypothetical, btw., there are plenty of studies observing and >>>> reflecting upon this regarding the different MANET protocols, in >>>> academic literature -- and observed in real networks as well. >>>> >>>> I note that this trade-off (slightly longer paths for lower >>>> control cost) may be perfectly fair, assuming that very low >>>> amounts of user data traffic transit through the network. >>>> However, I do not see this assumption mentioned as a >>>> justification for focusing on the control cost metric and >>>> discarding the "path length" or the "total cost of getting user >>>> data through the network". >>>> >>>> I believe that either these assumptions should be made explicit >>>> ("there's so little user data traffic in a ROLL network that we >>>> do not care about shortest paths") or -- if these assumptions do >>>> not hold, that the evaluation criteria are incomplete. >>>> >>>> I note that it's true that we can always add another criteria ad >>>> infinitum, and that's CLEARLY not what we want to do. However >>>> when I say "incomplete" in the above, I simply suggest that based >>>> on what is presented one cannot draw conclusions based on the >>>> evaluation criteria....or, worse, that one draws the wrong >>>> conclusions based on the information presented. >>> >>> It is not easy to answer each of your point without running the >>> risk to start a debate that will never end. You raised some >>> excellent points that I agree with and others that I firmly >>> disagree with ... So let me try to make a few observations: >>> 1) As pointed out earlier, yes there are similarities between >>> MANET and ROLL. I do not see this as an issue. >>> 2) The aim of the protocol survey IS NOT to exclude MANET >>> protocols. As mentioned many times on the list, we *only* wanted >>> to show that existing protocols, with no change, could not be used >>> in LLNs. This has been clarified in the document as your request >>> and it HAD to be clarified. >>> 3) We could have used two different approaches for the survey: >>> - Look at all MUST from the requirements documents >>> - Try to derive a subset of necessary but not sufficient criteria, >>> which the WG chose to do (consensus). Yes this list is not perfect, >>> criteria could be changed, removed or added but looked good enough >>> with excellent consensus until LC. >>> 4) With regards to 6lowpan (I copy the chair), I do not see any >>> overlap at all. Please refer to their charter and WG items. The >>> only place that required clarification was the routing >>> requirements and I was personally opposed to it but this was >>> adopted as a 6lowpan WG item *by consensus*. We're are working >>> together and managed to sort this out. This document will be >>> 6lowpan specific. >>> >>> What I want to avoid is an endless discussion on the positioning >>> of ROLL, MANET, 6lowpan and quite frankly we could add other WGs >>> to the list. >>> >>> /So what is the bottom line ?/ >>> >>> We just need to agree on the fact that there is no existing >>> protocol that meets the ROLL requirements and move to the next >>> step (re-chartering) to select one (hopefully not two) routing >>> protocols in light of the routing requirement (NOT the protocol >>> survey), which can either be an adapted MANET protocol or a new >>> protocol. >>> >>> Now moving to your proposed resolution. >>> >>>> >>>> >>>> So, in a nutshell, I suggest that we address (i) the positioning >>>> issue and (ii) the criteria issue thus: >>>> >>>> o Describe as I proposed above if ROLL and MANETs position >>>> themselves as I >>>> have deducted. If my deduction is incorrect, then let's quickly >>>> iterate on the list >>>> as to understand how to do produce an alternative description. If >>>> we can't do this, >>>> then the conclusion can be that "we do not know how ROLL and >>>> MANET position >>>> themselves wrt each other", and we could then state that clearly? >>>> >>>> It *should* not be more than a couple of paragraphs worth of text >>>> to add, I gather? >>>> >>> >>> If you find a way to word this, please feel free and I'd be happy >>> to help but feel it as necessary ... Any opinion from our RTG and >>> INT ADs ? >>> >>>> o To the criteria, either of: >>>> >>>> - Add the assumption that "user data traffic is so low that path >>>> lengths do not >>>> matter nor does the cost of carrying user data traffice" >>>> >>> >>> The motivation for selecting a longer path is not tied to the >>> amount of traffic here but the level of constraints. Note that >>> this is also true for several other technologies such as MPLS-TE. >>> You may have large amount of traffic and still require to follow a >>> non-shortest path (constrained based routing). This is detailed in >>> several requirements IDs. Criticality of data is of course >>> different, thus the requirements for potentially different data >>> paths according to packet marking using DSCP. >>> >>>> - Add a criteria & evaluation of "path length" >>>> >>>> - Add a criteria & evaluation of "total cost for getting user >>>> data through the network" >>>> >>> >>> And we can add many more but if the current protocol do not >>> satisfy existing requirements, isn't it sufficient to answer the >>> question on whether one can find an existing protocol? >>> >>>> This would make a large chunk of my concerns and issues vanish, >>>> and allow correctly interpreting and evaluating the rest of the >>>> document. >>> >>> That said, question for the WG. Who think that such criteria >>> should be added to move forward ? Please reply. >>> >>>> >>>> >>>> How does that sound as an approach forward? >>>> >>> >>> Thanks for helping out. >>> >>> Cheers. >>> >>> JP. >>> >>>> Cheers, >>>> >>>> Thomas >>>> >>>> On Jan 27, 2009, at 1:00 AM, Internet-Drafts@ietf.org >>>> wrote: >>>> >>>>> A New Internet-Draft is available from the on-line >>>>> Internet-Drafts >>>>> directories. >>>>> This draft is a work item of the Routing Over Low power and >>>>> Lossy networks Working Group of the IETF. >>>>> >>>>> Title : Overview of Existing Routing Protocols for Low Power and >>>>> Lossy Networks >>>>> Author(s) : A. Tavakoli, S. Dawson-Haggerty, P. Levis >>>>> Filename : draft-ietf-roll-protocols-survey-05.txt >>>>> Pages : 26 >>>>> Date : 2009-1-26 >>>>> >>>>> Networks of low power wireless devices introduce novel IP routing >>>>> issues. Low-power wireless devices, such as sensors, >>>>> actuators and >>>>> smart objects, have difficult constraints: very limited memory, >>>>> little processing power, and long sleep periods. As most of >>>>> these >>>>> devices are battery-powered, energy efficiency is critically >>>>> important. Wireless link qualities can vary significantly >>>>> over time, >>>>> requiring protocols to make agile decisions yet minimize >>>>> topology >>>>> change energy costs. Routing over such low power and lossy >>>>> networks >>>>> has novel requirements that existing protocols may not >>>>> address. This >>>>> document provides a brief survey of the strengths and >>>>> weaknesses of >>>>> existing protocols with respect to this class of networks. >>>>> From this >>>>> survey it examines whether existing and mature IETF protocols >>>>> can be >>>>> used without modification in these networks, or whether >>>>> further work >>>>> is necessary. >>>>> is necessary. >>>>> >>>>> A URL for this Internet-Draft is: >>>>> = >>>>> http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-survey-= 05.txt >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> Below is the data which will enable a MIME compliant mail reader >>>>> implementation to automatically retrieve the ASCII version of the >>>>> Internet-Draft. >>>>> Content-Type: text/plain >>>>> Content-ID: <2009-1-26155804.I-D@ietf.org >>>>> > >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> >> On Tue, Feb 3, 2009 at 2:19 PM, Thomas Heide Clausen >> > wrote: >> >> Dear JP, dear ADs, dear WG, >> >> For the record, I am not arguing that MANET protocols should be >> applied or be applicable -- as you seem to suggest in your email. I >> believe that I have stated so repeatedly. >> >> I submit, however, that as it is currently exposed, ROLL, MANET and >> 6LOW seem to be operating within the same space -- to the untrained >> eye, in exactly the same space. My position is that it would be very >> unfortunate having one WG creating confusion on the applicability of >> the work of itself and of other IETF wg's, by simple omission of >> suitable perimeter definitions. >> In that sort of situation, the IETF needs to be extra prudent to >> make sure to clearly spell out suitable perimeter definitions prior >> to, or conjointly with, the first publication cycle. In this case, >> before or with the survey I-D. >> >> Sincerely, >> >> Thomas >> >> >> On Feb 3, 2009, at 1:19 PM, JP Vasseur wrote: >> >>> Dear WG and ADs, >>> >>> Two issues are raised here for which we would appreciate ADs' >>> point of view and feed-back from the WG. Please see in line. >>> >>> >>> Dear Thomas, >>> >>> At the risk of repeating myself, I'd like to make a few important >>> statements before *hopefully* come to a closure ;-) >>> >>> -> As you know, many of the ROLL WG active participants have been >>> working quite hard to produce a detailed set of requirements, >>> discuss how to proceed on the protocol survey document, and other >>> ID are in the works. >>> -> We managed to get highly experienced contributors in the field >>> that have designed and deployed solutions so they not only have an >>> excellent expertise of the requirements but also on solutions, >>> *-> Yes we need to rush out. Why ? Because proprietary or >>> semi-closed non-IP solutions are being deployed at a fairly large >>> scale. I do not think that I have to convince anybody on this list >>> that this is the WRONG approach for a number of reasons. The >>> industry is asking for an IP solution *now*.* >>> -> No we do not want to re-invent the wheel (see our presentation >>> at the routing plenary in Chicago). Anything that already exists >>> MUST (rfc2119 ;-)) be used provided that it meets our >>> requirements. And if we can adapt an existing protocol, we are all >>> for it ! >>> -> Yes these requirements are quite specifics and this is >>> precisely why ROLL has been formed, 4 application-specific routing >>> requirements have been produced (to reduce the scope). Even if at >>> a first sight, it looks very much similar to a MANET issue (and >>> there ARE similarities but also very different requirements), >>> having to deal with a highly static network of hundreds of >>> thousands of battery operated sleeping nodes with 4K of RAM is >>> quite specific. Note that this is not a random example, but an >>> on-going non-IP deployed network. >>> >>> And to conclude on this introduction ... after an outstanding >>> progress on the WG during the first 6-8 months, we have been >>> slowed down dramatically for the last 2 months, thus it is time to >>> close and move on to quickly re-charter and start the protocol >>> work (hopefully as light as possible) to see IP-based solution >>> deployed. I know that we are on the same page, we just need to >>> find a good compromise on both "sides". >>> >>> Nothing new so far, let's move to a proposed resolution - See in >>> line, >>> >>> On Feb 2, 2009, at 7:37 PM, Thomas Heide Clausen wrote: >>> >>>> All, >>>> >>>> I promised a review, and I apologize that I wasn't able to do so >>>> before the weekend as originally projected. >>>> >>>> Other than some typos that Chris and others have pointed out, >>>> I'll try to offer my understanding of the problem space and >>>> suggest some ways of addressing my main concerns.... >>>> >>>> My first main concern remain that it is not clear, still, how >>>> ROLL positions itself with respect to MANET, 6LOW et. al, all of >>>> which appear to be within the same space and within the IETF. >>>> This I-D sees ROLL as presented with entirely new problems (the >>>> use of "novel" in the abstract, the statement that "existing >>>> protocols were not designed with these requirements in mind" seem >>>> to confirm this). >>>> >>>> Looking at the requirements listed, including "low power, low >>>> bandwidth, low footprint", these appear similar to those which >>>> are also brought forward in e.g. MANET and 6LOW. Reading >>>> (quickly, I confess) the various requirements documents of the >>>> draft-ietf-roll series present scenarios which are similar to >>>> those where MANETs are deployed, and are thought deployed, as >>>> well. >>>> >>>> I also note that many additional (and unstated) characteristics >>>> between ROLL and e.g. MANET are the same: mobile, wireless, >>>> fragility, auto-configuration, IP routing, interface/link >>>> issues... >>>> >>>> Arguing that, as does this I-D, despite the above impression >>>> "ROLL is novel and different" invites asking "how, exactly?" I >>>> think that this question is valid, and merits being answered, >>>> before the evaluations in this I-D can be judged fairly. >>>> >>>> Note that I come from a MANET background, and so I *could* >>>> interpret from the ROLL discussion that where MANETs may aim for >>>> "low power, low bandwidth, ....", ROLL may be able to quantify >>>> these as "below this firm threshold" -- i.e. as a sort of >>>> "extreme" or "constrained" MANET. >>>> >>>> This is a personal observation, I note, which would allow me to >>>> comprehend how ROLL and MANET are positioned relative to one >>>> another -- but one which neither this I-D nor the requirements >>>> document spell out or quantify -- or, for that matter, debunk. >>>> >>>> I think it's critical to understand this, in order to understand >>>> the need for a new protocol development. I think it is important >>>> to document this understanding in something with more persistency. >>>> >>>> If what I suggest above makes sense as a way of positioning ROLL >>>> and MANET relative to one another, I'd suggest including >>>> something to this effect in the survey I-D, as this I-D is the >>>> one making a *direct* reference to the applicability of MANET >>>> protocols to ROLL. >>>> >>>> If what I suggest doesn't make sense at all, then I'd be happy to >>>> have it debunked and, hopefully, through that debunking a >>>> positioning/description that does ring true with us all can be >>>> produced? >>>> >>>> My second main concern is, that I still think that the choice of >>>> criteria is unfortunate (not the word, Phill has me convinced on >>>> that front, but the actual criteria). Control cost is, by all >>>> means, a rather meaningless criteria when taken in isolation. >>>> I've sketched a "zero-control-cost" routing protocol (flood all >>>> data - say use SMF, also a MANET protocol, and also a rather >>>> "mature" I-D and wg item) which would score well on the control >>>> cost criteria, but would likely be an extremely bad choice for >>>> delivering unicast data. >>>> >>>> The metric which matters, and which should matter to ROLL in >>>> particular, is "the total cost of getting user data through the >>>> network, including control cost necessary to set up paths" -- as >>>> we know, every packet sent and received costs bandwidth, energy >>>> and cycles -- user data no different from contro. >>>> >>>> According to the criterions as set up by this I-D, a protocol >>>> producing "longer than shortest paths" at the benefit of slightly >>>> lower control cost would score better than a protocol producing >>>> "shortest paths" with slightly higher control cost. This is not >>>> hypothetical, btw., there are plenty of studies observing and >>>> reflecting upon this regarding the different MANET protocols, in >>>> academic literature -- and observed in real networks as well. >>>> >>>> I note that this trade-off (slightly longer paths for lower >>>> control cost) may be perfectly fair, assuming that very low >>>> amounts of user data traffic transit through the network. >>>> However, I do not see this assumption mentioned as a >>>> justification for focusing on the control cost metric and >>>> discarding the "path length" or the "total cost of getting user >>>> data through the network". >>>> >>>> I believe that either these assumptions should be made explicit >>>> ("there's so little user data traffic in a ROLL network that we >>>> do not care about shortest paths") or -- if these assumptions do >>>> not hold, that the evaluation criteria are incomplete. >>>> >>>> I note that it's true that we can always add another criteria ad >>>> infinitum, and that's CLEARLY not what we want to do. However >>>> when I say "incomplete" in the above, I simply suggest that based >>>> on what is presented one cannot draw conclusions based on the >>>> evaluation criteria....or, worse, that one draws the wrong >>>> conclusions based on the information presented. >>> >>> It is not easy to answer each of your point without running the >>> risk to start a debate that will never end. You raised some >>> excellent points that I agree with and others that I firmly >>> disagree with ... So let me try to make a few observations: >>> 1) As pointed out earlier, yes there are similarities between >>> MANET and ROLL. I do not see this as an issue. >>> 2) The aim of the protocol survey IS NOT to exclude MANET >>> protocols. As mentioned many times on the list, we *only* wanted >>> to show that existing protocols, with no change, could not be used >>> in LLNs. This has been clarified in the document as your request >>> and it HAD to be clarified. >>> 3) We could have used two different approaches for the survey: >>> - Look at all MUST from the requirements documents >>> - Try to derive a subset of necessary but not sufficient criteria, >>> which the WG chose to do (consensus). Yes this list is not perfect, >>> criteria could be changed, removed or added but looked good enough >>> with excellent consensus until LC. >>> 4) With regards to 6lowpan (I copy the chair), I do not see any >>> overlap at all. Please refer to their charter and WG items. The >>> only place that required clarification was the routing >>> requirements and I was personally opposed to it but this was >>> adopted as a 6lowpan WG item *by consensus*. We're are working >>> together and managed to sort this out. This document will be >>> 6lowpan specific. >>> >>> What I want to avoid is an endless discussion on the positioning >>> of ROLL, MANET, 6lowpan and quite frankly we could add other WGs >>> to the list. >>> >>> /So what is the bottom line ?/ >>> >>> We just need to agree on the fact that there is no existing >>> protocol that meets the ROLL requirements and move to the next >>> step (re-chartering) to select one (hopefully not two) routing >>> protocols in light of the routing requirement (NOT the protocol >>> survey), which can either be an adapted MANET protocol or a new >>> protocol. >>> >>> Now moving to your proposed resolution. >>> >>>> >>>> >>>> So, in a nutshell, I suggest that we address (i) the positioning >>>> issue and (ii) the criteria issue thus: >>>> >>>> o Describe as I proposed above if ROLL and MANETs position >>>> themselves as I >>>> have deducted. If my deduction is incorrect, then let's quickly >>>> iterate on the list >>>> as to understand how to do produce an alternative description. If >>>> we can't do this, >>>> then the conclusion can be that "we do not know how ROLL and >>>> MANET position >>>> themselves wrt each other", and we could then state that clearly? >>>> >>>> It *should* not be more than a couple of paragraphs worth of text >>>> to add, I gather? >>>> >>> >>> If you find a way to word this, please feel free and I'd be happy >>> to help but feel it as necessary ... Any opinion from our RTG and >>> INT ADs ? >>> >>>> o To the criteria, either of: >>>> >>>> - Add the assumption that "user data traffic is so low that path >>>> lengths do not >>>> matter nor does the cost of carrying user data traffice" >>>> >>> >>> The motivation for selecting a longer path is not tied to the >>> amount of traffic here but the level of constraints. Note that >>> this is also true for several other technologies such as MPLS-TE. >>> You may have large amount of traffic and still require to follow a >>> non-shortest path (constrained based routing). This is detailed in >>> several requirements IDs. Criticality of data is of course >>> different, thus the requirements for potentially different data >>> paths according to packet marking using DSCP. >>> >>>> - Add a criteria & evaluation of "path length" >>>> >>>> - Add a criteria & evaluation of "total cost for getting user >>>> data through the network" >>>> >>> >>> And we can add many more but if the current protocol do not >>> satisfy existing requirements, isn't it sufficient to answer the >>> question on whether one can find an existing protocol? >>> >>>> This would make a large chunk of my concerns and issues vanish, >>>> and allow correctly interpreting and evaluating the rest of the >>>> document. >>> >>> That said, question for the WG. Who think that such criteria >>> should be added to move forward ? Please reply. >>> >>>> >>>> >>>> How does that sound as an approach forward? >>>> >>> >>> Thanks for helping out. >>> >>> Cheers. >>> >>> JP. >>> >>>> Cheers, >>>> >>>> Thomas >>>> >>>> On Jan 27, 2009, at 1:00 AM, Internet-Drafts@ietf.org >>>> wrote: >>>> >>>>> A New Internet-Draft is available from the on-line >>>>> Internet-Drafts >>>>> directories. >>>>> This draft is a work item of the Routing Over Low power and >>>>> Lossy networks Working Group of the IETF. >>>>> >>>>> Title : Overview of Existing Routing Protocols for Low Power and >>>>> Lossy Networks >>>>> Author(s) : A. Tavakoli, S. Dawson-Haggerty, P. Levis >>>>> Filename : draft-ietf-roll-protocols-survey-05.txt >>>>> Pages : 26 >>>>> Date : 2009-1-26 >>>>> >>>>> Networks of low power wireless devices introduce novel IP routing >>>>> issues. Low-power wireless devices, such as sensors, >>>>> actuators and >>>>> smart objects, have difficult constraints: very limited memory, >>>>> little processing power, and long sleep periods. As most of >>>>> these >>>>> devices are battery-powered, energy efficiency is critically >>>>> important. Wireless link qualities can vary significantly >>>>> over time, >>>>> requiring protocols to make agile decisions yet minimize >>>>> topology >>>>> change energy costs. Routing over such low power and lossy >>>>> networks >>>>> has novel requirements that existing protocols may not >>>>> address. This >>>>> document provides a brief survey of the strengths and >>>>> weaknesses of >>>>> existing protocols with respect to this class of networks. >>>>> From this >>>>> survey it examines whether existing and mature IETF protocols >>>>> can be >>>>> used without modification in these networks, or whether >>>>> further work >>>>> is necessary. >>>>> is necessary. >>>>> >>>>> A URL for this Internet-Draft is: >>>>> = >>>>> http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-survey-= 05.txt >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> Below is the data which will enable a MIME compliant mail reader >>>>> implementation to automatically retrieve the ASCII version of the >>>>> Internet-Draft. >>>>> Content-Type: text/plain >>>>> Content-ID: <2009-1-26155804.I-D@ietf.org >>>>> > >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 From roll-bounces@ietf.org Tue Feb 3 07:42:40 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FBAE3A68B1; Tue, 3 Feb 2009 07:42:40 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D81263A68B1 for ; Tue, 3 Feb 2009 07:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eEV6YYRFR+Z for ; Tue, 3 Feb 2009 07:42:38 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id A587F3A672F for ; Tue, 3 Feb 2009 07:42:37 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so333431eya.31 for ; Tue, 03 Feb 2009 07:42:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=XOOdkzvDYrpmsnNBk9QyJxpbXh9Qk6skJ4dNSZPkMfc=; b=QQlJJUXQoD32T+5vy/Re2Zz+cGX8R+uHFWIhbQTX3HAX4i/BM3T+qDK8/Ka+PHdPvo 30ki8l5sw7bwUd8tyDfh74+Qu3qLh5I+4miE6RcKc1LmsaGX+2D9XJ5n+xA9SI6TBGy5 H+xOZWyNlydUyykoTGPrgnXv/T1FGdUAdJwj4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=HJnqmTxH8VxBvUr6kJWF4WBvPl/MfcHW9liyVIx+ylteCba98Vp3oe7Jv/+J04JRaG UMM9vyENbH3FopPflIQ8LVlTrCRYPF84Ach+DF3QQRNzX8Zn/kgyjk2h2EZj5A0ycnQF I56kLSfWj0XEGslu4/zt/jtl4jL23h46jNcEk= MIME-Version: 1.0 Received: by 10.103.117.8 with SMTP id u8mr754299mum.123.1233675736352; Tue, 03 Feb 2009 07:42:16 -0800 (PST) In-Reply-To: <498852C5.1050503@gmail.com> References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> Date: Tue, 3 Feb 2009 07:42:16 -0800 X-Google-Sender-Auth: 28db6cb9dd1c8c7a Message-ID: <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> From: Arsalan Tavakoli To: Alexandru Petrescu Cc: "David E. Culler" , roll@ietf.org, Ross Callon Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0227470103==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0227470103== Content-Type: multipart/alternative; boundary=0016e6570b86088a2d046205843c --0016e6570b86088a2d046205843c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > > >> I agree in principle. > > But what's then the implication of of the protocols-survey draft on the > next-stage developments? > > The protocols-survey draft clearly puts NEMO protocol out of scope: > >> This document does not examine the Network Mobility Basic Support Protocol >> (NEMO RFC 3963 [RFC3963]) because it is not a routing protocol. >> > > If protocols-survey draft gets published as is, now, this means NEMO > protocol is not going to be considered. Regardless of the mentioning of the > "mobility" aspects in the requirements. > > Alex No, it doesn't mean that at all. The protocol survey picked a set of candidates to evaluate (which was agreed upon on the mailing list and at IETF meetings), which only serve to answer the basic question: does any protocol currently exist that satisfies all requirements. When we move to the next stage, specifications for protocols outside of those considered, including NEMO, are certainly more than welcome. - Arsalan --0016e6570b86088a2d046205843c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I agree in principle.

But what's then the implication of of the protocols-survey draft on the= next-stage developments?

The protocols-survey draft clearly puts NEMO protocol out of scope:
This document does not examine the Network Mobility Basic Support Protocol = (NEMO RFC 3963 [RFC3963]) because it is not a routing protocol.

If protocols-survey draft gets published as is, now, this means NEMO protoc= ol is not going to be considered.  Regardless of the mentioning of the= "mobility" aspects in the requirements.

Alex

No, it doesn't mean that at all. &= nbsp;The protocol survey picked a set of candidates to evaluate (which was = agreed upon on the mailing list and at IETF meetings), which only serve to = answer the basic question: does any protocol currently exist that satisfies= all requirements.  When we move to the next stage, specifications for= protocols outside of those considered, including NEMO, are certainly more = than welcome.

- Arsalan

--0016e6570b86088a2d046205843c-- --===============0227470103== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0227470103==-- From roll-bounces@ietf.org Tue Feb 3 07:48:55 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86BBE28C0DF; Tue, 3 Feb 2009 07:48:55 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 205D83A69B1 for ; Tue, 3 Feb 2009 07:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+MCk6NSS5u2 for ; Tue, 3 Feb 2009 07:48:52 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 584D83A6C41 for ; Tue, 3 Feb 2009 07:48:52 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,373,1231113600"; d="scan'208";a="32724162" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2009 15:48:31 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n13FmVrb024682; Tue, 3 Feb 2009 16:48:31 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n13FmVrd027133; Tue, 3 Feb 2009 15:48:31 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 16:48:30 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 16:48:29 +0100 Message-Id: <4A8F4A99-4F98-4DDD-A4D7-4E3F71EBD556@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <498852C5.1050503@gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Feb 2009 16:48:28 +0100 References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Feb 2009 15:48:30.0037 (UTC) FILETIME=[DC4F8050:01C98616] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1687; t=1233676111; x=1234540111; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Review=20and=20comments=20Re=3 A=09I-D=09ACTION=3Adraft-ietf-roll-protocols-survey-05.txt |Sender:=20; bh=uTP0PozfV4bLo8+KpwhxW0oSKfIMWpuGNrUw9xNtXF4=; b=dGszxDuE84779oMzITVweVdNgnRXm0FViF00cF7rOkR1N//kJ/zJBl1or3 fO4cfPP2lZ2vITf3dkYIDxGEMTtDtlTik6XY20M081kjp7rqpwLovc/5LW0V paSyKrtbGA; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Ross Callon , roll@ietf.org, Arsalan Tavakoli , "David E. Culler" , stevedh@cs.berkeley.edu Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Feb 3, 2009, at 3:20 PM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> Hi Alex, >> On Feb 3, 2009, at 12:21 AM, Alexandru Petrescu wrote: >>> Mischa Dohler a =E9crit : [...] >>>> As for your proposition, I have another one: Why don't we stop = >>>> here and get on with the actual protocol design stage, >>> Sorry, which protocol do we mean to go on to protocol design stage? >>> Could one imagine starting from scratch designing a new protocol? >> We have detailed routing requirements documents. Should we re- = >> charter, the process gets quite simple. Look at different = >> candidates and how close they are to the requirements. Then select = >> one or two (in which case we need clear applicability statement). And >> yes if we can use an adapted existing protocol, then great. > > I agree in principle. > > But what's then the implication of of the protocols-survey draft on = > the next-stage developments? > > The protocols-survey draft clearly puts NEMO protocol out of scope: >> This document does not examine the Network Mobility Basic Support = >> Protocol (NEMO RFC 3963 [RFC3963]) because it is not a routing = >> protocol. > > If protocols-survey draft gets published as is, now, this means NEMO = > protocol is not going to be considered. Why ? if we get rechartered NEMO WILL be considered as part of the = candidates among others pieces of the solution, > Regardless of the mentioning of the "mobility" aspects in the = > requirements. > > Alex > > > _______________________________________________ > 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 From roll-bounces@ietf.org Tue Feb 3 07:52:01 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F357A3A6C3A; Tue, 3 Feb 2009 07:52:00 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B0303A6C40 for ; Tue, 3 Feb 2009 07:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vkc0bq6N6ZbE for ; Tue, 3 Feb 2009 07:51:59 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 4486C3A6C3F for ; Tue, 3 Feb 2009 07:51:59 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n13FpMF6014058; Tue, 3 Feb 2009 16:51:22 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n13FpLIx014823; Tue, 3 Feb 2009 16:51:21 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n13FpKEv029922; Tue, 3 Feb 2009 16:51:20 +0100 Message-ID: <498867F8.6000802@gmail.com> Date: Tue, 03 Feb 2009 16:51:20 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Arsalan Tavakoli References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> In-Reply-To: <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> Cc: "David E. Culler" , roll@ietf.org, Ross Callon Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Arsalan Tavakoli a =E9crit : > = > I agree in principle. > = > But what's then the implication of of the protocols-survey draft on > the next-stage developments? > = > The protocols-survey draft clearly puts NEMO protocol out of scope: > = > This document does not examine the Network Mobility Basic > Support Protocol (NEMO RFC 3963 [RFC3963]) because it is not a > routing protocol. > = > = > If protocols-survey draft gets published as is, now, this means NEMO > protocol is not going to be considered. Regardless of the > mentioning of the "mobility" aspects in the requirements. > = > Alex > = > = > No, it doesn't mean that at all. The protocol survey picked a set of = > candidates to evaluate (which was agreed upon on the mailing list and at = > IETF meetings), which only serve to answer the basic question: does any = > protocol currently exist that satisfies all requirements. When we move = > to the next stage, specifications for protocols outside of those = > considered, including NEMO, are certainly more than welcome. In this case the entire protocols-survey draft looks superfluous: its = statements aren't of any use because in the next stage we ignore its advice. Alex _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Feb 3 07:52:53 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27A9528C129; Tue, 3 Feb 2009 07:52:53 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C389228C126 for ; Tue, 3 Feb 2009 07:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-z6iBVfPHNZ for ; Tue, 3 Feb 2009 07:52:51 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 887D228C121 for ; Tue, 3 Feb 2009 07:52:51 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n13Fonmo011335; Tue, 3 Feb 2009 16:50:49 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n13FqR7s016662; Tue, 3 Feb 2009 16:52:27 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n13FqRd2030455; Tue, 3 Feb 2009 16:52:27 +0100 Message-ID: <4988683B.9020508@gmail.com> Date: Tue, 03 Feb 2009 16:52:27 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: JP Vasseur References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <4A8F4A99-4F98-4DDD-A4D7-4E3F71EBD556@cisco.com> In-Reply-To: <4A8F4A99-4F98-4DDD-A4D7-4E3F71EBD556@cisco.com> Cc: roll@ietf.org Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org JP Vasseur a =E9crit : > = > On Feb 3, 2009, at 3:20 PM, Alexandru Petrescu wrote: > = >> JP Vasseur a =E9crit : >>> Hi Alex, >>> On Feb 3, 2009, at 12:21 AM, Alexandru Petrescu wrote: >>>> Mischa Dohler a =E9crit : [...] >>>>> As for your proposition, I have another one: Why don't we stop here = >>>>> and get on with the actual protocol design stage, >>>> Sorry, which protocol do we mean to go on to protocol design stage? >>>> Could one imagine starting from scratch designing a new protocol? >>> We have detailed routing requirements documents. Should we = >>> re-charter, the process gets quite simple. Look at different = >>> candidates and how close they are to the requirements. Then select = >>> one or two (in which case we need clear applicability statement). And >>> yes if we can use an adapted existing protocol, then great. >> >> I agree in principle. >> >> But what's then the implication of of the protocols-survey draft on = >> the next-stage developments? >> >> The protocols-survey draft clearly puts NEMO protocol out of scope: >>> This document does not examine the Network Mobility Basic Support = >>> Protocol (NEMO RFC 3963 [RFC3963]) because it is not a routing protocol. >> >> If protocols-survey draft gets published as is, now, this means NEMO = >> protocol is not going to be considered. > = > Why ? if we get rechartered NEMO WILL be considered as part of the = > candidates among others pieces of the solution, Why don't we write precisely that in some draft text? Why not in the = protocols-survey draft? Alex _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Feb 3 08:03:53 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDBE13A688A; Tue, 3 Feb 2009 08:03:53 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8725E28C10E for ; Tue, 3 Feb 2009 08:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiRMlF7xv9TB for ; Tue, 3 Feb 2009 08:03:51 -0800 (PST) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by core3.amsl.com (Postfix) with ESMTP id 44AE73A67D6 for ; Tue, 3 Feb 2009 08:03:51 -0800 (PST) Received: by ewy14 with SMTP id 14so2530569ewy.13 for ; Tue, 03 Feb 2009 08:03:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=s4N+kcxNE6LyTX7oJ5AzRkVHptpcZYADi86YXwVmUd0=; b=aWQHW5ycBjEJvfigPzSqHnYIRPDxRBlVESwgZfYl8WCNtby61IshhC/2IZtNtr2XTn kFDF7Ep0H4t2nYD/aJa+x+a2F8c82WOkJtguZp0gvQbYmHH33nfXB4OJc5aeUp53Pl9n FOialeTbI6NQ6gX/PHRanwRfX/1G/rZwmTmf0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=t1IhWNB5IdQ8eASLs5xyYxqGskjqlI3Gf/Sl0AzrIPiJKpXIHsNXc8vw+XlX9Vt59L 4QhnxCPAKZ8wVflqGy1qzr0DrDEQH0OG3e+lxFr8l3EsXy5b7a1vx88lAkKMXmK0BSn5 lU6/ldNuTJlCrOI1OrpcMaDpITJD5yhWagHCQ= MIME-Version: 1.0 Received: by 10.210.61.11 with SMTP id j11mr6058516eba.119.1233677010825; Tue, 03 Feb 2009 08:03:30 -0800 (PST) In-Reply-To: <498867F8.6000802@gmail.com> References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> Date: Tue, 3 Feb 2009 08:03:30 -0800 X-Google-Sender-Auth: e78b22cee930f9ac Message-ID: <69306dde0902030803x651b7e5akc7127cd0d8809c08@mail.gmail.com> From: Arsalan Tavakoli To: Alexandru Petrescu Cc: "David E. Culler" , roll@ietf.org, Ross Callon Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1110505539==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1110505539== Content-Type: multipart/alternative; boundary=0015174a0fbaff7443046205cf56 --0015174a0fbaff7443046205cf56 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > > >> No, it doesn't mean that at all. The protocol survey picked a set of >> candidates to evaluate (which was agreed upon on the mailing list and at >> IETF meetings), which only serve to answer the basic question: does any >> protocol currently exist that satisfies all requirements. When we move to >> the next stage, specifications for protocols outside of those considered, >> including NEMO, are certainly more than welcome. >> > > In this case the entire protocols-survey draft looks superfluous: its > statements aren't of any use because in the next stage we ignore its advice. > > Alex > How are we ignoring it's advice? While it might seem superfluous or a formality to you, one of the real questions that we needed to answer before moving on to protocol design (if necessary mind you), was what are the base set of necessary but sufficient requirements for this design space, and do any existing protocol specifications meet these requirements. This protocol survey allowed us to answer this question 'No', and now move on to the actual protocol design space. As we have repeatedly said, this document does NOT serve as an advisory to which protocol or protocols should be selected for ROLL. It does highlight what are the areas that need modification for a set of existing protocols, but this in no way inhibits the presentation of any other protocols in the next stage. --0015174a0fbaff7443046205cf56 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

No, it doesn't mean that at all.  The protocol survey picked a set= of candidates to evaluate (which was agreed upon on the mailing list and a= t IETF meetings), which only serve to answer the basic question: does any p= rotocol currently exist that satisfies all requirements.  When we move= to the next stage, specifications for protocols outside of those considere= d, including NEMO, are certainly more than welcome.

In this case the entire protocols-survey draft looks superfluous: its state= ments aren't of any use because in the next stage we ignore its advice.=

Alex

How are we ignoring it's advic= e?  While it might seem superfluous or a formality to you, one of the = real questions that we needed to answer before moving on to protocol design= (if necessary mind you), was what are the base set of necessary but suffic= ient requirements for this design space, and do any existing protocol speci= fications meet these requirements.  This protocol survey allowed us to= answer this question 'No', and now move on to the actual protocol = design space.  As we have repeatedly said, this document does NOT serv= e as an advisory to which protocol or protocols should be selected for ROLL= .  It does highlight what are the areas that need modification for a s= et of existing protocols, but this in no way inhibits the presentation of a= ny other protocols in the next stage. 

--0015174a0fbaff7443046205cf56-- --===============1110505539== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1110505539==-- From roll-bounces@ietf.org Tue Feb 3 08:06:31 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C77E28C0DF; Tue, 3 Feb 2009 08:06:31 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28CCD28C185 for ; Tue, 3 Feb 2009 08:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8yjfLgAMCG0 for ; Tue, 3 Feb 2009 08:06:29 -0800 (PST) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by core3.amsl.com (Postfix) with ESMTP id DEA3C28C0DF for ; Tue, 3 Feb 2009 08:06:28 -0800 (PST) Received: by ewy14 with SMTP id 14so2533585ewy.13 for ; Tue, 03 Feb 2009 08:06:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=hGHu8XnJTdeaSFflRIz/cS3W8Vw6H7frJqpZlFa5yBo=; b=Lez9OnSyrDZbW3PGDUr0ZvnFWckRHEnx+fKDWjvQ22JYNvATUqthx/KD92LOo249PL 2Tco0gSTdW9q9VCWvOzqmXQdC6pea7PctOTbx3RTV9HATMigycAXQUqKZd/F8UBCPK9u rPQhYyA84Erl2UArjbbQ/YpOr+K3p1DS+mMTQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=ZyNWayQfsL8Mqs0TYnfIAirStqJtE2hdnwYibT5o3kh8vdqx60RIwU+hIQCYYmZFuj KHp0ZVj/BwztFti37lbOEC5HEMX4vKzh8rlu6/3nzIO4MtACFn5wuGuCXe4x94KdvWGg hzZhouiQWXoCvBV6lyT6+KGAyzYGykWKLZo2g= MIME-Version: 1.0 Received: by 10.210.87.19 with SMTP id k19mr2151061ebb.105.1233677167989; Tue, 03 Feb 2009 08:06:07 -0800 (PST) In-Reply-To: <4988683B.9020508@gmail.com> References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <4A8F4A99-4F98-4DDD-A4D7-4E3F71EBD556@cisco.com> <4988683B.9020508@gmail.com> Date: Tue, 3 Feb 2009 08:06:07 -0800 X-Google-Sender-Auth: 8b320b38c3f1e3c1 Message-ID: <69306dde0902030806y17a6197cra5b945e947cfe9@mail.gmail.com> From: Arsalan Tavakoli To: Alexandru Petrescu Cc: roll@ietf.org Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0827061130==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0827061130== Content-Type: multipart/alternative; boundary=0015174c3c605d9574046205d972 --0015174c3c605d9574046205d972 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > > >>> Why ? if we get rechartered NEMO WILL be considered as part of the >> candidates among others pieces of the solution, >> > > Why don't we write precisely that in some draft text? Why not in the > protocols-survey draft? > > > Alex > This IS in the protocols-survey draft. While we don't highlight NEMO specifically, the document makes very clear its purpose is only to determine if an existing specification meets all the requirements, and in the case that it doesn't, it makes no claim on whether a new protocol design will be presented, or an existing specification will be modified (and it does not imply that existing is limited to those in the document). Either way, NEMO is included in this space. > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --0015174c3c605d9574046205d972 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Why ? if we get rechartered NEMO WILL be considered as part of the candidat= es among others pieces of the solution,

Why don't we write precisely that in some draft text?  Why not in = the protocols-survey draft?


Alex

This IS in the protocols-s= urvey draft.  While we don't highlight NEMO specifically, the docu= ment makes very clear its purpose is only to determine if an existing speci= fication meets all the requirements, and in the case that it doesn't, i= t makes no claim on whether a new protocol design will be presented, or an = existing specification will be modified (and it does not imply that existin= g is limited to those in the document).  Either way, NEMO is included = in this space.

 



_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

--0015174c3c605d9574046205d972-- --===============0827061130== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0827061130==-- From roll-bounces@ietf.org Tue Feb 3 08:17:09 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 273B43A6A40; Tue, 3 Feb 2009 08:17:09 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F26843A6A1F for ; Tue, 3 Feb 2009 08:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Z-L0ReRmHcH for ; Tue, 3 Feb 2009 08:17:07 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 09DB03A6A40 for ; Tue, 3 Feb 2009 08:17:06 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n13GGh8h025115; Tue, 3 Feb 2009 17:16:43 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n13GGhwK024263; Tue, 3 Feb 2009 17:16:43 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n13GGgxr010181; Tue, 3 Feb 2009 17:16:43 +0100 Message-ID: <49886DEA.8090103@gmail.com> Date: Tue, 03 Feb 2009 17:16:42 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Arsalan Tavakoli References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <4A8F4A99-4F98-4DDD-A4D7-4E3F71EBD556@cisco.com> <4988683B.9020508@gmail.com> <69306dde0902030806y17a6197cra5b945e947cfe9@mail.gmail.com> In-Reply-To: <69306dde0902030806y17a6197cra5b945e947cfe9@mail.gmail.com> Cc: roll@ietf.org Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Arsalan Tavakoli a =E9crit : > = > Why ? if we get rechartered NEMO WILL be considered as part of the > candidates among others pieces of the solution, > = > = > Why don't we write precisely that in some draft text? Why not in the > protocols-survey draft? > = > = > Alex > = > = > This IS in the protocols-survey draft. While we don't highlight NEMO > specifically, It's not that NEMO is not specifically highlighted, it's that it's not examined at all: > This document does not examine the Network Mobility Basic Support = > Protocol (NEMO RFC 3963 [RFC3963]) because it is not a routing = > protocol. Later phrases sound better, but I think the above could be better = formulated to reflect better what you're saying. I could suggest text = if you wish, instead of crossing swords :-) Alex the document makes very clear its purpose is only to > determine if an existing specification meets all the requirements, > and in the case that it doesn't, it makes no claim on whether a new > protocol design will be presented, or an existing specification will > be modified (and it does not imply that existing is limited to those > in the document). Either way, NEMO is included in this space. > = > = > = > = > = > = > _______________________________________________ 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 From roll-bounces@ietf.org Tue Feb 3 08:38:24 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC4F328C172; Tue, 3 Feb 2009 08:38:24 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36A4E28C126 for ; Tue, 3 Feb 2009 08:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyqLDKhDEQHD for ; Tue, 3 Feb 2009 08:38:22 -0800 (PST) Received: from smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by core3.amsl.com (Postfix) with SMTP id 27E5828C172 for ; Tue, 3 Feb 2009 08:38:22 -0800 (PST) Received: (qmail 69578 invoked from network); 3 Feb 2009 16:38:02 -0000 Received: from unknown (HELO ?192.168.0.207?) (anand@209.48.242.66 with plain) by smtp107.biz.mail.re2.yahoo.com with SMTP; 3 Feb 2009 16:38:01 -0000 X-YMail-OSG: vgL7lVwVM1nZsPnYrmZ7FUc8ywDL1MdU18rb4AkW7gjnLj_l4LDlpezTP0zix4X_u97zVkFLdEQCJdzZ34QiSNV33DT1ASzRlKeqNQYCz26m9e4z4eQ9.e85qHZNJvYubBotP7vShDBK81eZN_v.bNow X-Yahoo-Newman-Property: ymail-3 Message-ID: <498874A8.9030206@ekasystems.com> Date: Tue, 03 Feb 2009 11:45:28 -0500 From: "M. B. Anand" User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: ROLL WG References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> In-Reply-To: Subject: Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review and comments draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org JP Vasseur wrote: > > *-> Yes we need to rush out. Why ? Because proprietary or semi-closed > non-IP solutions are being deployed at a fairly large scale. I do not > think that I have to convince anybody on this list that this is the > WRONG approach for a number of reasons. The industry is asking for an > IP solution *now*.* Indeed. And the bold letters are quite warranted. As we speak, actual legislation is moving through Congress in the US that specifies "Internet-enabled technologies" as a condition for grants in smart grid applications. Who knows what such technologies are ? There is no routing standard, there is no standard on any number of other things although there are bits and pieces of standards here and there. Billions of dollars are about to be handed out in the very near future and in the absence of any standards, practically everything is going to get claimed to be IP. The window is closing very, very fast. While all this is surely not an excuse to produce shoddy work, it is certainly a tremendous driver to move. The sole reason for those of us engaged in the application space to be involved and contribute actively here is that there is a group of experts who having been doing networking for decades and there is an unrivaled body of knowledge at IETF on how to do networking correctly. That includes all the working groups. It needs to be done here and it needs to be done soon. > >> This would make a large chunk of my concerns and issues vanish, and >> allow correctly interpreting and evaluating the rest of the document. > > That said, question for the WG. Who think that such criteria should be > added to move forward ? Please reply. As has been said here many times, the purpose of this document is to evaluate the suitability of existing IETF protocols for their suitability for intersection of ROLL requirements. The document itself is very clear and states: "this document simply seeks to answer the question: do LLNs require a new protocol specification document at all?" So, no, it is not superfluous, because this question needed to be answered. It is expressly not the purpose of this document to decide what is a useful approach or a starting point for any new protocol. It seems to get interpreted that way in many of these discussions and that is not its purpose. In a recent email, Emmanuel states: "Basically, everybody agrees that something special must be done for sensor ad hoc connectivity with IP, and everybody wants to reach the next phase ASAP (i.e. work on solutions). " If everybody agrees on this, then this document should close without needing any further discussion. The whole purpose of the document is to document what everyone seems to agree on. Then, what is the disagreement ? I suggest we restrict the discussion to the following: 1. Are there any disagreements on the analysis ? - Seems not at the present time, or any such issues have already been addressed. 2. Should any criteria be removed and if so why ? - Again, I haven't seen anyone state this. 3. Let's not add any criteria - because that is not going to magically make the conclusion - i.e., the fact no existing protocol, unchanged, suits the requirements (which, BTW, everyone agrees on) change. All the other discussions on ROLL, MANET, 6LoW etc. are perhaps valuable and there is a time and place for those, but it has little to do with this draft. Best regards, Anand. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Feb 3 08:43:21 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 279813A6C3A; Tue, 3 Feb 2009 08:43:21 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 400D93A67FD for ; Tue, 3 Feb 2009 08:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHJiLTLTj0y5 for ; Tue, 3 Feb 2009 08:43:19 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by core3.amsl.com (Postfix) with ESMTP id ED2213A6AC3 for ; Tue, 3 Feb 2009 08:43:18 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 14F4C70013; Tue, 3 Feb 2009 17:42:58 +0100 (CET) Received: from PMEXCC21.intranet-paris.francetelecom.fr (unknown [10.196.130.6]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id CA00F70005; Tue, 3 Feb 2009 17:42:57 +0100 (CET) Received: from PMEXCB30.intranet-paris.francetelecom.fr ([10.196.130.37]) by PMEXCC21.intranet-paris.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.2499); Tue, 3 Feb 2009 17:42:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Feb 2009 17:42:57 +0100 Message-ID: <53DE7AEBE1DD5741A44C36342768192203DA9B06@PMEXCB30.intranet-paris.francetelecom.fr> In-Reply-To: <498874A8.9030206@ekasystems.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review andcomments draft-ietf-roll-protocols-survey-05.txt Thread-Index: AcmGHczs8ejSRot5S0uB6tLmM6471AAAFIig From: To: "M. B. Anand" , "ROLL WG" X-OriginalArrivalTime: 03 Feb 2009 16:42:57.0693 (UTC) FILETIME=[77FC3CD0:01C9861E] Subject: Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review andcomments draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Dear all, I fully support Anand's comments - it's time to move on and work on WG rech= artering to ignite the specification effort. = Cheers, Christian. -----Message d'origine----- De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de M. = B. Anand Envoy=E9 : mardi 3 f=E9vrier 2009 17:45 =C0 : ROLL WG Objet : Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review andco= mments draft-ietf-roll-protocols-survey-05.txt JP Vasseur wrote: > > *-> Yes we need to rush out. Why ? Because proprietary or semi-closed = > non-IP solutions are being deployed at a fairly large scale. I do not = > think that I have to convince anybody on this list that this is the = > WRONG approach for a number of reasons. The industry is asking for an = > IP solution *now*.* Indeed. And the bold letters are quite warranted. As we speak, actual legis= lation is moving through Congress in the US that specifies "Internet-enable= d technologies" as a condition for grants in smart grid applications. Who k= nows what such technologies are ? There is no routing standard, there is no= standard on any number of other things although there are bits and pieces = of standards here and there. Billions of dollars are about to be handed out= in the very near future and in the absence of any standards, practically e= verything is going to get claimed to be IP. The window is closing very, ver= y fast. While all this is surely not an excuse to produce shoddy work, it is certai= nly a tremendous driver to move. The sole reason for those of us engaged in= the application space to be involved and contribute actively here is that = there is a group of experts who having been doing networking for decades an= d there is an unrivaled body of knowledge at IETF on how to do networking c= orrectly. That includes all the working groups. It needs to be done here an= d it needs to be done soon. > >> This would make a large chunk of my concerns and issues vanish, and = >> allow correctly interpreting and evaluating the rest of the document. > > That said, question for the WG. Who think that such criteria should be = > added to move forward ? Please reply. As has been said here many times, the purpose of this document is to evalua= te the suitability of existing IETF protocols for their suitability for int= ersection of ROLL requirements. The document itself is very clear and state= s: "this document simply seeks to answer the question: do LLNs require a new protocol specification document at all?" S= o, no, it is not superfluous, because this question needed to be answered. = It is expressly not the purpose of this document to decide what is a useful= approach or a starting point for any new protocol. It seems to get interpr= eted that way in many of these discussions and that is not its purpose. In a recent email, Emmanuel states: "Basically, everybody agrees that something special must be done for sensor= ad hoc connectivity with IP, and everybody wants to reach the next phase A= SAP (i.e. work on solutions). " If everybody agrees on this, then this document should close without needin= g any further discussion. The whole purpose of the document is to document = what everyone seems to agree on. Then, what is the disagreement ? I suggest we restrict the discussion to the following: 1. Are there any disagreements on the analysis ? - Seems not at the presen= t time, or any such issues have already been addressed. 2. Should any criteria be removed and if so why ? - Again, I haven't seen a= nyone state this. 3. Let's not add any criteria - because that is not going to magically make= the conclusion - i.e., the fact no existing protocol, unchanged, suits the= requirements (which, BTW, everyone agrees on) change. All the other discussions on ROLL, MANET, 6LoW etc. are perhaps valuable an= d there is a time and place for those, but it has little to do with this dr= aft. Best regards, Anand. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees. = Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. = France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Feb 3 08:44:21 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4221E28C1E7; Tue, 3 Feb 2009 08:44:21 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBEE428C164 for ; Tue, 3 Feb 2009 08:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15tCQI-exOs3 for ; Tue, 3 Feb 2009 08:44:18 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by core3.amsl.com (Postfix) with ESMTP id 598FB28C0E3 for ; Tue, 3 Feb 2009 08:44:18 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id b11so316995nfh.39 for ; Tue, 03 Feb 2009 08:43:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=gIWe/VxOhoi57nG76gWwjTRRk+ZFNSenx+XPhSnJv3w=; b=s7gShZ+6UiI+kX7K4lX68ED+DlouQdDwn063YkjfWSQwzsoiWDr+Z/tbIzzWQXuIya pl+SuyzoqDVfuzPINOchOOTog/ECzGIK7B5Q5lB7SUYzt07uQUba32QZLfauxZ8AzQSw 1NdVZCbLHyaK+3sSgbQZLekSS0uPTxxd63B6c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Z/EBAJ3vbX8OdTfTHPeNvVqim2TcAAhit+2A44kp475XwHZZgDXSIydIGCpDV6X+79 Euyoqn5bj8lZMucUbOJUVN0YZq1PwPZ9IsIhMn357k264A20s2RSY3/37+p5JwP53pMR cN9ef/MukqzzlFGMGNowXKBmqTPNk7QTAvpso= MIME-Version: 1.0 Received: by 10.210.10.1 with SMTP id 1mr3631086ebj.189.1233679438279; Tue, 03 Feb 2009 08:43:58 -0800 (PST) In-Reply-To: <49886DEA.8090103@gmail.com> References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <4A8F4A99-4F98-4DDD-A4D7-4E3F71EBD556@cisco.com> <4988683B.9020508@gmail.com> <69306dde0902030806y17a6197cra5b945e947cfe9@mail.gmail.com> <49886DEA.8090103@gmail.com> Date: Tue, 3 Feb 2009 08:43:58 -0800 X-Google-Sender-Auth: c63525647c4ec571 Message-ID: <69306dde0902030843h5d4a8855ldf7314ae2a5f40af@mail.gmail.com> From: Arsalan Tavakoli To: Alexandru Petrescu Cc: roll@ietf.org Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1425117490==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1425117490== Content-Type: multipart/alternative; boundary=0015174c0dd8af74f90462066023 --0015174c0dd8af74f90462066023 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Feb 3, 2009 at 8:16 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Arsalan Tavakoli a =E9crit : > >> >> Why ? if we get rechartered NEMO WILL be considered as part of the >> candidates among others pieces of the solution, >> >> >> Why don't we write precisely that in some draft text? Why not in the >> protocols-survey draft? >> >> >> Alex >> >> >> This IS in the protocols-survey draft. While we don't highlight NEMO >> specifically, >> > > It's not that NEMO is not specifically highlighted, it's that it's not > examined at all: > >> This document does not examine the Network Mobility Basic Support Protoc= ol >> (NEMO RFC 3963 [RFC3963]) because it is not a routing protocol. >> > > Later phrases sound better, but I think the above could be better > formulated to reflect better what you're saying. I could suggest text if > you wish, instead of crossing swords :-) > > Alex Let me rephrase this. Are you implying that within the NEMO RFC exists a routing protocol (which Phil, among others, has defined on this list numerous times) that meets all the ROLL requirements as defined in the protocol survey draft? If the answer is yes, then terrific, we're done. If however, the answer is no, as we and you have postulated on this mailing list before, then in my opinion this debate is an exercise in futility. To gain the benefit of having NEMO appear in the draft (which again it does not because of the statement above which we stand by), we have prolonged last call on this draft, which impedes our ability to move on to the actual protocol design, as JP and others have been pleading on the list because if we don't have an IP-based IETF ROLL protocol soon, we risk being bypassed by those looking t= o adopt a standardized protocol. I understand that you feel NEMO is a good candidate that shouldn't be slighted; my point is that once we move beyond this draft, that text in the draft excluding NEMO becomes moot; you will have all the opportunity to present NEMO, or rather a NEMO-modification as = a candidate to become the ROLL standardized protocol. But again, by definition of our charter, we can NOT do that until this draft is last called and finalized. > > > > > > > the document makes very clear its purpose is only to > >> determine if an existing specification meets all the requirements, >> and in the case that it doesn't, it makes no claim on whether a new >> protocol design will be presented, or an existing specification will >> be modified (and it does not imply that existing is limited to those >> in the document). Either way, NEMO is included in this space. >> >> >> >> >> >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> >> > > --0015174c0dd8af74f90462066023 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 3, 2009 at 8:16 AM, Alexandr= u Petrescu <alexandru.petrescu@gmail.com> wrote:
Arsalan Tavakoli a =E9crit :


Why ? if we get rechartered NEMO WILL be considered as part of the
candidates among others pieces of the solution,


Why don't we write precisely that in some draft text?  Why not in = the
protocols-survey draft?


Alex


This IS in the protocols-survey draft.  While we don't highlight N= EMO
 specifically,

It's not that NEMO is not specifically highlighted, it's that it= 9;s not
examined at all:

This document does not examine the Network Mobility Basic Support Protocol = (NEMO RFC 3963 [RFC3963]) because it is not a routing protocol.

Later phrases sound better, but I think the above could be better formulate= d to reflect better what you're saying.  I could suggest text if y= ou wish, instead of crossing swords :-)

Alex

Let me rephrase this.  Are you im= plying that within the NEMO RFC exists a routing protocol (which Phil, amon= g others, has defined on this list numerous times) that meets all the ROLL = requirements as defined in the protocol survey draft?

If the answer is yes, then terrific, we're done. &n= bsp;If however, the answer is no, as we and you have postulated on this mai= ling list before, then in my opinion this debate is an exercise in futility= .  To gain the benefit of having NEMO appear in the draft (which again= it does not because of the statement above which we stand by), we have pro= longed last call on this draft, which impedes our ability to move on to the= actual protocol design, as JP and others have been pleading on the list be= cause if we don't have an IP-based IETF ROLL protocol soon, we risk bei= ng bypassed by those looking to adopt a standardized protocol.  I unde= rstand that you feel NEMO is a good candidate that shouldn't be slighte= d; my point is that once we move beyond this draft, that text in the draft = excluding NEMO becomes moot; you will have all the opportunity to present N= EMO, or rather a NEMO-modification as a candidate to become the ROLL standa= rdized protocol.  But again, by definition of our charter, we can NOT = do that until this draft is last called and finalized.

 






 the document makes very clear its purpose is only to
determine if an existing specification meets all the requirements,
and in the case that it doesn't, it makes no claim on whether a new
protocol design will be presented, or an existing specification will
be modified (and it does not imply that existing is limited to those
in the document).  Either way, NEMO is included in this space.






_______________________________________________ Roll mailing list Roll@ietf.org <mailto:Roll@ietf.org> https:= //www.ietf.org/mailman/listinfo/roll





--0015174c0dd8af74f90462066023-- --===============1425117490== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1425117490==-- From roll-bounces@ietf.org Tue Feb 3 08:48:21 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79BB528C167; Tue, 3 Feb 2009 08:48:21 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F32F428C167 for ; Tue, 3 Feb 2009 08:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.255 X-Spam-Level: X-Spam-Status: No, score=-3.255 tagged_above=-999 required=5 tests=[AWL=1.344, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PtF4sdPJRZz for ; Tue, 3 Feb 2009 08:48:18 -0800 (PST) Received: from scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by core3.amsl.com (Postfix) with ESMTP id 8F98128C0FC for ; Tue, 3 Feb 2009 08:48:18 -0800 (PST) Received: from leo (postfix@leo.cttc.es [84.88.62.208]) by scorpius.cttc.es (8.13.8/8.13.5) with ESMTP id n13GjOpK027229; Tue, 3 Feb 2009 17:45:24 +0100 Received: from [84.88.61.89] (pcmdohler.cttc.es [84.88.61.89]) by leo (Postfix) with ESMTP id A822810C31E; Tue, 3 Feb 2009 17:45:24 +0100 (CET) Message-ID: <4988737C.9060201@cttc.es> Date: Tue, 03 Feb 2009 17:40:28 +0100 From: Mischa Dohler User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: christian.jacquenet@orange-ftgroup.com, "M. B. Anand" , ROLL WG References: <53DE7AEBE1DD5741A44C36342768192203DA9B06@PMEXCB30.intranet-paris.francetelecom.fr> In-Reply-To: <53DE7AEBE1DD5741A44C36342768192203DA9B06@PMEXCB30.intranet-paris.francetelecom.fr> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (leo); Tue, 03 Feb 2009 17:45:24 +0100 (CET) X-Scanned-By: MIMEDefang 2.57 on 84.88.62.197 Subject: Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review andcomments draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org I am also in favor. Thanks, Mischa. christian.jacquenet@orange-ftgroup.com wrote: > Dear all, > = > I fully support Anand's comments - it's time to move on and work on WG re= chartering to ignite the specification effort. = > = > Cheers, > = > Christian. > = > -----Message d'origine----- > De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de M= . B. Anand > Envoy=E9 : mardi 3 f=E9vrier 2009 17:45 > =C0 : ROLL WG > Objet : Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review and= comments draft-ietf-roll-protocols-survey-05.txt > = > JP Vasseur wrote: >> *-> Yes we need to rush out. Why ? Because proprietary or semi-closed = >> non-IP solutions are being deployed at a fairly large scale. I do not = >> think that I have to convince anybody on this list that this is the = >> WRONG approach for a number of reasons. The industry is asking for an = >> IP solution *now*.* > Indeed. And the bold letters are quite warranted. As we speak, actual leg= islation is moving through Congress in the US that specifies "Internet-enab= led technologies" as a condition for grants in smart grid applications. Who= knows what such technologies are ? There is no routing standard, there is = no standard on any number of other things although there are bits and piece= s of standards here and there. Billions of dollars are about to be handed o= ut in the very near future and in the absence of any standards, practically= everything is going to get claimed to be IP. The window is closing very, v= ery fast. > = > While all this is surely not an excuse to produce shoddy work, it is cert= ainly a tremendous driver to move. The sole reason for those of us engaged = in the application space to be involved and contribute actively here is tha= t there is a group of experts who having been doing networking for decades = and there is an unrivaled body of knowledge at IETF on how to do networking= correctly. That includes all the working groups. It needs to be done here = and it needs to be done soon. >>> This would make a large chunk of my concerns and issues vanish, and = >>> allow correctly interpreting and evaluating the rest of the document. >> That said, question for the WG. Who think that such criteria should be = >> added to move forward ? Please reply. > As has been said here many times, the purpose of this document is to eval= uate the suitability of existing IETF protocols for their suitability for i= ntersection of ROLL requirements. The document itself is very clear and sta= tes: "this document simply seeks to answer the > question: do LLNs require a new protocol specification document at all?" = So, no, it is not superfluous, because this question needed to be answered= . It is expressly not the purpose of this document to decide what is a usef= ul approach or a starting point for any new protocol. It seems to get inter= preted that way in many of these discussions and that is not its purpose. > = > In a recent email, Emmanuel states: > "Basically, everybody agrees that something special must be done for sens= or ad hoc connectivity with IP, and everybody wants to reach the next phase= ASAP (i.e. work on solutions). " > = > If everybody agrees on this, then this document should close without need= ing any further discussion. The whole purpose of the document is to documen= t what everyone seems to agree on. Then, what is the disagreement ? > = > I suggest we restrict the discussion to the following: > 1. Are there any disagreements on the analysis ? - Seems not at the pres= ent time, or any such issues have already been addressed. > 2. Should any criteria be removed and if so why ? - Again, I haven't seen= anyone state this. > 3. Let's not add any criteria - because that is not going to magically ma= ke the conclusion - i.e., the fact no existing protocol, unchanged, suits t= he requirements (which, BTW, everyone agrees on) change. > = > All the other discussions on ROLL, MANET, 6LoW etc. are perhaps valuable = and there is a time and place for those, but it has little to do with this = draft. > = > Best regards, > Anand. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > = > ********************************* > This message and any attachments (the "message") are confidential and int= ended solely for the addressees. = > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. = > France Telecom Group shall not be liable for the message if altered, chan= ged or falsified. > If you are not the intended addressee of this message, please cancel it i= mmediately and inform the sender. > ******************************** > _______________________________________________ > 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 From roll-bounces@ietf.org Tue Feb 3 08:53:19 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8A9D3A672F; Tue, 3 Feb 2009 08:53:19 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FAFD28C1E7 for ; Tue, 3 Feb 2009 08:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJlbK2TMiTip for ; Tue, 3 Feb 2009 08:53:18 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 16F783A6407 for ; Tue, 3 Feb 2009 08:53:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,373,1231113600"; d="scan'208";a="35765209" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 03 Feb 2009 16:52:36 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n13GqaUp012423; Tue, 3 Feb 2009 11:52:36 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n13GqaNx023413; Tue, 3 Feb 2009 16:52:36 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 11:52:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Feb 2009 11:52:21 -0500 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC7640779DE3A@xmb-rtp-208.amer.cisco.com> In-Reply-To: <4988737C.9060201@cttc.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review andcomments draft-ietf-roll-protocols-survey-05.txt Thread-Index: AcmGHy8N4hDEmxsaTH6noDHxXm9g8AAAIerw References: <53DE7AEBE1DD5741A44C36342768192203DA9B06@PMEXCB30.intranet-paris.francetelecom.fr> <4988737C.9060201@cttc.es> From: "Stan Ratliff (sratliff)" To: "Mischa Dohler" , , "M. B. Anand" , "ROLL WG" X-OriginalArrivalTime: 03 Feb 2009 16:52:36.0117 (UTC) FILETIME=[D0C0BC50:01C9861F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5590; t=1233679956; x=1234543956; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20=22Stan=20Ratliff=20(sratliff)=22=20 |Subject:=20RE=3A=20[Roll]=20*=20ALL=20PLEASE=20READ=20**=2 0TIME=20FOR=20CLOSURE=20?=20Re=3A=20Review=09andcomments=20d raft-ietf-roll-protocols-survey-05.txt |Sender:=20 |To:=20=22Mischa=20Dohler=22=20,=0A= 20=20=20=20=20=20=20=20,=0A=20=20=20=20=20=20=20=20=22M.=20B.=20Anand=22=20,=20=22ROLL=20WG=22=20; bh=SJuiZgRLwbtUPovNARYWDKF7qwqvgG9GBsCzF8FxzY8=; b=MSGjWt44/RyG1ejQxG2E/3tnzJ4COWDRU7aMkkDJ8gapwS4U/7xos4UMyO d6YLkJTWNLA2ic++7ZExDP0yxH5kPIchoVX/cUP7lIuo76Aggw/yt7AdtaJr qsWf7ebn7w; Authentication-Results: rtp-dkim-2; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review andcomments draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Ditto. Let's wrap this up and move on to the next challenge. = Regards, Stan = -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mis= cha Dohler Sent: Tuesday, February 03, 2009 11:40 AM To: christian.jacquenet@orange-ftgroup.com; M. B. Anand; ROLL WG Subject: Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review andc= omments draft-ietf-roll-protocols-survey-05.txt I am also in favor. Thanks, Mischa. christian.jacquenet@orange-ftgroup.com wrote: > Dear all, > = > I fully support Anand's comments - it's time to move on and work on WG re= chartering to ignite the specification effort. = > = > Cheers, > = > Christian. > = > -----Message d'origine----- > De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part = > de M. B. Anand Envoy=E9 : mardi 3 f=E9vrier 2009 17:45 =C0 : ROLL WG Obje= t : = > Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review = > andcomments draft-ietf-roll-protocols-survey-05.txt > = > JP Vasseur wrote: >> *-> Yes we need to rush out. Why ? Because proprietary or semi-closed = >> non-IP solutions are being deployed at a fairly large scale. I do not = >> think that I have to convince anybody on this list that this is the = >> WRONG approach for a number of reasons. The industry is asking for an = >> IP solution *now*.* > Indeed. And the bold letters are quite warranted. As we speak, actual leg= islation is moving through Congress in the US that specifies "Internet-enab= led technologies" as a condition for grants in smart grid applications. Who= knows what such technologies are ? There is no routing standard, there is = no standard on any number of other things although there are bits and piece= s of standards here and there. Billions of dollars are about to be handed o= ut in the very near future and in the absence of any standards, practically= everything is going to get claimed to be IP. The window is closing very, v= ery fast. > = > While all this is surely not an excuse to produce shoddy work, it is cert= ainly a tremendous driver to move. The sole reason for those of us engaged = in the application space to be involved and contribute actively here is tha= t there is a group of experts who having been doing networking for decades = and there is an unrivaled body of knowledge at IETF on how to do networking= correctly. That includes all the working groups. It needs to be done here = and it needs to be done soon. >>> This would make a large chunk of my concerns and issues vanish, and = >>> allow correctly interpreting and evaluating the rest of the document. >> That said, question for the WG. Who think that such criteria should = >> be added to move forward ? Please reply. > As has been said here many times, the purpose of this document is to = > evaluate the suitability of existing IETF protocols for their = > suitability for intersection of ROLL requirements. The document itself = > is very clear and states: "this document simply seeks to answer the > question: do LLNs require a new protocol specification document at all?" = So, no, it is not superfluous, because this question needed to be answered= . It is expressly not the purpose of this document to decide what is a usef= ul approach or a starting point for any new protocol. It seems to get inter= preted that way in many of these discussions and that is not its purpose. > = > In a recent email, Emmanuel states: > "Basically, everybody agrees that something special must be done for sens= or ad hoc connectivity with IP, and everybody wants to reach the next phase= ASAP (i.e. work on solutions). " > = > If everybody agrees on this, then this document should close without need= ing any further discussion. The whole purpose of the document is to documen= t what everyone seems to agree on. Then, what is the disagreement ? > = > I suggest we restrict the discussion to the following: > 1. Are there any disagreements on the analysis ? - Seems not at the pres= ent time, or any such issues have already been addressed. > 2. Should any criteria be removed and if so why ? - Again, I haven't seen= anyone state this. > 3. Let's not add any criteria - because that is not going to magically ma= ke the conclusion - i.e., the fact no existing protocol, unchanged, suits t= he requirements (which, BTW, everyone agrees on) change. > = > All the other discussions on ROLL, MANET, 6LoW etc. are perhaps valuable = and there is a time and place for those, but it has little to do with this = draft. > = > Best regards, > Anand. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > = > ********************************* > This message and any attachments (the "message") are confidential and int= ended solely for the addressees. = > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. = > France Telecom Group shall not be liable for the message if altered, chan= ged or falsified. > If you are not the intended addressee of this message, please cancel it i= mmediately and inform the sender. > ******************************** > _______________________________________________ > 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 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Feb 3 09:03:20 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6786328C172; Tue, 3 Feb 2009 09:03:20 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40B2E3A6C3A for ; Tue, 3 Feb 2009 09:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.87 X-Spam-Level: X-Spam-Status: No, score=-3.87 tagged_above=-999 required=5 tests=[AWL=2.729, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRnPBlvhTxpw for ; Tue, 3 Feb 2009 09:03:17 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id DEECE28C172 for ; Tue, 3 Feb 2009 09:03:17 -0800 (PST) Received: from [128.32.39.229] (dhcp-39-229.EECS.Berkeley.EDU [128.32.39.229]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n13H2tZo027943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Feb 2009 09:02:57 -0800 (PST) Message-ID: <498878B9.80403@eecs.berkeley.edu> Date: Tue, 03 Feb 2009 09:02:49 -0800 From: "David E. Culler" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Thomas Heide Clausen References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> In-Reply-To: <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> Cc: Ross Callon , roll@ietf.org, Arsalan Tavakoli Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Thomas, 1. The charter of MANET (http://www.ietf.org/html.charters/manet-charter.html) does not even contain the word POWER - nor should it. MANET does not demand the intense focus on power that arises with embedded devices with no human being attached to them. Yes, "mobile" does imply that protocols should be "relatively lightweight in nature", but living for three hours on a monstrous laptop battery is rather different from living for 3 years on a pair of AAs. A few (like 5) orders of magnitude do make a difference. Similarly, loss does occur in the context of mobility, but it is of an entirely different nature to that they arises with low power wireless in embedded environment. 2. The charter of ROLL (http://www.ietf.org/html.charters/roll-charter.html) only mentions the word MOBILE in making clear that it must be considered as part of the due diligence associated with the routing requirements. If the process of turning over all the stones should bring mobility to the surface as a primary issue, then it would make sense to consider the overlap carefully. They don't. All the requirements are stationary. Mobility within them is extremely constrained. 3. The charter of 6LoWPAN (http://www.ietf.org/html.charters/6lowpan-charter.html) does not include pursuing routing because it is in the Internet area. That is one of the key reasons for ROLL, so that there could be work in the "routing" area. So, the answer to the interminable questions about whether there is some procedural matter than might be used to derail the technical progress toward the goal of ROLL is NO. We should stop wasting everyone's time with such efforts. The common issue is wireless. The underlying argument that you seem to be making is that if it has anything to do with wireless belongs to MANET. There is no question that the answer to that is also NO. Thomas Heide Clausen wrote: > All, > > I promised a review, and I apologize that I wasn't able to do so > before the weekend as originally projected. > > Other than some typos that Chris and others have pointed out, I'll try > to offer my understanding of the problem space and suggest some ways > of addressing my main concerns.... > > My first main concern remain that it is not clear, still, how ROLL > positions itself with respect to MANET, 6LOW et. al, all of which > appear to be within the same space and within the IETF. This I-D sees > ROLL as presented with entirely new problems (the use of "novel" in > the abstract, the statement that "existing protocols were not designed > with these requirements in mind" seem to confirm this). > > Looking at the requirements listed, including "low power, low > bandwidth, low footprint", these appear similar to those which are > also brought forward in e.g. MANET and 6LOW. Reading (quickly, I > confess) the various requirements documents of the draft-ietf-roll > series present scenarios which are similar to those where MANETs are > deployed, and are thought deployed, as well. > > I also note that many additional (and unstated) characteristics > between ROLL and e.g. MANET are the same: mobile, wireless, fragility, > auto-configuration, IP routing, interface/link issues... > > Arguing that, as does this I-D, despite the above impression "ROLL is > novel and different" invites asking "how, exactly?" I think that this > question is valid, and merits being answered, before the evaluations > in this I-D can be judged fairly. > > Note that I come from a MANET background, and so I *could* interpret > from the ROLL discussion that where MANETs may aim for "low power, low > bandwidth, ....", ROLL may be able to quantify these as "below this > firm threshold" -- i.e. as a sort of "extreme" or "constrained" MANET. > > This is a personal observation, I note, which would allow me to > comprehend how ROLL and MANET are positioned relative to one another > -- but one which neither this I-D nor the requirements document spell > out or quantify -- or, for that matter, debunk. > > I think it's critical to understand this, in order to understand the > need for a new protocol development. I think it is important to > document this understanding in something with more persistency. > > If what I suggest above makes sense as a way of positioning ROLL and > MANET relative to one another, I'd suggest including something to this > effect in the survey I-D, as this I-D is the one making a *direct* > reference to the applicability of MANET protocols to ROLL. > > If what I suggest doesn't make sense at all, then I'd be happy to have > it debunked and, hopefully, through that debunking a > positioning/description that does ring true with us all can be produced? > > My second main concern is, that I still think that the choice of > criteria is unfortunate (not the word, Phill has me convinced on that > front, but the actual criteria). Control cost is, by all means, a > rather meaningless criteria when taken in isolation. I've sketched a > "zero-control-cost" routing protocol (flood all data - say use SMF, > also a MANET protocol, and also a rather "mature" I-D and wg item) > which would score well on the control cost criteria, but would likely > be an extremely bad choice for delivering unicast data. > > The metric which matters, and which should matter to ROLL in > particular, is "the total cost of getting user data through the > network, including control cost necessary to set up paths" -- as we > know, every packet sent and received costs bandwidth, energy and > cycles -- user data no different from contro. > > According to the criterions as set up by this I-D, a protocol > producing "longer than shortest paths" at the benefit of slightly > lower control cost would score better than a protocol producing > "shortest paths" with slightly higher control cost. This is not > hypothetical, btw., there are plenty of studies observing and > reflecting upon this regarding the different MANET protocols, in > academic literature -- and observed in real networks as well. > > I note that this trade-off (slightly longer paths for lower control > cost) may be perfectly fair, assuming that very low amounts of user > data traffic transit through the network. However, I do not see this > assumption mentioned as a justification for focusing on the control > cost metric and discarding the "path length" or the "total cost of > getting user data through the network". > > I believe that either these assumptions should be made explicit > ("there's so little user data traffic in a ROLL network that we do not > care about shortest paths") or -- if these assumptions do not hold, > that the evaluation criteria are incomplete. > > I note that it's true that we can always add another criteria ad > infinitum, and that's CLEARLY not what we want to do. However when I > say "incomplete" in the above, I simply suggest that based on what is > presented one cannot draw conclusions based on the evaluation > criteria....or, worse, that one draws the wrong conclusions based on > the information presented. > > So, in a nutshell, I suggest that we address (i) the positioning issue > and (ii) the criteria issue thus: > > o Describe as I proposed above if ROLL and MANETs position > themselves as I > have deducted. If my deduction is incorrect, then let's > quickly iterate on the list > as to understand how to do produce an alternative description. > If we can't do this, > then the conclusion can be that "we do not know how ROLL and > MANET position > themselves wrt each other", and we could then state that clearly? > > It *should* not be more than a couple of paragraphs worth of > text to add, I gather? > > o To the criteria, either of: > > - Add the assumption that "user data traffic is so low > that path lengths do not > matter nor does the cost of carrying user data traffice" > > - Add a criteria & evaluation of "path length" > > - Add a criteria & evaluation of "total cost for > getting user data through the network" > > This would make a large chunk of my concerns and issues vanish, and > allow correctly interpreting and evaluating the rest of the document. > > How does that sound as an approach forward? > > Cheers, > > Thomas > > On Jan 27, 2009, at 1:00 AM, Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Routing Over Low power and Lossy >> networks Working Group of the IETF. >> >> Title : Overview of Existing Routing Protocols for Low >> Power and Lossy Networks >> Author(s) : A. Tavakoli, S. Dawson-Haggerty, P. Levis >> Filename : draft-ietf-roll-protocols-survey-05.txt >> Pages : 26 >> Date : 2009-1-26 >> >> Networks of low power wireless devices introduce novel IP routing >> issues. Low-power wireless devices, such as sensors, actuators and >> smart objects, have difficult constraints: very limited memory, >> little processing power, and long sleep periods. As most of these >> devices are battery-powered, energy efficiency is critically >> important. Wireless link qualities can vary significantly over time, >> requiring protocols to make agile decisions yet minimize topology >> change energy costs. Routing over such low power and lossy networks >> has novel requirements that existing protocols may not address. This >> document provides a brief survey of the strengths and weaknesses of >> existing protocols with respect to this class of networks. From this >> survey it examines whether existing and mature IETF protocols can be >> used without modification in these networks, or whether further work >> is necessary. >> is necessary. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-survey-05.txt >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> Content-Type: text/plain >> Content-ID: <2009-1-26155804.I-D@ietf.org> >> >> _______________________________________________ >> 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 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Feb 3 09:03:40 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92FC93A6C41; Tue, 3 Feb 2009 09:03:40 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 952F928C21E for ; Tue, 3 Feb 2009 09:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.501 X-Spam-Level: X-Spam-Status: No, score=-10.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64Ir7-Z6RjgW for ; Tue, 3 Feb 2009 09:03:38 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 398A43A6C3A for ; Tue, 3 Feb 2009 09:03:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,373,1231113600"; d="scan'208";a="32734469" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2009 17:03:12 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n13H3Cg5005072; Tue, 3 Feb 2009 18:03:12 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n13H3CMa024488; Tue, 3 Feb 2009 17:03:12 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 18:03:12 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 18:03:11 +0100 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <498867F8.6000802@gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Feb 2009 18:03:10 +0100 References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Feb 2009 17:03:12.0097 (UTC) FILETIME=[4BD39510:01C98621] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1838; t=1233680592; x=1234544592; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Review=20and=20comments=20Re=3 A=20I-D=20ACTION=3Adraft-ietf-roll-protocols-survey-05.txt |Sender:=20; bh=JADvTbQMARztXgPrTWGngLmEqHrz8aJaAbpGSPbdJNE=; b=NaanSrv6ikAxmFOLV8y9S9F3klSMP6p6Tcm/Dq0ZQCgL1YEI73QJsvxkNl 4HveHGyUuvYFRC988yff8MoJdZ92DviGC02xYNCT1l9uLm+kdjPo+zgRTF/T 55aVh4Y/wW; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "David E. Culler" , roll@ietf.org, Ross Callon Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Alex, On Feb 3, 2009, at 4:51 PM, Alexandru Petrescu wrote: > Arsalan Tavakoli a =E9crit : >> I agree in principle. >> But what's then the implication of of the protocols-survey draft = >> on >> the next-stage developments? >> The protocols-survey draft clearly puts NEMO protocol out of = >> scope: >> This document does not examine the Network Mobility Basic >> Support Protocol (NEMO RFC 3963 [RFC3963]) because it is not a >> routing protocol. >> If protocols-survey draft gets published as is, now, this means = >> NEMO >> protocol is not going to be considered. Regardless of the >> mentioning of the "mobility" aspects in the requirements. >> Alex >> No, it doesn't mean that at all. The protocol survey picked a set = >> of candidates to evaluate (which was agreed upon on the mailing = >> list and at IETF meetings), which only serve to answer the basic = >> question: does any protocol currently exist that satisfies all = >> requirements. When we move to the next stage, specifications for = >> protocols outside of those considered, including NEMO, are = >> certainly more than welcome. > > In this case the entire protocols-survey draft looks superfluous: = > its statements aren't of any use because in the next stage we ignore = > its advice. > I understand that it is difficult to follow all the traffic *but* we = said many times that the objective of the survey was to determine = whether or not we could find an existing protocol (with no change) satisfying the = requirements, that's it. On your recommendation to explicitly indicate that NEMO will be looked = at, we will add it to the protocol survey. Does that satisfy your = requirement ? Thanks. JP. > Alex > > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Feb 3 09:04:28 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAFFC28C123; Tue, 3 Feb 2009 09:04:28 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CD5328C123 for ; Tue, 3 Feb 2009 09:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.502 X-Spam-Level: X-Spam-Status: No, score=-10.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUZ6H+BzTwiJ for ; Tue, 3 Feb 2009 09:04:26 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 4CD9B3A6C41 for ; Tue, 3 Feb 2009 09:04:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,373,1231113600"; d="scan'208";a="32734585" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2009 17:04:06 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n13H45Ul005312; Tue, 3 Feb 2009 18:04:05 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n13H45XM024768; Tue, 3 Feb 2009 17:04:05 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 18:04:05 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 18:04:05 +0100 Message-Id: <9E802CAD-0ED9-429E-97F6-0C9353AB5AE0@cisco.com> From: JP Vasseur To: Arsalan Tavakoli In-Reply-To: <69306dde0902030803x651b7e5akc7127cd0d8809c08@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Feb 2009 18:04:04 +0100 References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> <69306dde0902030803x651b7e5akc7127cd0d8809c08@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Feb 2009 17:04:05.0689 (UTC) FILETIME=[6BC51290:01C98621] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1747; t=1233680645; x=1234544645; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Review=20and=20comments=20Re=3 A=20I-D=20ACTION=3Adraft-ietf-roll-protocols-survey-05.txt |Sender:=20; bh=QmnO3b7YycsjpM+00QHs6yhTqIVxv1+JnqcJK5ISRZ0=; b=ge3Du9pJWnZEc3cVMZiFrhQEVA3FyMX+4edvpnej/W3YbUE3Z76CzVQo2M gZ3n4OEe2/hiDj9sUdrSPg1lBnSCsofId/+GrDW9JjjOdaS0WxuAjKBdGBqw uZPU9OKgZD; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Ross Callon , roll@ietf.org, "David E. Culler" Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Sorry Arsalan I replied before seeing your reply, which was identical ;-) On Feb 3, 2009, at 5:03 PM, Arsalan Tavakoli wrote: > > No, it doesn't mean that at all. The protocol survey picked a set > of candidates to evaluate (which was agreed upon on the mailing list > and at IETF meetings), which only serve to answer the basic > question: does any protocol currently exist that satisfies all > requirements. When we move to the next stage, specifications for > protocols outside of those considered, including NEMO, are certainly > more than welcome. > > In this case the entire protocols-survey draft looks superfluous: > its statements aren't of any use because in the next stage we ignore > its advice. > > Alex > > How are we ignoring it's advice? While it might seem superfluous or > a formality to you, one of the real questions that we needed to > answer before moving on to protocol design (if necessary mind you), > was what are the base set of necessary but sufficient requirements > for this design space, and do any existing protocol specifications > meet these requirements. This protocol survey allowed us to answer > this question 'No', and now move on to the actual protocol design > space. As we have repeatedly said, this document does NOT serve as > an advisory to which protocol or protocols should be selected for > ROLL. It does highlight what are the areas that need modification > for a set of existing protocols, but this in no way inhibits the > presentation of any other protocols in the next stage. > > _______________________________________________ > 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 From roll-bounces@ietf.org Tue Feb 3 09:05:40 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A54F28C172; Tue, 3 Feb 2009 09:05:40 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0270E28C228 for ; Tue, 3 Feb 2009 09:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.503 X-Spam-Level: X-Spam-Status: No, score=-10.503 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVk+YHeknw3D for ; Tue, 3 Feb 2009 09:05:38 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8F8CC3A6C41 for ; Tue, 3 Feb 2009 09:05:37 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,373,1231113600"; d="scan'208,217";a="32734746" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2009 17:05:17 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n13H5HrO005772; Tue, 3 Feb 2009 18:05:17 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n13H5HQs025212; Tue, 3 Feb 2009 17:05:17 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 18:05:16 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 18:05:16 +0100 Message-Id: <9A1CAD0E-060C-4026-961B-CC50B758677B@cisco.com> From: JP Vasseur To: Arsalan Tavakoli In-Reply-To: <69306dde0902030806y17a6197cra5b945e947cfe9@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Feb 2009 18:05:15 +0100 References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <4A8F4A99-4F98-4DDD-A4D7-4E3F71EBD556@cisco.com> <4988683B.9020508@gmail.com> <69306dde0902030806y17a6197cra5b945e947cfe9@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Feb 2009 17:05:16.0421 (UTC) FILETIME=[95EDEB50:01C98621] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4018; t=1233680717; x=1234544717; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Review=20and=20comments=20Re=3 A=20I-D=20ACTION=3Adraft-ietf-roll-protocols-survey-05.txt |Sender:=20; bh=0cn1fLWSnSlPBk1uzUWG1Vr8JsXarhQi6qJjkfQoi1M=; b=fKFJX0sO4Zefv6fFlef/FJqtQvZbjDuTM/3oNGvGqEJISVC8KRR6+rj5k3 9k6kJDl7dYvT3MbZto0/ggOlp+MCIEI1ZHMzd3I6TtoDStv0AS7cjm1K4OSP r35iQFmKV4; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1188664632==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1188664632== Content-Type: multipart/alternative; boundary=Apple-Mail-116--177038543 --Apple-Mail-116--177038543 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Arsalan, Let's wait until we get all final comment and if OK with Alex we'll add an explicit short section related to NEMO. Thanks. JP. On Feb 3, 2009, at 5:06 PM, Arsalan Tavakoli wrote: > > Why ? if we get rechartered NEMO WILL be considered as part of the > candidates among others pieces of the solution, > > Why don't we write precisely that in some draft text? Why not in > the protocols-survey draft? > > > Alex > > This IS in the protocols-survey draft. While we don't highlight > NEMO specifically, the document makes very clear its purpose is only > to determine if an existing specification meets all the > requirements, and in the case that it doesn't, it makes no claim on > whether a new protocol design will be presented, or an existing > specification will be modified (and it does not imply that existing > is limited to those in the document). Either way, NEMO is included > in this space. > > > > > > _______________________________________________ > 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 --Apple-Mail-116--177038543 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

Why ? if we get rechartered = NEMO WILL be considered as part of the candidates among others pieces of = the solution,

Why don't we write precisely = that in some draft text?  Why not in the protocols-survey = draft?


= Alex

This IS in the = protocols-survey draft.  While we don't highlight NEMO = specifically, the document makes very clear its purpose is only to = determine if an existing specification meets all the requirements, and = in the case that it doesn't, it makes no claim on whether a new protocol = design will be presented, or an existing specification will be modified = (and it does not imply that existing is limited to those in the = document).  Either way, NEMO is included in this space.
=

 



= _______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
=

= _______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-116--177038543-- --===============1188664632== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1188664632==-- From roll-bounces@ietf.org Tue Feb 3 09:18:48 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 823343A6B9F; Tue, 3 Feb 2009 09:18:48 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C42933A6B17 for ; Tue, 3 Feb 2009 09:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.599 X-Spam-Level: X-Spam-Status: No, score=-11.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWbWHtDLyzce for ; Tue, 3 Feb 2009 09:18:45 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C7E843A6407 for ; Tue, 3 Feb 2009 09:18:42 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,373,1231113600"; d="scan'208";a="32736159" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2009 17:18:22 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n13HIM3Y021874; Tue, 3 Feb 2009 18:18:22 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n13HIMXq029184; Tue, 3 Feb 2009 17:18:22 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 18:18:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Feb 2009 18:18:20 +0100 Message-ID: <38F26F36EAA981478A49D1F37F474A860297BF02@xmb-ams-33d.emea.cisco.com> In-Reply-To: <4988737C.9060201@cttc.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review andcomments draft-ietf-roll-protocols-survey-05.txt Thread-Index: AcmGHy+52//Hfu7WQ/y3k5oAVpKCZAABCXvg References: <53DE7AEBE1DD5741A44C36342768192203DA9B06@PMEXCB30.intranet-paris.francetelecom.fr> <4988737C.9060201@cttc.es> From: "Julien Abeille (jabeille)" To: "Mischa Dohler" , , "M. B. Anand" , "ROLL WG" X-OriginalArrivalTime: 03 Feb 2009 17:18:22.0182 (UTC) FILETIME=[6A478860:01C98623] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5550; t=1233681502; x=1234545502; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20RE=3A=20[Roll]=20*=20ALL=20PLEASE=20READ=20**=2 0TIME=20FOR=20CLOSURE=20?=20Re=3A=20Review=09andcomments=20d raft-ietf-roll-protocols-survey-05.txt |Sender:=20; bh=0XKlkjB1ULxt+xzuBKN8By3MkEiu1qFS+age/Our5Go=; b=jf4bPfmmmOFGkhCvEeD9QjR1twq9EhQtJ9AnMt+GrL2oATdQiWY2Ip3VeP /OCEZYrK7Dj8qPIkyC8ZppjvHHESCdp4bZaUGWISmTPlvtwOnojXXChqxj4X fnyxlaWeVd; Authentication-Results: ams-dkim-2; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review andcomments draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi all, I also support this. Best, Julien = -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mis= cha Dohler Sent: mardi 3 f=E9vrier 2009 17:40 To: christian.jacquenet@orange-ftgroup.com; M. B. Anand; ROLL WG Subject: Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review andc= omments draft-ietf-roll-protocols-survey-05.txt I am also in favor. Thanks, Mischa. christian.jacquenet@orange-ftgroup.com wrote: > Dear all, > = > I fully support Anand's comments - it's time to move on and work on WG re= chartering to ignite the specification effort. = > = > Cheers, > = > Christian. > = > -----Message d'origine----- > De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part = > de M. B. Anand Envoy=E9 : mardi 3 f=E9vrier 2009 17:45 =C0 : ROLL WG Obje= t : = > Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review = > andcomments draft-ietf-roll-protocols-survey-05.txt > = > JP Vasseur wrote: >> *-> Yes we need to rush out. Why ? Because proprietary or semi-closed = >> non-IP solutions are being deployed at a fairly large scale. I do not = >> think that I have to convince anybody on this list that this is the = >> WRONG approach for a number of reasons. The industry is asking for an = >> IP solution *now*.* > Indeed. And the bold letters are quite warranted. As we speak, actual leg= islation is moving through Congress in the US that specifies "Internet-enab= led technologies" as a condition for grants in smart grid applications. Who= knows what such technologies are ? There is no routing standard, there is = no standard on any number of other things although there are bits and piece= s of standards here and there. Billions of dollars are about to be handed o= ut in the very near future and in the absence of any standards, practically= everything is going to get claimed to be IP. The window is closing very, v= ery fast. > = > While all this is surely not an excuse to produce shoddy work, it is cert= ainly a tremendous driver to move. The sole reason for those of us engaged = in the application space to be involved and contribute actively here is tha= t there is a group of experts who having been doing networking for decades = and there is an unrivaled body of knowledge at IETF on how to do networking= correctly. That includes all the working groups. It needs to be done here = and it needs to be done soon. >>> This would make a large chunk of my concerns and issues vanish, and = >>> allow correctly interpreting and evaluating the rest of the document. >> That said, question for the WG. Who think that such criteria should = >> be added to move forward ? Please reply. > As has been said here many times, the purpose of this document is to = > evaluate the suitability of existing IETF protocols for their = > suitability for intersection of ROLL requirements. The document itself = > is very clear and states: "this document simply seeks to answer the > question: do LLNs require a new protocol specification document at all?" = So, no, it is not superfluous, because this question needed to be answered= . It is expressly not the purpose of this document to decide what is a usef= ul approach or a starting point for any new protocol. It seems to get inter= preted that way in many of these discussions and that is not its purpose. > = > In a recent email, Emmanuel states: > "Basically, everybody agrees that something special must be done for sens= or ad hoc connectivity with IP, and everybody wants to reach the next phase= ASAP (i.e. work on solutions). " > = > If everybody agrees on this, then this document should close without need= ing any further discussion. The whole purpose of the document is to documen= t what everyone seems to agree on. Then, what is the disagreement ? > = > I suggest we restrict the discussion to the following: > 1. Are there any disagreements on the analysis ? - Seems not at the pres= ent time, or any such issues have already been addressed. > 2. Should any criteria be removed and if so why ? - Again, I haven't seen= anyone state this. > 3. Let's not add any criteria - because that is not going to magically ma= ke the conclusion - i.e., the fact no existing protocol, unchanged, suits t= he requirements (which, BTW, everyone agrees on) change. > = > All the other discussions on ROLL, MANET, 6LoW etc. are perhaps valuable = and there is a time and place for those, but it has little to do with this = draft. > = > Best regards, > Anand. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > = > ********************************* > This message and any attachments (the "message") are confidential and int= ended solely for the addressees. = > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. = > France Telecom Group shall not be liable for the message if altered, chan= ged or falsified. > If you are not the intended addressee of this message, please cancel it i= mmediately and inform the sender. > ******************************** > _______________________________________________ > 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 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Feb 3 09:26:53 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F4F13A6C4D; Tue, 3 Feb 2009 09:26:53 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51F5A28C24F for ; Tue, 3 Feb 2009 08:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.28 X-Spam-Level: X-Spam-Status: No, score=-6.28 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPQ8lTQ0qXTe for ; Tue, 3 Feb 2009 08:53:27 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 326CF28C23D for ; Tue, 3 Feb 2009 08:53:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,373,1231113600"; d="scan'208,217";a="35804525" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 03 Feb 2009 16:53:06 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n13Gr3qu026577; Tue, 3 Feb 2009 11:53:06 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n13Gr3Pc023584; Tue, 3 Feb 2009 16:53:03 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 11:53:03 -0500 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 11:52:12 -0500 Message-Id: <7F8459D1-3464-435A-AF8F-F9C437036FDF@cisco.com> From: David Ward To: ROLL WG In-Reply-To: Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Feb 2009 10:52:11 -0600 References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Feb 2009 16:52:13.0132 (UTC) FILETIME=[C30D80C0:01C9861F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=47652; t=1233679986; x=1234543986; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20*=20ALL=20PLEASE=20READ=20**=20TIME=20F OR=20CLOSURE=20?=20Re=3A=20[Roll]=20Review=20and=20comments= 20draft-ietf-roll-protocols-survey-05.txt |Sender:=20 |To:=20ROLL=20WG=20; bh=tQ9GUeiZHQAMSB4KOlDCUPNROKR63OR2sL9/xz8BT/I=; b=nUdxApXj7jg6Ns0p1CXUj5I7k7Qme3e5mP7DkMpib0oKGriXXuaK0xYT1h LHWqJ4b48zBxuqS/zC60SFJt08bAuNhoBB+uJ4R/GDlWCn+oIajM33WCwMDf /0aqrCtDzP; Authentication-Results: rtp-dkim-1; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Mailman-Approved-At: Tue, 03 Feb 2009 09:26:52 -0800 Cc: Arsalan Tavakoli , Geoff Mulligan , "David E. Culler" , stevedh@cs.berkeley.edu, mtownsley@cisco.com, Thomas Heide Clausen , Jari Arkko , Ross Callon Subject: Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review and comments draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0928166290==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0928166290== Content-Type: multipart/alternative; boundary=Apple-Mail-2--177822667 --Apple-Mail-2--177822667 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit All - We debated the delta between these three WGs when chartering ROLL for a considerable period of time. I do not want to revisit that debate but, I will quickly summarize here - 6LOWPAN is not working at the IP layer so, the overlap here is really not an issue. - MANET is and has been working on routing protocols for mobile, ad hoc networks with specific requirements and use cases. Some of those use cases may or may not overlap with ROLL. There will be lessons to be learned but, the primary use cases being worked on appeared by all the chairs and ADs involved to be different enough to warrant a new WG in this area. - ROLL was originally chartered to write the requirements and evaluate existing protocols for low power, lossy networks running over IP (some call these "sensor networks"). ROLL is only chartered to work on the routing protocol portion. Not the transport, encap or other topics at this time. Also note that mobility is not under consideration at this time. ROLL WG appears to have come to consensus on the requirement docs that state specific functions, attributes, power/memory envelope and algorithmic considerations that must be "in the routing protocol" for these networks. The survey ID (which is of course a snapshot at one point in time) puts some bounds on mapping the required functions, attributes and other considerations into protocols available *today.* Given the real work of designing a protocol hasn't begun by the ROLL WG participants; holding up the WG to begin taking what they currently defined as a very complex, multivariate problem and begin whittling it down to something solvable via theoretical and hypothetical exercises seems like an unwise use of time given the experience and energy of the WG in this problem space. The WG must move beyond the moderately high-level boundary setting exercise (which I believe there is consensus) and move onto the more challenging work of defining the objects, algorithms, semantics, state machines and functionality of the protocol. In the design phase (vs the survey phase) a better evaluation can be made of the ease or difficulty of "from scratch" or "modify what we have" can be made. I expect "wild swings" of the design pattern of the protocol during the first year of the design effort. I attempted to make this clear at the mic in Minneapolis that the current trajectory is very complex problem domain that hasn't born a lot of fruit but, that in the design phase reducing the complexity must occur. Members of the WG who have vast experience in these types of networks and have widely deployed products have stated that the routing protocol issues are solvable problems with some simplifying assumptions. I look forward to the WG making these design decisions and tradeoffs and debating the structure of the protocol. Any protocol reuse, experience, etc will be critical at this point to make the correct choices and I look to MANET, ROLL, MEXT, 6LOWPAN and other IETF'ers with routing protocol experience to contribute. This is an industry important juncture and moving LPLN to IP is a critical change. I am looking to the WG chairs to declare loose consensus on the documents (when appropriate) so that the rechartering of the WG to enter the design phase can occur. WIthout a doubt, the requirements as- is have defined the boundary of the work effort and I believe it is clear what is the difference between the WGs. HIH -DWard On Feb 3, 2009, at 7:14 AM, Thomas Heide Clausen wrote: > Dear JP, dear ADs, dear WG, > > (I Cc the other INT chair, as he's following 6lowpan) > > For the record, I am not arguing that MANET protocols should be > applied or be applicable -- as you seem to suggest in your email. I > believe that I have stated so repeatedly. > > I submit, however, that as it is currently exposed, ROLL, MANET and > 6LOW seem to be operating within the same space -- to the untrained > eye, in exactly the same space. My position is that it would be very > unfortunate having one WG creating confusion on the applicability of > the work of itself and of other IETF wg's, by simple omission of > suitable perimeter definitions. > > In that sort of situation, the IETF needs to be extra prudent to > make sure to clearly spell out suitable perimeter definitions prior > to, or conjointly with, the first publication cycle. In this case, > before or with the survey I-D. > > Sincerely, > > Thomas > > > On Feb 3, 2009, at 1:19 PM, JP Vasseur wrote: > >> Dear WG and ADs, >> >> Two issues are raised here for which we would appreciate ADs' point >> of view and feed-back from the WG. Please see in line. >> >> >> Dear Thomas, >> >> At the risk of repeating myself, I'd like to make a few important >> statements before *hopefully* come to a closure ;-) >> >> -> As you know, many of the ROLL WG active participants have been >> working quite hard to produce a detailed set of requirements, >> discuss how to proceed on the protocol survey document, and other >> ID are in the works. >> -> We managed to get highly experienced contributors in the field >> that have designed and deployed solutions so they not only have an >> excellent expertise of the requirements but also on solutions, >> -> Yes we need to rush out. Why ? Because proprietary or semi- >> closed non-IP solutions are being deployed at a fairly large scale. >> I do not think that I have to convince anybody on this list that >> this is the WRONG approach for a number of reasons. The industry is >> asking for an IP solution *now*. >> -> No we do not want to re-invent the wheel (see our presentation >> at the routing plenary in Chicago). Anything that already exists >> MUST (rfc2119 ;-)) be used provided that it meets our requirements. >> And if we can adapt an existing protocol, we are all for it ! >> -> Yes these requirements are quite specifics and this is precisely >> why ROLL has been formed, 4 application-specific routing >> requirements have been produced (to reduce the scope). Even if at a >> first sight, it looks very much similar to a MANET issue (and there >> ARE similarities but also very different requirements), having to >> deal with a highly static network of hundreds of thousands of >> battery operated sleeping nodes with 4K of RAM is quite specific. >> Note that this is not a random example, but an on-going non-IP >> deployed network. >> >> And to conclude on this introduction ... after an outstanding >> progress on the WG during the first 6-8 months, we have been slowed >> down dramatically for the last 2 months, thus it is time to close >> and move on to quickly re-charter and start the protocol work >> (hopefully as light as possible) to see IP-based solution deployed. >> I know that we are on the same page, we just need to find a good >> compromise on both "sides". >> >> Nothing new so far, let's move to a proposed resolution - See in >> line, >> >> On Feb 2, 2009, at 7:37 PM, Thomas Heide Clausen wrote: >> >>> All, >>> >>> I promised a review, and I apologize that I wasn't able to do so >>> before the weekend as originally projected. >>> >>> Other than some typos that Chris and others have pointed out, I'll >>> try to offer my understanding of the problem space and suggest >>> some ways of addressing my main concerns.... >>> >>> My first main concern remain that it is not clear, still, how ROLL >>> positions itself with respect to MANET, 6LOW et. al, all of which >>> appear to be within the same space and within the IETF. This I-D >>> sees ROLL as presented with entirely new problems (the use of >>> "novel" in the abstract, the statement that "existing protocols >>> were not designed with these requirements in mind" seem to confirm >>> this). >>> >>> Looking at the requirements listed, including "low power, low >>> bandwidth, low footprint", these appear similar to those which are >>> also brought forward in e.g. MANET and 6LOW. Reading (quickly, I >>> confess) the various requirements documents of the draft-ietf- >>> roll series present scenarios which are similar to those where >>> MANETs are deployed, and are thought deployed, as well. >>> >>> I also note that many additional (and unstated) characteristics >>> between ROLL and e.g. MANET are the same: mobile, wireless, >>> fragility, auto-configuration, IP routing, interface/link issues... >>> >>> Arguing that, as does this I-D, despite the above impression "ROLL >>> is novel and different" invites asking "how, exactly?" I think >>> that this question is valid, and merits being answered, before the >>> evaluations in this I-D can be judged fairly. >>> >>> Note that I come from a MANET background, and so I *could* >>> interpret from the ROLL discussion that where MANETs may aim for >>> "low power, low bandwidth, ....", ROLL may be able to quantify >>> these as "below this firm threshold" -- i.e. as a sort of >>> "extreme" or "constrained" MANET. >>> >>> This is a personal observation, I note, which would allow me to >>> comprehend how ROLL and MANET are positioned relative to one >>> another -- but one which neither this I-D nor the requirements >>> document spell out or quantify -- or, for that matter, debunk. >>> >>> I think it's critical to understand this, in order to understand >>> the need for a new protocol development. I think it is important >>> to document this understanding in something with more persistency. >>> >>> If what I suggest above makes sense as a way of positioning ROLL >>> and MANET relative to one another, I'd suggest including something >>> to this effect in the survey I-D, as this I-D is the one making a >>> *direct* reference to the applicability of MANET protocols to ROLL. >>> >>> If what I suggest doesn't make sense at all, then I'd be happy to >>> have it debunked and, hopefully, through that debunking a >>> positioning/description that does ring true with us all can be >>> produced? >>> >>> My second main concern is, that I still think that the choice of >>> criteria is unfortunate (not the word, Phill has me convinced on >>> that front, but the actual criteria). Control cost is, by all >>> means, a rather meaningless criteria when taken in isolation. I've >>> sketched a "zero-control-cost" routing protocol (flood all data - >>> say use SMF, also a MANET protocol, and also a rather "mature" I-D >>> and wg item) which would score well on the control cost criteria, >>> but would likely be an extremely bad choice for delivering unicast >>> data. >>> >>> The metric which matters, and which should matter to ROLL in >>> particular, is "the total cost of getting user data through the >>> network, including control cost necessary to set up paths" -- as >>> we know, every packet sent and received costs bandwidth, energy >>> and cycles -- user data no different from contro. >>> >>> According to the criterions as set up by this I-D, a protocol >>> producing "longer than shortest paths" at the benefit of slightly >>> lower control cost would score better than a protocol producing >>> "shortest paths" with slightly higher control cost. This is not >>> hypothetical, btw., there are plenty of studies observing and >>> reflecting upon this regarding the different MANET protocols, in >>> academic literature -- and observed in real networks as well. >>> >>> I note that this trade-off (slightly longer paths for lower >>> control cost) may be perfectly fair, assuming that very low >>> amounts of user data traffic transit through the network. However, >>> I do not see this assumption mentioned as a justification for >>> focusing on the control cost metric and discarding the "path >>> length" or the "total cost of getting user data through the >>> network". >>> >>> I believe that either these assumptions should be made explicit >>> ("there's so little user data traffic in a ROLL network that we do >>> not care about shortest paths") or -- if these assumptions do not >>> hold, that the evaluation criteria are incomplete. >>> >>> I note that it's true that we can always add another criteria ad >>> infinitum, and that's CLEARLY not what we want to do. However when >>> I say "incomplete" in the above, I simply suggest that based on >>> what is presented one cannot draw conclusions based on the >>> evaluation criteria....or, worse, that one draws the wrong >>> conclusions based on the information presented. >> >> It is not easy to answer each of your point without running the >> risk to start a debate that will never end. You raised some >> excellent points that I agree with and others that I firmly >> disagree with ... So let me try to make a few observations: >> 1) As pointed out earlier, yes there are similarities between MANET >> and ROLL. I do not see this as an issue. >> 2) The aim of the protocol survey IS NOT to exclude MANET >> protocols. As mentioned many times on the list, we *only* wanted to >> show that existing protocols, with no change, could not be used in >> LLNs. This has been clarified in the document as your request and >> it HAD to be clarified. >> 3) We could have used two different approaches for the survey: >> - Look at all MUST from the requirements documents >> - Try to derive a subset of necessary but not sufficient criteria, >> which the WG chose to do (consensus). Yes this list is not perfect, >> criteria could be changed, removed or added but looked good enough >> with excellent consensus until LC. >> 4) With regards to 6lowpan (I copy the chair), I do not see any >> overlap at all. Please refer to their charter and WG items. The >> only place that required clarification was the routing requirements >> and I was personally opposed to it but this was adopted as a >> 6lowpan WG item by consensus. We're are working together and >> managed to sort this out. This document will be 6lowpan specific. >> >> What I want to avoid is an endless discussion on the positioning of >> ROLL, MANET, 6lowpan and quite frankly we could add other WGs to >> the list. >> >> So what is the bottom line ? >> >> We just need to agree on the fact that there is no existing >> protocol that meets the ROLL requirements and move to the next step >> (re-chartering) to select one (hopefully not two) routing protocols >> in light of the routing requirement (NOT the protocol survey), >> which can either be an adapted MANET protocol or a new protocol. >> >> Now moving to your proposed resolution. >> >>> >>> >>> So, in a nutshell, I suggest that we address (i) the positioning >>> issue and (ii) the criteria issue thus: >>> >>> o Describe as I proposed above if ROLL and MANETs position >>> themselves as I >>> have deducted. If my deduction is incorrect, then let's quickly >>> iterate on the list >>> as to understand how to do produce an alternative description. >>> If we can't do this, >>> then the conclusion can be that "we do not know how ROLL and >>> MANET position >>> themselves wrt each other", and we could then state that clearly? >>> >>> It *should* not be more than a couple of paragraphs worth of >>> text to add, I gather? >>> >> >> If you find a way to word this, please feel free and I'd be happy >> to help but feel it as necessary ... Any opinion from our RTG and >> INT ADs ? >> >>> o To the criteria, either of: >>> >>> - Add the assumption that "user data traffic is so low that >>> path lengths do not >>> matter nor does the cost of carrying user data traffice" >>> >> >> The motivation for selecting a longer path is not tied to the >> amount of traffic here but the level of constraints. Note that this >> is also true for several other technologies such as MPLS-TE. You >> may have large amount of traffic and still require to follow a non- >> shortest path (constrained based routing). This is detailed in >> several requirements IDs. Criticality of data is of course >> different, thus the requirements for potentially different data >> paths according to packet marking using DSCP. >> >>> - Add a criteria & evaluation of "path length" >>> >>> - Add a criteria & evaluation of "total cost for getting user >>> data through the network" >>> >> >> And we can add many more but if the current protocol do not satisfy >> existing requirements, isn't it sufficient to answer the question >> on whether one can find an existing protocol? >> >>> This would make a large chunk of my concerns and issues vanish, >>> and allow correctly interpreting and evaluating the rest of the >>> document. >> >> That said, question for the WG. Who think that such criteria should >> be added to move forward ? Please reply. >> >>> >>> >>> How does that sound as an approach forward? >>> >> >> Thanks for helping out. >> >> Cheers. >> >> JP. >> >>> Cheers, >>> >>> Thomas >>> >>> On Jan 27, 2009, at 1:00 AM, Internet-Drafts@ietf.org wrote: >>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Routing Over Low power and Lossy >>>> networks Working Group of the IETF. >>>> >>>> Title : Overview of Existing Routing Protocols for Low Power >>>> and Lossy Networks >>>> Author(s) : A. Tavakoli, S. Dawson-Haggerty, P. Levis >>>> Filename : draft-ietf-roll-protocols-survey-05.txt >>>> Pages : 26 >>>> Date : 2009-1-26 >>>> >>>> Networks of low power wireless devices introduce novel IP routing >>>> issues. Low-power wireless devices, such as sensors, actuators >>>> and >>>> smart objects, have difficult constraints: very limited memory, >>>> little processing power, and long sleep periods. As most of >>>> these >>>> devices are battery-powered, energy efficiency is critically >>>> important. Wireless link qualities can vary significantly over >>>> time, >>>> requiring protocols to make agile decisions yet minimize topology >>>> change energy costs. Routing over such low power and lossy >>>> networks >>>> has novel requirements that existing protocols may not >>>> address. This >>>> document provides a brief survey of the strengths and >>>> weaknesses of >>>> existing protocols with respect to this class of networks. >>>> From this >>>> survey it examines whether existing and mature IETF protocols >>>> can be >>>> used without modification in these networks, or whether further >>>> work >>>> is necessary. >>>> is necessary. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-survey-05.txt >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>> Content-Type: text/plain >>>> Content-ID: <2009-1-26155804.I-D@ietf.org> >>>> >>>> _______________________________________________ >>>> 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 >> > --Apple-Mail-2--177822667 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
All = -

We debated the delta between these three WGs = when chartering ROLL for a considerable period of time. I do not want to = revisit that debate but, I will quickly summarize = here

- 6LOWPAN is not working at the IP layer = so, the overlap here is really not an issue.
- MANET is and = has been working on routing protocols for mobile, ad hoc networks with = specific requirements and use cases. Some of those use cases may or may = not overlap with ROLL. There will be lessons to be learned but, the = primary use cases being worked on appeared by all the chairs and ADs = involved to be different enough to warrant a new WG in this = area.
- ROLL was originally chartered to write the = requirements and evaluate existing protocols for low power, lossy = networks running over IP (some call these  "sensor networks"). ROLL = is only chartered to work on the routing protocol portion. Not the = transport, encap or other topics at this time. Also note that mobility = is not under consideration at this time.

ROLL = WG appears to have come to consensus on the requirement docs that state = specific functions, attributes, power/memory envelope and algorithmic = considerations that must be "in the routing protocol" for these = networks. The survey ID (which is of course a snapshot at one point in = time) puts some bounds on mapping the required functions, attributes and = other considerations into protocols available = *today.*

Given the real work of designing a = protocol hasn't begun by the ROLL WG participants; holding up the WG to = begin taking what they currently defined as a very complex, multivariate = problem and begin whittling it down to something solvable via = theoretical and hypothetical exercises seems like an unwise use of time = given the experience and energy of the WG in this problem space. =  The WG must move beyond the moderately high-level boundary setting = exercise (which I believe there is consensus) and move onto the more = challenging work of defining the objects, algorithms, semantics, state = machines and functionality of the protocol.  In the design phase = (vs the survey phase) a better evaluation can be made of the ease or = difficulty of "from scratch" or "modify what we have" can be made. I = expect "wild swings" of the design pattern of the protocol during the = first year of the design effort. I attempted to make this clear at the = mic in Minneapolis that the current trajectory is very complex problem = domain that hasn't born a lot of fruit but, that in the design phase = reducing the complexity must occur. Members of the WG who have vast = experience in these types of networks and have widely deployed products = have stated that the routing protocol issues are solvable problems with = some simplifying assumptions. I look forward to the WG making these = design decisions and tradeoffs and debating the structure of the = protocol. Any protocol reuse, experience, etc will be critical at this = point to make the correct choices and I look to MANET, ROLL, MEXT, = 6LOWPAN and other IETF'ers with routing protocol experience to = contribute. This is an industry important juncture and moving LPLN to IP = is a critical change.

I am looking to the WG = chairs to declare loose consensus on the documents  (when = appropriate) so that the rechartering of the WG to enter the design = phase can occur. WIthout a doubt, the requirements as-is have defined = the boundary of the work effort and I believe it is clear what is the = difference between the = WGs.


HIH

= -DWard




On = Feb 3, 2009, at 7:14 AM, Thomas Heide Clausen wrote:

Dear JP, dear ADs, dear = WG,

(I Cc the other INT chair, as he's following = 6lowpan)

For the record, I am not arguing that = MANET protocols should be applied or be applicable -- as you seem to = suggest in your email. I believe that I have stated so = repeatedly.

I submit, = however, that as it is currently exposed, ROLL, MANET and 6LOW seem to = be operating within the same space -- to the untrained eye, in exactly = the same space. My position is that it would be very unfortunate = having one WG creating confusion on the applicability of the work of = itself and of other IETF wg's, by simple omission of suitable perimeter = definitions. 

In that sort of situation, the IETF needs to be = extra prudent to make sure to clearly spell out suitable perimeter = definitions prior to, or conjointly with, the first publication cycle. = In this case, before or with the survey I-D.


Thomas

On Feb 3, = 2009, at 1:19 PM, JP Vasseur wrote:

Dear = WG and ADs,

Two issues are raised here for = which we would appreciate ADs' point of view and feed-back from the WG. = Please see in line.


Dear = Thomas,

At the risk of repeating myself, I'd like to = make a few important statements before *hopefully* come to a closure = ;-)

-> As you know, many of the ROLL WG active = participants have been working quite hard to produce a detailed set of = requirements, discuss how to proceed on the protocol survey document, = and other ID are in the works.
-> We managed to get highly = experienced contributors in the field that have designed and = deployed solutions so they not only have an excellent expertise of the = requirements but also on solutions,
-> Yes we need to rush = out. Why ? Because proprietary or semi-closed non-IP solutions are being = deployed at a fairly large scale. I do not think that I have to convince = anybody on this list that this is the WRONG approach for a number of = reasons. The industry is asking for an IP solution = *now*.
-> No we do not want to re-invent the wheel (see = our presentation at the routing plenary in Chicago). Anything that = already exists MUST (rfc2119 ;-)) be used provided that it meets our = requirements. And if we can adapt an existing protocol, we are all for = it !
-> Yes these requirements are quite specifics and this is = precisely why ROLL has been formed, 4 application-specific routing = requirements have been produced (to reduce the scope). Even if at a = first sight, it looks very much similar to a MANET issue (and there ARE = similarities but also very different requirements), having to deal with = a highly static network of hundreds of thousands of battery operated = sleeping nodes with 4K of RAM is quite specific. Note that this is not a = random example, but an on-going non-IP deployed = network.

And to conclude on this introduction = ... after an outstanding progress on the WG during the first 6-8 months, = we have been slowed down dramatically for the last 2 months, thus it is = time to close and move on to quickly re-charter and start the protocol = work (hopefully as light as possible) to see IP-based solution deployed. = I know that we are on the same page, we just need to find a good = compromise on both "sides".

Nothing new so far, = let's move to a proposed resolution - See in = line,

On Feb 2, 2009, at 7:37 PM, = Thomas Heide Clausen wrote:

All,

I promised a review, and I apologize that = I wasn't able to do so before the weekend as originally = projected.

Other than some typos that Chris and others have = pointed out, I'll try to offer my understanding of the problem space and = suggest some ways of addressing my main concerns....

My first = main concern remain that it is not clear, still, how ROLL positions = itself with respect to MANET, 6LOW et. al, all of which appear to be = within the same space and within the IETF. This I-D sees ROLL as = presented with entirely new problems (the use of "novel" in the = abstract, the statement that "existing protocols were not designed with = these requirements in mind" seem to confirm this).

Looking at the =  requirements listed, including "low power, low bandwidth, low = footprint", these appear similar to those which are also brought forward = in e.g. MANET and 6LOW. Reading (quickly, I confess) the various = requirements documents  of the draft-ietf-roll series present = scenarios which are similar to those where MANETs are deployed, and are = thought deployed, as well.

I also note that many additional (and = unstated) characteristics between ROLL and e.g. MANET are the same: = mobile, wireless, fragility, auto-configuration, IP routing, = interface/link issues...

Arguing that, as does this I-D, despite = the above impression "ROLL is novel and different" invites asking "how, = exactly?" I think that this question is valid, and merits being = answered, before the evaluations in this I-D can be judged = fairly.

Note that I come from a MANET background, and so I = *could* interpret from the ROLL discussion that where MANETs may aim for = "low power, low bandwidth, ....", ROLL may be able to quantify these as = "below this firm threshold" -- i.e. as a sort of "extreme" or = "constrained" MANET.

This is a personal observation, I note, = which would allow me to comprehend how ROLL and MANET are positioned = relative to one another -- but one which neither this I-D nor the = requirements document spell out or quantify -- or, for that matter, = debunk.

I think it's critical to understand this, in order to = understand the need for a new protocol development. I think it is = important to document this understanding in something with more = persistency.

If what I suggest above makes sense as a way of = positioning ROLL and MANET relative to one another, I'd suggest = including something to this effect in the survey I-D, as this I-D is the = one making a *direct* reference to the applicability of MANET protocols = to ROLL.

If what I suggest doesn't make sense at all, then I'd be = happy to have it debunked and, hopefully, through that debunking a = positioning/description that does ring true with us all can be = produced?

My second main concern is, that I still think that the = choice of criteria is unfortunate (not the word, Phill has me convinced = on that front, but the actual criteria). Control cost is, by all means, = a rather meaningless criteria when taken in isolation. I've sketched a = "zero-control-cost" routing protocol (flood all data - say use SMF, also = a MANET protocol, and also a rather "mature" I-D and wg item) which = would score well on the control cost criteria, but would likely be an = extremely bad choice for delivering unicast data.

The metric = which matters, and which should matter to ROLL in particular, is "the = total cost of getting user data through the network, including control = cost necessary to set up paths" -- as we know, every packet sent and = received costs bandwidth, energy and cycles -- user data no different = from contro.

According to the criterions as set up by this I-D, a = protocol producing "longer than shortest paths" at the benefit of = slightly lower control cost would score better than a protocol producing = "shortest paths" with slightly higher control cost. This is not = hypothetical, btw., there are plenty of studies observing and reflecting = upon this regarding the different MANET protocols, in academic = literature -- and observed in real networks as well.

I note that = this trade-off (slightly longer paths for lower control cost) may be = perfectly fair, assuming that very low amounts of user data traffic = transit through the network. However, I do not see this assumption = mentioned as a justification for focusing on the control cost metric and = discarding the "path length" or the "total cost of getting user data = through the network".

I believe that either these assumptions = should be made explicit ("there's so little user data traffic in a ROLL = network that we do not care about shortest paths") or -- if these = assumptions do not hold, that the evaluation criteria are = incomplete.

I note that it's true that we can always add another = criteria ad infinitum, and that's CLEARLY not what we want to do. = However when I say "incomplete" in the above, I simply suggest that = based on what is presented one cannot draw conclusions based on the = evaluation criteria....or, worse, that one draws the wrong conclusions = based on the information = presented.

It is not easy to = answer each of your point without running the risk to start a debate = that will never end. You raised some excellent points that I agree with = and others that I firmly disagree with ... So let me try to make a few = observations:
1) As pointed out earlier, yes there are = similarities between MANET and ROLL. I do not see this as an = issue.
2) The aim of the protocol survey IS NOT to exclude = MANET protocols. As mentioned many times on the list, we *only* wanted = to show that existing protocols, with no change, could not be used in = LLNs. This has been clarified in the document as your request and it HAD = to be clarified.
3) We could have used two different = approaches for the survey:
- Look at all MUST from the = requirements documents
- Try to derive a subset of = necessary but not sufficient criteria, which the WG chose to do = (consensus). Yes this list is not perfect,
criteria = could be changed, removed or added but looked good enough with excellent = consensus until LC.
4) With regards to 6lowpan (I copy the = chair), I do not see any overlap at all. Please refer to their charter = and WG items. The only place that required clarification was the routing = requirements and I was personally opposed to it but this was adopted as = a 6lowpan WG item by consensus. We're are working together and = managed to sort this out. This document will be 6lowpan = specific.

What I want to avoid is an endless = discussion on the positioning of ROLL, MANET, 6lowpan and quite frankly = we could add other WGs to the list.

So what = is the bottom line ?

We just need to agree = on the fact that there is no existing protocol that meets the ROLL = requirements and move to the next step (re-chartering) to select one = (hopefully not two) routing protocols in light of the routing = requirement (NOT the protocol survey), which can either be an adapted = MANET protocol or a new protocol.

Now moving to = your proposed resolution.



So, in a nutshell, I suggest that we address = (i) the positioning issue and (ii) the criteria issue thus:

o Describe = as I proposed above if ROLL and MANETs position themselves as I
have = deducted. If my deduction is incorrect, then let's quickly iterate on = the list
= = as to understand how to do produce an alternative description. If = we can't do this,
then the conclusion can be that = "we do not know how ROLL and MANET position
= themselves wrt each other", and we could then state that = clearly?
= =
= = It *should* not be more than a couple of paragraphs worth of text = to add, I gather?


If you find a = way to word this, please feel free and I'd be happy to help but feel it = as necessary ... Any opinion from our RTG and INT ADs = ?

o To the = criteria, either of:

- Add the assumption that "user = data traffic is so low that path lengths do not
matter = nor does the cost of carrying user data = traffice"


The motivation = for selecting a longer path is not tied to the amount of traffic here = but the level of constraints. Note that this is also true for several = other technologies such as MPLS-TE. You may have large amount of traffic = and still require to follow a non-shortest path (constrained based = routing). This is detailed in several requirements IDs. Criticality of = data is of course different, thus the requirements for potentially = different data paths according to packet marking using = DSCP.

- Add a = criteria & evaluation of "path length"

- Add a = criteria & evaluation of "total cost for getting user data through = the network"


And we can = add many more but if the current protocol do not satisfy existing = requirements, isn't it sufficient to answer the question on whether one = can find an existing protocol?

This would make a large chunk of my concerns and = issues vanish, and allow correctly interpreting and evaluating the rest = of the document.

That said, = question for the WG. Who think that such criteria should be added to = move forward ? Please reply.



How does that sound as an approach = forward?


Thanks for = helping = out.

Cheers.

JP.
Cheers,

Thomas

On Jan 27, = 2009, at 1:00 AM, Internet-Drafts@ietf.org = wrote:

A New Internet-Draft is = available from the on-line Internet-Drafts
directories.
This = draft is a work item of the Routing Over Low power and Lossy networks = Working Group of the IETF.

= Title = = : Overview of Existing Routing Protocols for Low Power and Lossy = Networks
= Author(s) = : A. Tavakoli, S. Dawson-Haggerty, P. = Levis
= Filename = : = draft-ietf-roll-protocols-survey-05.txt
= Pages = = : 26
Date : = 2009-1-26
=
Networks of low power = wireless devices introduce novel IP routing
  issues.  Low-power wireless devices, = such as sensors, actuators and
=   smart objects, have difficult constraints: very limited = memory,
  little = processing power, and long sleep periods.  As most of = these
  devices are = battery-powered, energy efficiency is = critically
=   important.  Wireless link qualities can vary = significantly over time,
=   requiring protocols to make agile decisions yet minimize = topology
  change = energy costs.  Routing over such low power and lossy = networks
  has = novel requirements that existing protocols may not address. =  This
=   document provides a brief survey of the strengths and = weaknesses of
=   existing protocols with respect to this class of networks. =  =46rom this
=   survey it examines whether existing and mature IETF = protocols can be
=   used without modification in these networks, or whether = further work
  is = necessary.
  is = necessary.

A URL for this = Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-s= urvey-05.txt

Internet-Drafts = are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-d= rafts/

Below is the = data which will enable a MIME compliant mail = reader
implementation to = automatically retrieve the ASCII version of = the
Internet-Draft.
Content-Type: text/plain
Content-ID: <2009-1-26155804.I-D@ietf.org<= /a>>

_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

_____________________________= __________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll



= --Apple-Mail-2--177822667-- --===============0928166290== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0928166290==-- From roll-bounces@ietf.org Tue Feb 3 09:27:42 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A74FC3A69A3; Tue, 3 Feb 2009 09:27:42 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87AC13A6B17 for ; Tue, 3 Feb 2009 09:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vbMSDHYUo0h for ; Tue, 3 Feb 2009 09:27:40 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 3D1763A68B3 for ; Tue, 3 Feb 2009 09:27:40 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n13HPepp029301; Tue, 3 Feb 2009 18:25:40 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n13HRIn3028562; Tue, 3 Feb 2009 18:27:18 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n13HRIMa007336; Tue, 3 Feb 2009 18:27:18 +0100 Message-ID: <49887E75.1090705@gmail.com> Date: Tue, 03 Feb 2009 18:27:17 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: JP Vasseur References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> In-Reply-To: Cc: roll@ietf.org Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org JP Vasseur a =E9crit : [...] > On your recommendation to explicitly indicate that NEMO will be > looked at, we will add it to the protocol survey. Does that satisfy > your requirement ? YEs, I agree. Do you want me to fork a separate thread with the NEMO text? And let me take advantage of this opening by re-suggesting the = correction of the protocols-survey ND text. There is an error here: protocols-survey draft: > The fact that all routers must respond to a Router Solicitation = > requires that the number of routers with a 1-hop neighborhood is > small, or there will be a reply implosion. Such reply implosion is avoided by the IPv6 ND spec, because it requires the RAs responding to an RS be spaced randomly in time: RFC4861 "ND for IPv6": > 6.2.6. Processing Router Solicitations [...] > In all cases, Router Advertisements sent in response to a Router > Solicitation MUST be delayed by a random time between 0 and = > MAX_RA_DELAY_TIME seconds. In this sense, do you want me to make a separate thread regarding this = ND text? Alex _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Feb 3 09:31:48 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D875F3A6B2E; Tue, 3 Feb 2009 09:31:48 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7AE43A6B96 for ; Tue, 3 Feb 2009 09:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4hY7RcS6z7n for ; Tue, 3 Feb 2009 09:31:46 -0800 (PST) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id 964173A6407 for ; Tue, 3 Feb 2009 09:31:46 -0800 (PST) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n13HVPlm007533 for ; Tue, 3 Feb 2009 17:31:25 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n13HVO8F024830 for ; Tue, 3 Feb 2009 17:31:24 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 03 Feb 2009 17:31:13 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Tue, 3 Feb 2009 17:31:23 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Feb 2009 17:31:19 -0000 Message-ID: In-Reply-To: <498878B9.80403@eecs.berkeley.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Review and comments Re:I-D ACTION:draft-ietf-roll-protocols-survey-05.txt Thread-Index: AcmGIU3jstD7QtK/T+ugVhZCr+zhKwAAHO0w References: <20090127000001.9F1F03A6819@core3.amsl.com><7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498878B9.80403@eecs.berkeley.edu> From: "Dearlove, Christopher (UK)" To: "David E. Culler" , "Thomas Heide Clausen" X-OriginalArrivalTime: 03 Feb 2009 17:31:23.0585 (UTC) FILETIME=[3C082B10:01C98625] Cc: Ross Callon , roll@ietf.org, Arsalan Tavakoli Subject: Re: [Roll] Review and comments Re:I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org I think this posting has taken a reasonable point and greatly overstated it. If it were in the draft, I'd certainly want it changed. > 1. The charter of MANET > (http://www.ietf.org/html.charters/manet-charter.html) does not even > contain the word POWER True, but as you go on to point out, it contains other phrases that equate to that limiting power is a good thing (to be balanced with other good things). > living for three hours on a monstrous laptop battery is rather > different from living for 3 years on a pair of AAs. True. And most MANETs don't have to live for 3 years on a pair of AAs - though I don't know any that wouldn't like to. But neither is 3 hours on a laptop battery the universal state of affairs either. > All the requirements are stationary. Really MANET should have been named DANET (dynamic, not mobile) but there wasn't a French impressionist painter of that name. Stationary (not physically moving) does not imply static, and many MANETs use their dynamism to cope with other forms of dynamism - node loss (power exhaustion, damage, theft etc.) and propagation changes (opening a door in a building can necessitate a reconfiguration, especially if the door is metal). Generally a slower timescale (but doors can open quite quickly). As I would see it, there is MANET, the concept. Everything ROLL is doing is within that space. But then there's MANET the WG, creating some general purpose protocols covering much of that space - not all, but more than (for example) earlier drafts of this document recognised. Do those protocols "as is" cover ROLL's space? No. So there's the justification for ROLL. But it does no one any favours to claim ROLL is "other" and totally different (and I still don't like "novel" in the abstract). It's an extreme case, but part of a continuum. Which leads to some people's issues. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Feb 3 09:31:54 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 107B33A6C48; Tue, 3 Feb 2009 09:31:54 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A330E3A6C48 for ; Tue, 3 Feb 2009 09:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXwTdYX-T5q8 for ; Tue, 3 Feb 2009 09:31:52 -0800 (PST) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 7C1443A6B96 for ; Tue, 3 Feb 2009 09:31:48 -0800 (PST) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n13HVQ5i023063 for ; Tue, 3 Feb 2009 17:31:26 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n13HVP0g024845 for ; Tue, 3 Feb 2009 17:31:25 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 03 Feb 2009 17:31:14 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Tue, 3 Feb 2009 17:31:25 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Feb 2009 17:31:21 -0000 Message-ID: In-Reply-To: <498874A8.9030206@ekasystems.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review andcomments draft-ietf-roll-protocols-survey-05.txt Thread-Index: AcmGHdNtIyd+vZx1QMuwD9Rftq1YegAAY7dw References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498874A8.9030206@ekasystems.com> From: "Dearlove, Christopher (UK)" To: "M. B. Anand" , "ROLL WG" X-OriginalArrivalTime: 03 Feb 2009 17:31:25.0140 (UTC) FILETIME=[3CF57140:01C98625] Subject: Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review andcomments draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org M.B. Anand > In a recent email, Emmanuel states: > "Basically, everybody agrees that something special must be done for > sensor ad hoc connectivity with IP, and everybody wants to reach the > next phase ASAP (i.e. work on solutions). " > > If everybody agrees on this, then this document should close without > needing any further discussion. The whole purpose of the document is to > document what everyone seems to agree on. Then, what is the disagreement ? That is a little simplistic. Let's suppose that the document said that protocol X is a bad protocol, totally unsuited for ROLL or any other work. Now suppose the authors of protocol X agreed it was unsuited for ROLL, but thought it was a highly valuable protocol for other work. Now as far as ROLL is concerned, there may be no difference. But if the document proceeded, there would then be an RFC saying protocol X is a bad protocol. It may get quoted in non-ROLL contexts. This would not be good. Now the ROLL document doesn't say protocol X is a bad protocol for any X. Some people however aren't entirely happy with some details the document includes, and would view this as a more limited case of such a problem. Maybe they are right, maybe they are wrong, maybe the best solution is a small change. (Some such small changes have already taken place.) The point is if this is going to be an RFC, it's not just the internal purposes of ROLL that matter. Note that I'm not saying I have such an issue (I think the document could be better, but am not sure it's worth the effort, and as I'm not volunteering the effort, that's a pass). But it's worth understanding why some people may have problems, as, if nothing else, that way you can reach agreement more easily. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Feb 3 09:40:29 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB2273A6C51; Tue, 3 Feb 2009 09:40:29 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A3CA3A6B99 for ; Tue, 3 Feb 2009 09:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.051 X-Spam-Level: X-Spam-Status: No, score=-4.051 tagged_above=-999 required=5 tests=[AWL=1.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNYdPnoFJUpk for ; Tue, 3 Feb 2009 09:40:27 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 91ABB3A6407 for ; Tue, 3 Feb 2009 09:40:27 -0800 (PST) Received: from [128.32.39.229] (dhcp-39-229.EECS.Berkeley.EDU [128.32.39.229]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n13He1bL028888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Feb 2009 09:40:02 -0800 (PST) Message-ID: <49888169.3070402@eecs.berkeley.edu> Date: Tue, 03 Feb 2009 09:39:53 -0800 From: "David E. Culler" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498874A8.9030206@ekasystems.com> In-Reply-To: Cc: ROLL WG Subject: Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review andcomments draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1963176303==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1963176303== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Absolutely.  The survey is not a beauty context.  Nor does it pas judgment on the value of any piece of work.  It in no way suggest that anything that is considered is "Bad".  It merely does the due diligence to determine if there is any work to be done.  And while we might quibble about the 3rd order or 4th order bit, the high order bit is unequivocally YES.  There is work to be done.

However, the recondition for doing that work is that the survey is done. 

Dearlove, Christopher (UK) wrote: 
M.B. Anand
  
In a recent email, Emmanuel states:
"Basically, everybody agrees that something special must be done for 
sensor ad hoc connectivity with IP, and everybody wants to reach the 
next phase ASAP (i.e. work on solutions). "

If everybody agrees on this, then this document should close without 
needing any further discussion. The whole purpose of the document is
    
to 
  
document what everyone seems to agree on. Then, what is the
    
disagreement ?

That is a little simplistic. Let's suppose that the document said
that protocol X is a bad protocol, totally unsuited for ROLL or any
other work. Now suppose the authors of protocol X agreed it was
unsuited for ROLL, but thought it was a highly valuable protocol
for other work. Now as far as ROLL is concerned, there may be no
difference. But if the document proceeded, there would then be an
RFC saying protocol X is a bad protocol. It may get quoted in
non-ROLL contexts. This would not be good.

Now the ROLL document doesn't say protocol X is a bad protocol for
any X. Some people however aren't entirely happy with some details
the document includes, and would view this as a more limited case
of such a problem. Maybe they are right, maybe they are wrong, maybe
the best solution is a small change. (Some such small changes have
already taken place.) The point is if this is going to be an RFC,
it's not just the internal purposes of ROLL that matter.

Note that I'm not saying I have such an issue (I think the document
could be better, but am not sure it's worth the effort, and as I'm
not volunteering the effort, that's a pass). But it's worth
understanding why some people may have problems, as, if nothing else,
that way you can reach agreement more easily.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--===============1963176303== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1963176303==-- From roll-bounces@ietf.org Tue Feb 3 09:40:51 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15C8A3A684C; Tue, 3 Feb 2009 09:40:51 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B5B43A684C for ; Tue, 3 Feb 2009 09:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.502 X-Spam-Level: X-Spam-Status: No, score=-10.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXCMKC4HmFyz for ; Tue, 3 Feb 2009 09:40:48 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C887F3A6407 for ; Tue, 3 Feb 2009 09:40:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,373,1231113600"; d="scan'208";a="32738538" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2009 17:40:27 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n13HeRTQ015850; Tue, 3 Feb 2009 18:40:27 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n13HeRSk005918; Tue, 3 Feb 2009 17:40:27 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 18:40:27 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 18:40:26 +0100 Message-Id: From: JP Vasseur To: "Dearlove, Christopher (UK)" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Feb 2009 18:40:25 +0100 References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498874A8.9030206@ekasystems.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Feb 2009 17:40:26.0947 (UTC) FILETIME=[7FE6A130:01C98626] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3088; t=1233682827; x=1234546827; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20*=20ALL=20PLEASE=20READ=20**=2 0TIME=20FOR=20CLOSURE=20?=20Re=3A=20Review=20andcomments=20d raft-ietf-roll-protocols-survey-05.txt |Sender:=20; bh=gPWw/k2aOjvoD71X6f2VAnNXT/jj40sg4P/Yqs8bwSI=; b=vKCdC8tEuMiZJecblyWsO14RqpuMF4y7xSJ4tlrRdOPvosD3sL+DmBbK8A S2vmzmc5qwGbnp8Bq6oRS3A1iywavVWlgLt0HMGaTvcQXh+SQWwfx23xv7IM 4B0atzdQ9w; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG Subject: Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review andcomments draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Christopher, On Feb 3, 2009, at 6:31 PM, Dearlove, Christopher (UK) wrote: > > M.B. Anand >> In a recent email, Emmanuel states: >> "Basically, everybody agrees that something special must be done for >> sensor ad hoc connectivity with IP, and everybody wants to reach the >> next phase ASAP (i.e. work on solutions). " >> >> If everybody agrees on this, then this document should close without >> needing any further discussion. The whole purpose of the document is > to >> document what everyone seems to agree on. Then, what is the > disagreement ? > > That is a little simplistic. Let's suppose that the document said > that protocol X is a bad protocol, totally unsuited for ROLL or any > other work. I hope that you do not interpret the conclusion on the suitability of a protocol to a specific issue as "this protocol is BAD". > Now suppose the authors of protocol X agreed it was > unsuited for ROLL, but thought it was a highly valuable protocol > for other work. Now as far as ROLL is concerned, there may be no > difference. There is a difference. We say: * This protocol does not (in ITS CURRENT STATE) meet the requirements. * The authors are welcome to propose a modified version in the next step ! > But if the document proceeded, there would then be an > RFC saying protocol X is a bad protocol. It may get quoted in > non-ROLL contexts. This would not be good. It will not, the survey is quite clear on this. We can make sure to add 1-2 sentences very explicitly if you will. > > > Now the ROLL document doesn't say protocol X is a bad protocol for > any X. Some people however aren't entirely happy with some details > the document includes, and would view this as a more limited case > of such a problem. Maybe they are right, maybe they are wrong, maybe > the best solution is a small change. (Some such small changes have > already taken place.) The point is if this is going to be an RFC, > it's not just the internal purposes of ROLL that matter. > Informational RFC with limited scope (very explicitly pointed out in the I-D). > Note that I'm not saying I have such an issue (I think the document > could be better, but am not sure it's worth the effort, and as I'm > not volunteering the effort, that's a pass). But it's worth > understanding why some people may have problems, as, if nothing else, > that way you can reach agreement more easily. Sure, thanks. JP. > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > 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 From roll-bounces@ietf.org Tue Feb 3 09:42:23 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FF2B3A6C57; Tue, 3 Feb 2009 09:42:23 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 911AB3A6C48 for ; Tue, 3 Feb 2009 09:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.204 X-Spam-Level: X-Spam-Status: No, score=-10.204 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOM8Iy84PiNF for ; Tue, 3 Feb 2009 09:36:59 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D70623A6C5C for ; Tue, 3 Feb 2009 09:36:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,373,1231113600"; d="scan'208,217";a="32738125" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2009 17:36:30 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n13HaU4q027297; Tue, 3 Feb 2009 18:36:30 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n13HaUHO004691; Tue, 3 Feb 2009 17:36:30 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 18:36:30 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 18:36:28 +0100 Message-Id: From: JP Vasseur To: David Ward , ROLL WG , Thomas Heide Clausen , Emmanuel Baccelli , Alexandru Petrescu In-Reply-To: <7F8459D1-3464-435A-AF8F-F9C437036FDF@cisco.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Feb 2009 18:36:27 +0100 References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <7F8459D1-3464-435A-AF8F-F9C437036FDF@cisco.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Feb 2009 17:36:29.0147 (UTC) FILETIME=[F2293AB0:01C98625] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=51081; t=1233682590; x=1234546590; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20*=20ALL=20PLEASE=20READ=20**=20TIME=20F OR=20CLOSURE=20?=20Re=3A=20[Roll]=20Review=20and=20comments= 20draft-ietf-roll-protocols-survey-05.txt |Sender:=20; bh=/Ypy9nhcMvOgsG0xCaOvnQhpmcs29QtWwOU6Yqc+h/8=; b=rDd6xvG9ekxzepWV/qDliOM1FGfUQkoh2DuwDscSi/3IJLjcCc73a9gr9w gPE5LxpbPxWGANvoY+ry+9iUxgHGBz95D88sBg7Lpn45H0GyBRRhOVBRWj+q 7+BvfoBzGa; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Mailman-Approved-At: Tue, 03 Feb 2009 09:42:22 -0800 Cc: Arsalan Tavakoli , Geoff Mulligan , "David E. Culler" , stevedh@cs.berkeley.edu, mtownsley@cisco.com, Jari Arkko , Ross Callon Subject: Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review and comments draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1944694172==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1944694172== Content-Type: multipart/alternative; boundary=Apple-Mail-118--175166438 --Apple-Mail-118--175166438 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Thanks Dave for AD's feed-back. We *are* making progress and looking at all the interest that we are gathering from many participants, this is a good sign of strong participation for the next phase, a key of success. First of all, I would like to remind that all the routing requirements documents are finalized. I asked for a last revision of the building routing requirements documents before publication request. And then we will be done for this part. Lot of work. Here is what I propose: 1) I guess that things have been clarified on the WG positioning issue. 2) Many supportive request to close on this and move forward. 3) Still there are a few requests that have been made by Thomas, Alex, ... that we should try to address. May I ask you to try to limit as much as possible your request and we will do everything possible to address them. 4) End of this week, we will close on the protocol survey. 5) Right after we'll propose you a new charter (one week discussion) before IESG submission. 6) If/once re-chartered, we count on everybody's help to continue the good work. Thanks. JP. On Feb 3, 2009, at 5:52 PM, David Ward wrote: > All - > > We debated the delta between these three WGs when chartering ROLL > for a considerable period of time. I do not want to revisit that > debate but, I will quickly summarize here > > - 6LOWPAN is not working at the IP layer so, the overlap here is > really not an issue. > - MANET is and has been working on routing protocols for mobile, ad > hoc networks with specific requirements and use cases. Some of those > use cases may or may not overlap with ROLL. There will be lessons to > be learned but, the primary use cases being worked on appeared by > all the chairs and ADs involved to be different enough to warrant a > new WG in this area. > - ROLL was originally chartered to write the requirements and > evaluate existing protocols for low power, lossy networks running > over IP (some call these "sensor networks"). ROLL is only chartered > to work on the routing protocol portion. Not the transport, encap or > other topics at this time. Also note that mobility is not under > consideration at this time. > > ROLL WG appears to have come to consensus on the requirement docs > that state specific functions, attributes, power/memory envelope and > algorithmic considerations that must be "in the routing protocol" > for these networks. The survey ID (which is of course a snapshot at > one point in time) puts some bounds on mapping the required > functions, attributes and other considerations into protocols > available *today.* > > Given the real work of designing a protocol hasn't begun by the ROLL > WG participants; holding up the WG to begin taking what they > currently defined as a very complex, multivariate problem and begin > whittling it down to something solvable via theoretical and > hypothetical exercises seems like an unwise use of time given the > experience and energy of the WG in this problem space. The WG must > move beyond the moderately high-level boundary setting exercise > (which I believe there is consensus) and move onto the more > challenging work of defining the objects, algorithms, semantics, > state machines and functionality of the protocol. In the design > phase (vs the survey phase) a better evaluation can be made of the > ease or difficulty of "from scratch" or "modify what we have" can be > made. I expect "wild swings" of the design pattern of the protocol > during the first year of the design effort. I attempted to make this > clear at the mic in Minneapolis that the current trajectory is very > complex problem domain that hasn't born a lot of fruit but, that in > the design phase reducing the complexity must occur. Members of the > WG who have vast experience in these types of networks and have > widely deployed products have stated that the routing protocol > issues are solvable problems with some simplifying assumptions. I > look forward to the WG making these design decisions and tradeoffs > and debating the structure of the protocol. Any protocol reuse, > experience, etc will be critical at this point to make the correct > choices and I look to MANET, ROLL, MEXT, 6LOWPAN and other IETF'ers > with routing protocol experience to contribute. This is an industry > important juncture and moving LPLN to IP is a critical change. > > I am looking to the WG chairs to declare loose consensus on the > documents (when appropriate) so that the rechartering of the WG to > enter the design phase can occur. WIthout a doubt, the requirements > as-is have defined the boundary of the work effort and I believe it > is clear what is the difference between the WGs. > > > HIH > > -DWard > > > > > On Feb 3, 2009, at 7:14 AM, Thomas Heide Clausen wrote: > >> Dear JP, dear ADs, dear WG, >> >> (I Cc the other INT chair, as he's following 6lowpan) >> >> For the record, I am not arguing that MANET protocols should be >> applied or be applicable -- as you seem to suggest in your email. I >> believe that I have stated so repeatedly. >> >> I submit, however, that as it is currently exposed, ROLL, MANET and >> 6LOW seem to be operating within the same space -- to the untrained >> eye, in exactly the same space. My position is that it would be >> very unfortunate having one WG creating confusion on the >> applicability of the work of itself and of other IETF wg's, by >> simple omission of suitable perimeter definitions. >> >> In that sort of situation, the IETF needs to be extra prudent to >> make sure to clearly spell out suitable perimeter definitions prior >> to, or conjointly with, the first publication cycle. In this case, >> before or with the survey I-D. >> >> Sincerely, >> >> Thomas >> >> >> On Feb 3, 2009, at 1:19 PM, JP Vasseur wrote: >> >>> Dear WG and ADs, >>> >>> Two issues are raised here for which we would appreciate ADs' >>> point of view and feed-back from the WG. Please see in line. >>> >>> >>> Dear Thomas, >>> >>> At the risk of repeating myself, I'd like to make a few important >>> statements before *hopefully* come to a closure ;-) >>> >>> -> As you know, many of the ROLL WG active participants have been >>> working quite hard to produce a detailed set of requirements, >>> discuss how to proceed on the protocol survey document, and other >>> ID are in the works. >>> -> We managed to get highly experienced contributors in the field >>> that have designed and deployed solutions so they not only have an >>> excellent expertise of the requirements but also on solutions, >>> -> Yes we need to rush out. Why ? Because proprietary or semi- >>> closed non-IP solutions are being deployed at a fairly large >>> scale. I do not think that I have to convince anybody on this list >>> that this is the WRONG approach for a number of reasons. The >>> industry is asking for an IP solution *now*. >>> -> No we do not want to re-invent the wheel (see our presentation >>> at the routing plenary in Chicago). Anything that already exists >>> MUST (rfc2119 ;-)) be used provided that it meets our >>> requirements. And if we can adapt an existing protocol, we are all >>> for it ! >>> -> Yes these requirements are quite specifics and this is >>> precisely why ROLL has been formed, 4 application-specific routing >>> requirements have been produced (to reduce the scope). Even if at >>> a first sight, it looks very much similar to a MANET issue (and >>> there ARE similarities but also very different requirements), >>> having to deal with a highly static network of hundreds of >>> thousands of battery operated sleeping nodes with 4K of RAM is >>> quite specific. Note that this is not a random example, but an on- >>> going non-IP deployed network. >>> >>> And to conclude on this introduction ... after an outstanding >>> progress on the WG during the first 6-8 months, we have been >>> slowed down dramatically for the last 2 months, thus it is time to >>> close and move on to quickly re-charter and start the protocol >>> work (hopefully as light as possible) to see IP-based solution >>> deployed. I know that we are on the same page, we just need to >>> find a good compromise on both "sides". >>> >>> Nothing new so far, let's move to a proposed resolution - See in >>> line, >>> >>> On Feb 2, 2009, at 7:37 PM, Thomas Heide Clausen wrote: >>> >>>> All, >>>> >>>> I promised a review, and I apologize that I wasn't able to do so >>>> before the weekend as originally projected. >>>> >>>> Other than some typos that Chris and others have pointed out, >>>> I'll try to offer my understanding of the problem space and >>>> suggest some ways of addressing my main concerns.... >>>> >>>> My first main concern remain that it is not clear, still, how >>>> ROLL positions itself with respect to MANET, 6LOW et. al, all of >>>> which appear to be within the same space and within the IETF. >>>> This I-D sees ROLL as presented with entirely new problems (the >>>> use of "novel" in the abstract, the statement that "existing >>>> protocols were not designed with these requirements in mind" seem >>>> to confirm this). >>>> >>>> Looking at the requirements listed, including "low power, low >>>> bandwidth, low footprint", these appear similar to those which >>>> are also brought forward in e.g. MANET and 6LOW. Reading >>>> (quickly, I confess) the various requirements documents of the >>>> draft-ietf-roll series present scenarios which are similar to >>>> those where MANETs are deployed, and are thought deployed, as well. >>>> >>>> I also note that many additional (and unstated) characteristics >>>> between ROLL and e.g. MANET are the same: mobile, wireless, >>>> fragility, auto-configuration, IP routing, interface/link issues... >>>> >>>> Arguing that, as does this I-D, despite the above impression >>>> "ROLL is novel and different" invites asking "how, exactly?" I >>>> think that this question is valid, and merits being answered, >>>> before the evaluations in this I-D can be judged fairly. >>>> >>>> Note that I come from a MANET background, and so I *could* >>>> interpret from the ROLL discussion that where MANETs may aim for >>>> "low power, low bandwidth, ....", ROLL may be able to quantify >>>> these as "below this firm threshold" -- i.e. as a sort of >>>> "extreme" or "constrained" MANET. >>>> >>>> This is a personal observation, I note, which would allow me to >>>> comprehend how ROLL and MANET are positioned relative to one >>>> another -- but one which neither this I-D nor the requirements >>>> document spell out or quantify -- or, for that matter, debunk. >>>> >>>> I think it's critical to understand this, in order to understand >>>> the need for a new protocol development. I think it is important >>>> to document this understanding in something with more persistency. >>>> >>>> If what I suggest above makes sense as a way of positioning ROLL >>>> and MANET relative to one another, I'd suggest including >>>> something to this effect in the survey I-D, as this I-D is the >>>> one making a *direct* reference to the applicability of MANET >>>> protocols to ROLL. >>>> >>>> If what I suggest doesn't make sense at all, then I'd be happy to >>>> have it debunked and, hopefully, through that debunking a >>>> positioning/description that does ring true with us all can be >>>> produced? >>>> >>>> My second main concern is, that I still think that the choice of >>>> criteria is unfortunate (not the word, Phill has me convinced on >>>> that front, but the actual criteria). Control cost is, by all >>>> means, a rather meaningless criteria when taken in isolation. >>>> I've sketched a "zero-control-cost" routing protocol (flood all >>>> data - say use SMF, also a MANET protocol, and also a rather >>>> "mature" I-D and wg item) which would score well on the control >>>> cost criteria, but would likely be an extremely bad choice for >>>> delivering unicast data. >>>> >>>> The metric which matters, and which should matter to ROLL in >>>> particular, is "the total cost of getting user data through the >>>> network, including control cost necessary to set up paths" -- as >>>> we know, every packet sent and received costs bandwidth, energy >>>> and cycles -- user data no different from contro. >>>> >>>> According to the criterions as set up by this I-D, a protocol >>>> producing "longer than shortest paths" at the benefit of slightly >>>> lower control cost would score better than a protocol producing >>>> "shortest paths" with slightly higher control cost. This is not >>>> hypothetical, btw., there are plenty of studies observing and >>>> reflecting upon this regarding the different MANET protocols, in >>>> academic literature -- and observed in real networks as well. >>>> >>>> I note that this trade-off (slightly longer paths for lower >>>> control cost) may be perfectly fair, assuming that very low >>>> amounts of user data traffic transit through the network. >>>> However, I do not see this assumption mentioned as a >>>> justification for focusing on the control cost metric and >>>> discarding the "path length" or the "total cost of getting user >>>> data through the network". >>>> >>>> I believe that either these assumptions should be made explicit >>>> ("there's so little user data traffic in a ROLL network that we >>>> do not care about shortest paths") or -- if these assumptions do >>>> not hold, that the evaluation criteria are incomplete. >>>> >>>> I note that it's true that we can always add another criteria ad >>>> infinitum, and that's CLEARLY not what we want to do. However >>>> when I say "incomplete" in the above, I simply suggest that based >>>> on what is presented one cannot draw conclusions based on the >>>> evaluation criteria....or, worse, that one draws the wrong >>>> conclusions based on the information presented. >>> >>> It is not easy to answer each of your point without running the >>> risk to start a debate that will never end. You raised some >>> excellent points that I agree with and others that I firmly >>> disagree with ... So let me try to make a few observations: >>> 1) As pointed out earlier, yes there are similarities between >>> MANET and ROLL. I do not see this as an issue. >>> 2) The aim of the protocol survey IS NOT to exclude MANET >>> protocols. As mentioned many times on the list, we *only* wanted >>> to show that existing protocols, with no change, could not be used >>> in LLNs. This has been clarified in the document as your request >>> and it HAD to be clarified. >>> 3) We could have used two different approaches for the survey: >>> - Look at all MUST from the requirements documents >>> - Try to derive a subset of necessary but not sufficient >>> criteria, which the WG chose to do (consensus). Yes this list is >>> not perfect, >>> criteria could be changed, removed or added but looked good >>> enough with excellent consensus until LC. >>> 4) With regards to 6lowpan (I copy the chair), I do not see any >>> overlap at all. Please refer to their charter and WG items. The >>> only place that required clarification was the routing >>> requirements and I was personally opposed to it but this was >>> adopted as a 6lowpan WG item by consensus. We're are working >>> together and managed to sort this out. This document will be >>> 6lowpan specific. >>> >>> What I want to avoid is an endless discussion on the positioning >>> of ROLL, MANET, 6lowpan and quite frankly we could add other WGs >>> to the list. >>> >>> So what is the bottom line ? >>> >>> We just need to agree on the fact that there is no existing >>> protocol that meets the ROLL requirements and move to the next >>> step (re-chartering) to select one (hopefully not two) routing >>> protocols in light of the routing requirement (NOT the protocol >>> survey), which can either be an adapted MANET protocol or a new >>> protocol. >>> >>> Now moving to your proposed resolution. >>> >>>> >>>> >>>> So, in a nutshell, I suggest that we address (i) the positioning >>>> issue and (ii) the criteria issue thus: >>>> >>>> o Describe as I proposed above if ROLL and MANETs position >>>> themselves as I >>>> have deducted. If my deduction is incorrect, then let's quickly >>>> iterate on the list >>>> as to understand how to do produce an alternative description. >>>> If we can't do this, >>>> then the conclusion can be that "we do not know how ROLL and >>>> MANET position >>>> themselves wrt each other", and we could then state that clearly? >>>> >>>> It *should* not be more than a couple of paragraphs worth of >>>> text to add, I gather? >>>> >>> >>> If you find a way to word this, please feel free and I'd be happy >>> to help but feel it as necessary ... Any opinion from our RTG and >>> INT ADs ? >>> >>>> o To the criteria, either of: >>>> >>>> - Add the assumption that "user data traffic is so low that >>>> path lengths do not >>>> matter nor does the cost of carrying user data traffice" >>>> >>> >>> The motivation for selecting a longer path is not tied to the >>> amount of traffic here but the level of constraints. Note that >>> this is also true for several other technologies such as MPLS-TE. >>> You may have large amount of traffic and still require to follow a >>> non-shortest path (constrained based routing). This is detailed in >>> several requirements IDs. Criticality of data is of course >>> different, thus the requirements for potentially different data >>> paths according to packet marking using DSCP. >>> >>>> - Add a criteria & evaluation of "path length" >>>> >>>> - Add a criteria & evaluation of "total cost for getting user >>>> data through the network" >>>> >>> >>> And we can add many more but if the current protocol do not >>> satisfy existing requirements, isn't it sufficient to answer the >>> question on whether one can find an existing protocol? >>> >>>> This would make a large chunk of my concerns and issues vanish, >>>> and allow correctly interpreting and evaluating the rest of the >>>> document. >>> >>> That said, question for the WG. Who think that such criteria >>> should be added to move forward ? Please reply. >>> >>>> >>>> >>>> How does that sound as an approach forward? >>>> >>> >>> Thanks for helping out. >>> >>> Cheers. >>> >>> JP. >>> >>>> Cheers, >>>> >>>> Thomas >>>> >>>> On Jan 27, 2009, at 1:00 AM, Internet-Drafts@ietf.org wrote: >>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> This draft is a work item of the Routing Over Low power and >>>>> Lossy networks Working Group of the IETF. >>>>> >>>>> Title : Overview of Existing Routing Protocols for Low Power >>>>> and Lossy Networks >>>>> Author(s) : A. Tavakoli, S. Dawson-Haggerty, P. Levis >>>>> Filename : draft-ietf-roll-protocols-survey-05.txt >>>>> Pages : 26 >>>>> Date : 2009-1-26 >>>>> >>>>> Networks of low power wireless devices introduce novel IP routing >>>>> issues. Low-power wireless devices, such as sensors, >>>>> actuators and >>>>> smart objects, have difficult constraints: very limited memory, >>>>> little processing power, and long sleep periods. As most of >>>>> these >>>>> devices are battery-powered, energy efficiency is critically >>>>> important. Wireless link qualities can vary significantly >>>>> over time, >>>>> requiring protocols to make agile decisions yet minimize >>>>> topology >>>>> change energy costs. Routing over such low power and lossy >>>>> networks >>>>> has novel requirements that existing protocols may not >>>>> address. This >>>>> document provides a brief survey of the strengths and >>>>> weaknesses of >>>>> existing protocols with respect to this class of networks. >>>>> From this >>>>> survey it examines whether existing and mature IETF protocols >>>>> can be >>>>> used without modification in these networks, or whether >>>>> further work >>>>> is necessary. >>>>> is necessary. >>>>> >>>>> A URL for this Internet-Draft is: >>>>> http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-survey-05.txt >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> Below is the data which will enable a MIME compliant mail reader >>>>> implementation to automatically retrieve the ASCII version of the >>>>> Internet-Draft. >>>>> Content-Type: text/plain >>>>> Content-ID: <2009-1-26155804.I-D@ietf.org> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> > --Apple-Mail-118--175166438 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Thanks Dave for AD's = feed-back.

We *are* making progress and looking at = all the interest that we are gathering from many participants, this is a = good sign of strong participation for the next phase, a key of = success.

First of all, I would like to remind = that all the routing requirements documents are finalized. I asked for a = last revision of the building routing requirements documents before = publication request. And then we will be done for this part. Lot of = work.

Here is what I = propose:

1) I guess that things have been = clarified on the WG positioning issue.
2) Many supportive = request to close on this and move forward.
3) Still there = are a few requests that have been made by Thomas, Alex, ... that we = should try to address.
May I ask you to try to limit as = much as possible your request and we will do everything possible to = address them.
4) End of this week, we will close on the = protocol survey.
5) Right after we'll propose you a new = charter (one week discussion) before IESG submission.
6) = If/once re-chartered, we count on everybody's help to continue the good = work.

Thanks.

JP.
<= div>

On Feb 3, 2009, at 5:52 PM, David = Ward wrote:

All = -

We debated the delta between these three WGs = when chartering ROLL for a considerable period of time. I do not want to = revisit that debate but, I will quickly summarize = here

- 6LOWPAN is not working at the IP layer = so, the overlap here is really not an issue.
- MANET is and = has been working on routing protocols for mobile, ad hoc networks with = specific requirements and use cases. Some of those use cases may or may = not overlap with ROLL. There will be lessons to be learned but, the = primary use cases being worked on appeared by all the chairs and ADs = involved to be different enough to warrant a new WG in this = area.
- ROLL was originally chartered to write the = requirements and evaluate existing protocols for low power, lossy = networks running over IP (some call these  "sensor networks"). ROLL = is only chartered to work on the routing protocol portion. Not the = transport, encap or other topics at this time. Also note that mobility = is not under consideration at this time.

ROLL = WG appears to have come to consensus on the requirement docs that state = specific functions, attributes, power/memory envelope and algorithmic = considerations that must be "in the routing protocol" for these = networks. The survey ID (which is of course a snapshot at one point in = time) puts some bounds on mapping the required functions, attributes and = other considerations into protocols available = *today.*

Given the real work of designing a = protocol hasn't begun by the ROLL WG participants; holding up the WG to = begin taking what they currently defined as a very complex, multivariate = problem and begin whittling it down to something solvable via = theoretical and hypothetical exercises seems like an unwise use of time = given the experience and energy of the WG in this problem space. =  The WG must move beyond the moderately high-level boundary setting = exercise (which I believe there is consensus) and move onto the more = challenging work of defining the objects, algorithms, semantics, state = machines and functionality of the protocol.  In the design phase = (vs the survey phase) a better evaluation can be made of the ease or = difficulty of "from scratch" or "modify what we have" can be made. I = expect "wild swings" of the design pattern of the protocol during the = first year of the design effort. I attempted to make this clear at the = mic in Minneapolis that the current trajectory is very complex problem = domain that hasn't born a lot of fruit but, that in the design phase = reducing the complexity must occur. Members of the WG who have vast = experience in these types of networks and have widely deployed products = have stated that the routing protocol issues are solvable problems with = some simplifying assumptions. I look forward to the WG making these = design decisions and tradeoffs and debating the structure of the = protocol. Any protocol reuse, experience, etc will be critical at this = point to make the correct choices and I look to MANET, ROLL, MEXT, = 6LOWPAN and other IETF'ers with routing protocol experience to = contribute. This is an industry important juncture and moving LPLN to IP = is a critical change.

I am looking to the WG = chairs to declare loose consensus on the documents  (when = appropriate) so that the rechartering of the WG to enter the design = phase can occur. WIthout a doubt, the requirements as-is have defined = the boundary of the work effort and I believe it is clear what is the = difference between the = WGs.


HIH

= -DWard




On = Feb 3, 2009, at 7:14 AM, Thomas Heide Clausen wrote:

Dear JP, dear ADs, dear = WG,

(I Cc the other INT chair, as he's following = 6lowpan)

For the record, I am not arguing that = MANET protocols should be applied or be applicable -- as you seem to = suggest in your email. I believe that I have stated so = repeatedly.

I submit, = however, that as it is currently exposed, ROLL, MANET and 6LOW seem to = be operating within the same space -- to the untrained eye, in exactly = the same space. My position is that it would be very unfortunate = having one WG creating confusion on the applicability of the work of = itself and of other IETF wg's, by simple omission of suitable perimeter = definitions. 

In that sort of situation, the IETF needs to be = extra prudent to make sure to clearly spell out suitable perimeter = definitions prior to, or conjointly with, the first publication cycle. = In this case, before or with the survey I-D.


Thomas

On Feb 3, = 2009, at 1:19 PM, JP Vasseur wrote:

Dear = WG and ADs,

Two issues are raised here for = which we would appreciate ADs' point of view and feed-back from the WG. = Please see in line.


Dear = Thomas,

At the risk of repeating myself, I'd like to = make a few important statements before *hopefully* come to a closure = ;-)

-> As you know, many of the ROLL WG active = participants have been working quite hard to produce a detailed set of = requirements, discuss how to proceed on the protocol survey document, = and other ID are in the works.
-> We managed to get highly = experienced contributors in the field that have designed and = deployed solutions so they not only have an excellent expertise of the = requirements but also on solutions,
-> Yes we need to rush = out. Why ? Because proprietary or semi-closed non-IP solutions are being = deployed at a fairly large scale. I do not think that I have to convince = anybody on this list that this is the WRONG approach for a number of = reasons. The industry is asking for an IP solution = *now*.
-> No we do not want to re-invent the wheel (see = our presentation at the routing plenary in Chicago). Anything that = already exists MUST (rfc2119 ;-)) be used provided that it meets our = requirements. And if we can adapt an existing protocol, we are all for = it !
-> Yes these requirements are quite specifics and this is = precisely why ROLL has been formed, 4 application-specific routing = requirements have been produced (to reduce the scope). Even if at a = first sight, it looks very much similar to a MANET issue (and there ARE = similarities but also very different requirements), having to deal with = a highly static network of hundreds of thousands of battery operated = sleeping nodes with 4K of RAM is quite specific. Note that this is not a = random example, but an on-going non-IP deployed = network.

And to conclude on this introduction = ... after an outstanding progress on the WG during the first 6-8 months, = we have been slowed down dramatically for the last 2 months, thus it is = time to close and move on to quickly re-charter and start the protocol = work (hopefully as light as possible) to see IP-based solution deployed. = I know that we are on the same page, we just need to find a good = compromise on both "sides".

Nothing new so far, = let's move to a proposed resolution - See in = line,

On Feb 2, 2009, at 7:37 PM, = Thomas Heide Clausen wrote:

All,

I promised a review, and I apologize that = I wasn't able to do so before the weekend as originally = projected.

Other than some typos that Chris and others have = pointed out, I'll try to offer my understanding of the problem space and = suggest some ways of addressing my main concerns....

My first = main concern remain that it is not clear, still, how ROLL positions = itself with respect to MANET, 6LOW et. al, all of which appear to be = within the same space and within the IETF. This I-D sees ROLL as = presented with entirely new problems (the use of "novel" in the = abstract, the statement that "existing protocols were not designed with = these requirements in mind" seem to confirm this).

Looking at the =  requirements listed, including "low power, low bandwidth, low = footprint", these appear similar to those which are also brought forward = in e.g. MANET and 6LOW. Reading (quickly, I confess) the various = requirements documents  of the draft-ietf-roll series present = scenarios which are similar to those where MANETs are deployed, and are = thought deployed, as well.

I also note that many additional (and = unstated) characteristics between ROLL and e.g. MANET are the same: = mobile, wireless, fragility, auto-configuration, IP routing, = interface/link issues...

Arguing that, as does this I-D, despite = the above impression "ROLL is novel and different" invites asking "how, = exactly?" I think that this question is valid, and merits being = answered, before the evaluations in this I-D can be judged = fairly.

Note that I come from a MANET background, and so I = *could* interpret from the ROLL discussion that where MANETs may aim for = "low power, low bandwidth, ....", ROLL may be able to quantify these as = "below this firm threshold" -- i.e. as a sort of "extreme" or = "constrained" MANET.

This is a personal observation, I note, = which would allow me to comprehend how ROLL and MANET are positioned = relative to one another -- but one which neither this I-D nor the = requirements document spell out or quantify -- or, for that matter, = debunk.

I think it's critical to understand this, in order to = understand the need for a new protocol development. I think it is = important to document this understanding in something with more = persistency.

If what I suggest above makes sense as a way of = positioning ROLL and MANET relative to one another, I'd suggest = including something to this effect in the survey I-D, as this I-D is the = one making a *direct* reference to the applicability of MANET protocols = to ROLL.

If what I suggest doesn't make sense at all, then I'd be = happy to have it debunked and, hopefully, through that debunking a = positioning/description that does ring true with us all can be = produced?

My second main concern is, that I still think that the = choice of criteria is unfortunate (not the word, Phill has me convinced = on that front, but the actual criteria). Control cost is, by all means, = a rather meaningless criteria when taken in isolation. I've sketched a = "zero-control-cost" routing protocol (flood all data - say use SMF, also = a MANET protocol, and also a rather "mature" I-D and wg item) which = would score well on the control cost criteria, but would likely be an = extremely bad choice for delivering unicast data.

The metric = which matters, and which should matter to ROLL in particular, is "the = total cost of getting user data through the network, including control = cost necessary to set up paths" -- as we know, every packet sent and = received costs bandwidth, energy and cycles -- user data no different = from contro.

According to the criterions as set up by this I-D, a = protocol producing "longer than shortest paths" at the benefit of = slightly lower control cost would score better than a protocol producing = "shortest paths" with slightly higher control cost. This is not = hypothetical, btw., there are plenty of studies observing and reflecting = upon this regarding the different MANET protocols, in academic = literature -- and observed in real networks as well.

I note that = this trade-off (slightly longer paths for lower control cost) may be = perfectly fair, assuming that very low amounts of user data traffic = transit through the network. However, I do not see this assumption = mentioned as a justification for focusing on the control cost metric and = discarding the "path length" or the "total cost of getting user data = through the network".

I believe that either these assumptions = should be made explicit ("there's so little user data traffic in a ROLL = network that we do not care about shortest paths") or -- if these = assumptions do not hold, that the evaluation criteria are = incomplete.

I note that it's true that we can always add another = criteria ad infinitum, and that's CLEARLY not what we want to do. = However when I say "incomplete" in the above, I simply suggest that = based on what is presented one cannot draw conclusions based on the = evaluation criteria....or, worse, that one draws the wrong conclusions = based on the information = presented.

It is not easy to = answer each of your point without running the risk to start a debate = that will never end. You raised some excellent points that I agree with = and others that I firmly disagree with ... So let me try to make a few = observations:
1) As pointed out earlier, yes there are = similarities between MANET and ROLL. I do not see this as an = issue.
2) The aim of the protocol survey IS NOT to exclude = MANET protocols. As mentioned many times on the list, we *only* wanted = to show that existing protocols, with no change, could not be used in = LLNs. This has been clarified in the document as your request and it HAD = to be clarified.
3) We could have used two different = approaches for the survey:
- Look at all MUST from the = requirements documents
- Try to derive a subset of = necessary but not sufficient criteria, which the WG chose to do = (consensus). Yes this list is not perfect,
criteria = could be changed, removed or added but looked good enough with excellent = consensus until LC.
4) With regards to 6lowpan (I copy the = chair), I do not see any overlap at all. Please refer to their charter = and WG items. The only place that required clarification was the routing = requirements and I was personally opposed to it but this was adopted as = a 6lowpan WG item by consensus. We're are working together and = managed to sort this out. This document will be 6lowpan = specific.

What I want to avoid is an endless = discussion on the positioning of ROLL, MANET, 6lowpan and quite frankly = we could add other WGs to the list.

So what = is the bottom line ?

We just need to agree = on the fact that there is no existing protocol that meets the ROLL = requirements and move to the next step (re-chartering) to select one = (hopefully not two) routing protocols in light of the routing = requirement (NOT the protocol survey), which can either be an adapted = MANET protocol or a new protocol.

Now moving to = your proposed resolution.



So, in a nutshell, I suggest that we address = (i) the positioning issue and (ii) the criteria issue thus:

o Describe = as I proposed above if ROLL and MANETs position themselves as I
have = deducted. If my deduction is incorrect, then let's quickly iterate on = the list
= = as to understand how to do produce an alternative description. If = we can't do this,
then the conclusion can be that = "we do not know how ROLL and MANET position
= themselves wrt each other", and we could then state that = clearly?
= =
= = It *should* not be more than a couple of paragraphs worth of text = to add, I gather?


If you find a = way to word this, please feel free and I'd be happy to help but feel it = as necessary ... Any opinion from our RTG and INT ADs = ?

o To the = criteria, either of:

- Add the assumption that "user = data traffic is so low that path lengths do not
matter = nor does the cost of carrying user data = traffice"


The motivation = for selecting a longer path is not tied to the amount of traffic here = but the level of constraints. Note that this is also true for several = other technologies such as MPLS-TE. You may have large amount of traffic = and still require to follow a non-shortest path (constrained based = routing). This is detailed in several requirements IDs. Criticality of = data is of course different, thus the requirements for potentially = different data paths according to packet marking using = DSCP.

- Add a = criteria & evaluation of "path length"

- Add a = criteria & evaluation of "total cost for getting user data through = the network"


And we can = add many more but if the current protocol do not satisfy existing = requirements, isn't it sufficient to answer the question on whether one = can find an existing protocol?

This would make a large chunk of my concerns and = issues vanish, and allow correctly interpreting and evaluating the rest = of the document.

That said, = question for the WG. Who think that such criteria should be added to = move forward ? Please reply.



How does that sound as an approach = forward?


Thanks for = helping = out.

Cheers.

JP.
Cheers,

Thomas

On Jan 27, = 2009, at 1:00 AM, Internet-Drafts@ietf.org = wrote:

A New Internet-Draft is = available from the on-line Internet-Drafts
directories.
This = draft is a work item of the Routing Over Low power and Lossy networks = Working Group of the IETF.

= Title = = : Overview of Existing Routing Protocols for Low Power and Lossy = Networks
= Author(s) = : A. Tavakoli, S. Dawson-Haggerty, P. = Levis
= Filename = : = draft-ietf-roll-protocols-survey-05.txt
= Pages = = : 26
Date : = 2009-1-26
=
Networks of low power = wireless devices introduce novel IP routing
  issues.  Low-power wireless devices, = such as sensors, actuators and
=   smart objects, have difficult constraints: very limited = memory,
  little = processing power, and long sleep periods.  As most of = these
  devices are = battery-powered, energy efficiency is = critically
=   important.  Wireless link qualities can vary = significantly over time,
=   requiring protocols to make agile decisions yet minimize = topology
  change = energy costs.  Routing over such low power and lossy = networks
  has = novel requirements that existing protocols may not address. =  This
=   document provides a brief survey of the strengths and = weaknesses of
=   existing protocols with respect to this class of networks. =  =46rom this
=   survey it examines whether existing and mature IETF = protocols can be
=   used without modification in these networks, or whether = further work
  is = necessary.
  is = necessary.

A URL for this = Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-s= urvey-05.txt

Internet-Drafts = are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-d= rafts/

Below is the = data which will enable a MIME compliant mail = reader
implementation to = automatically retrieve the ASCII version of = the
Internet-Draft.
Content-Type: text/plain
Content-ID: <2009-1-26155804.I-D@ietf.org<= /a>>

_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

_____________________________= __________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll



= --Apple-Mail-118--175166438-- --===============1944694172== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1944694172==-- From roll-bounces@ietf.org Tue Feb 3 09:43:37 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 613603A6C48; Tue, 3 Feb 2009 09:43:37 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1C6F3A6C44 for ; Tue, 3 Feb 2009 09:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.503 X-Spam-Level: X-Spam-Status: No, score=-10.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3oiNlB-veKS for ; Tue, 3 Feb 2009 09:43:35 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A52913A684C for ; Tue, 3 Feb 2009 09:43:34 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,373,1231113600"; d="scan'208";a="32738831" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2009 17:43:14 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n13HhEkq016600; Tue, 3 Feb 2009 18:43:14 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n13HhEuu006655; Tue, 3 Feb 2009 17:43:14 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 18:43:14 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 18:43:13 +0100 Message-Id: <7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <49887E75.1090705@gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Feb 2009 18:43:13 +0100 References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> <49887E75.1090705@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Feb 2009 17:43:13.0842 (UTC) FILETIME=[E360C920:01C98626] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1282; t=1233682994; x=1234546994; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Review=20and=20comments=20Re=3 A=20I-D=20ACTION=3Adraft-ietf-roll-protocols-survey-05.txt |Sender:=20; bh=3D6BfKjn29dq9gJa1qHHeb2gcE1HYsjN1n11r2+uKAA=; b=G4w3MC3L+tWSASwJa2pR8vITsjg99NFZrtLis+mwB2P/qMOQmW75Rw7zSd 9Ni06ZSFlqHadPGKWuKGXBNFBPkzDQh9BYrozif9TR52GmKabDOvVnQ7Tyjo V3DAt45sWg; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Please do ... please do it short and concise ;-) Thanks. JP. On Feb 3, 2009, at 6:27 PM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : > [...] >> On your recommendation to explicitly indicate that NEMO will be >> looked at, we will add it to the protocol survey. Does that satisfy >> your requirement ? > > YEs, I agree. Do you want me to fork a separate thread with the = > NEMO text? > > And let me take advantage of this opening by re-suggesting the = > correction of the protocols-survey ND text. There is an error here: > > protocols-survey draft: >> The fact that all routers must respond to a Router Solicitation = >> requires that the number of routers with a 1-hop neighborhood is >> small, or there will be a reply implosion. > > Such reply implosion is avoided by the IPv6 ND spec, because it = > requires > the RAs responding to an RS be spaced randomly in time: > > RFC4861 "ND for IPv6": >> 6.2.6. Processing Router Solicitations > [...] >> In all cases, Router Advertisements sent in response to a Router >> Solicitation MUST be delayed by a random time between 0 and = >> MAX_RA_DELAY_TIME seconds. > > In this sense, do you want me to make a separate thread regarding = > this ND text? > > Alex > > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Feb 3 09:44:03 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89A2C3A6C48; Tue, 3 Feb 2009 09:44:03 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E59723A6C57 for ; Tue, 3 Feb 2009 09:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVU2zjHj0Vvk for ; Tue, 3 Feb 2009 09:44:01 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id E338D3A6C48 for ; Tue, 3 Feb 2009 09:44:00 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n13HhXmV024620; Tue, 3 Feb 2009 18:43:33 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n13HhWhQ019208; Tue, 3 Feb 2009 18:43:32 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n13HhWA6013275; Tue, 3 Feb 2009 18:43:32 +0100 Message-ID: <49888244.2030008@gmail.com> Date: Tue, 03 Feb 2009 18:43:32 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "David E. Culler" References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498878B9.80403@eecs.berkeley.edu> In-Reply-To: <498878B9.80403@eecs.berkeley.edu> Cc: Ross Callon , roll@ietf.org, Arsalan Tavakoli Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org David E. Culler a =E9crit : [...] > 2. The charter of ROLL = > (http://www.ietf.org/html.charters/roll-charter.html) only mentions the = > word MOBILE in making clear that it must be considered as part of the = > due diligence associated with the routing requirements. If the process = > of turning over all the stones should bring mobility to the surface as a = > primary issue, then it would make sense to consider the overlap = > carefully. They don't. All the requirements are stationary. Mobility = > within them is extremely constrained. More to the point, current ROLL req drafts mentioning mobility are as = follows: Industrial: 5 - Mobility: wireless worker, mobile field devices, speed 35kmph Home: 2 - Support of Mobility: multi-purpose remote, mobile wearable Building: 3 - Mobility: mobile device association in 15s, location tracking These kinds of key words have often been addressed with Mobile IP based = protocols (of which NEMO are extensions), for example in a IPv6-enabled = wearable PAN, or a bus connected to Internet, etc. Given that, I am surprised it's said that all requirements are = stationary and mobility within them is extremely constrained(?) Alex _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Feb 3 11:26:56 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CE6B3A6B2E; Tue, 3 Feb 2009 11:26:56 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5BA83A6946 for ; Tue, 3 Feb 2009 11:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.499 X-Spam-Level: X-Spam-Status: No, score=-4.499 tagged_above=-999 required=5 tests=[AWL=2.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vxAo-OHTw6S for ; Tue, 3 Feb 2009 11:26:53 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 85B773A68B3 for ; Tue, 3 Feb 2009 11:26:24 -0800 (PST) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n13JQ0Q2001924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Feb 2009 11:26:02 -0800 (PST) Message-ID: <49889A43.8040903@eecs.berkeley.edu> Date: Tue, 03 Feb 2009 11:25:55 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Alexandru Petrescu References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498878B9.80403@eecs.berkeley.edu> <49888244.2030008@gmail.com> In-Reply-To: <49888244.2030008@gmail.com> Cc: roll@ietf.org Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Alex - I can't speak for the other applications, but it is misleading to = use the industrial requirements document to support a need for mobility. There are 14 "MUST"s in the industrial requirements document. None of = them is associated with mobility. There are a few "SHOULD"s associated = with mobility. It would be nice to have, but not at the expense of any = of the MUSTs. I don't understand the discussion about the protocol survey document. = It seems like the discussion is distracting us from the main goal: = finding a routing protocol that works. If there is a protocol that satisfies the routing requirement MUSTs in = my document and the other three, then let's implement it on motes and = move on, and we won't care too much about whether RoLL recharters or = not, and we certainly won't care what gets listed in the protocol survey = document. If such a protocol doesn't exist, then please let's recharter and create = one. ksjp Alexandru Petrescu wrote: > David E. Culler a =E9crit : > [...] >> 2. The charter of ROLL = >> (http://www.ietf.org/html.charters/roll-charter.html) only mentions = >> the word MOBILE in making clear that it must be considered as part of = >> the due diligence associated with the routing requirements. If the = >> process of turning over all the stones should bring mobility to the = >> surface as a primary issue, then it would make sense to consider the = >> overlap carefully. They don't. All the requirements are = >> stationary. Mobility within them is extremely constrained. > > More to the point, current ROLL req drafts mentioning mobility are as = > follows: > > Industrial: > 5 - Mobility: wireless worker, mobile field devices, speed 35kmph > > Home: > 2 - Support of Mobility: multi-purpose remote, mobile wearable > > Building: > 3 - Mobility: mobile device association in 15s, location tracking > > These kinds of key words have often been addressed with Mobile IP = > based protocols (of which NEMO are extensions), for example in a = > IPv6-enabled wearable PAN, or a bus connected to Internet, etc. > > Given that, I am surprised it's said that all requirements are = > stationary and mobility within them is extremely constrained(?) > > Alex > > > _______________________________________________ > 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 From roll-bounces@ietf.org Tue Feb 3 11:48:02 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 328F73A6946; Tue, 3 Feb 2009 11:48:02 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A7F73A69D0 for ; Tue, 3 Feb 2009 11:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VS894+s+Yw4b for ; Tue, 3 Feb 2009 11:47:59 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 4054D3A68A2 for ; Tue, 3 Feb 2009 11:47:59 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so837133qwe.31 for ; Tue, 03 Feb 2009 11:47:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=RpdNU55mQ3KoTYTbCULY4Ctog2eVxJQirXo0izY/sDk=; b=hbq+GzyUFZHm10flMTE8YTVl27gWeCzO7YnRbm7nTo2GZtKYP8D5G5ytFnIzGuNvh1 /wuUi7wUR30S0iS7utXw4cv3FGtYH6BEJpyWmUcCmefbb13jwAKVCvxyfjSb57hsvR75 DbUvqUf4oDVsYQlC9Y624Lz+NuQCPsw1pTJ4U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=eTwVhjxZciL+8t9prPDV9jnnJ5HG84KrR6uMMye3bw/q6WKQu0PNZnni3otbyI/Jpr 644LBIqvqSUC3D+UFXZJIWm4wSHVH3Fw6CzITwuN/aNMfYDv9aBCNadPHUJUWUxnIngE sFwRIkFMqpr/l1auJelaFOvAPXWC3CO2m7vJs= MIME-Version: 1.0 Received: by 10.214.25.9 with SMTP id 9mr9000055qay.85.1233690458200; Tue, 03 Feb 2009 11:47:38 -0800 (PST) In-Reply-To: <498883C1.4070703@gmail.com> References: <20090127000001.9F1F03A6819@core3.amsl.com> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> <49887E75.1090705@gmail.com> <44680fe70902030943q416b0908occe4dbc6b1a331e8@mail.gmail.com> <498883C1.4070703@gmail.com> Date: Tue, 3 Feb 2009 11:47:38 -0800 X-Google-Sender-Auth: 65ce49bb782946a5 Message-ID: <44680fe70902031147i3f0a30d8hc1b86c091dfb2792@mail.gmail.com> From: Stephen Dawson-Haggerty To: Alexandru Petrescu , ROLL WG Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0165052502==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0165052502== Content-Type: multipart/alternative; boundary=0015175cdaf4861bd5046208f106 --0015175cdaf4861bd5046208f106 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I accidentally did not copy the list earlier. See below. On Tue, Feb 3, 2009 at 9:49 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Stephen, thanks for the email. > > I would have liked this to go public though... I don't feel like > exchanging privately at this point about ROLL. > > Stephen Dawson-Haggerty a =E9crit : > >> protocols-survey draft: >> >> The fact that all routers must respond to a Router Solicitation requires >> that the number of routers with a 1-hop neighborhood is small, or there = will >> be a reply implosion. >> >> >> Such reply implosion is avoided by the IPv6 ND spec, because it >> requires the RAs responding to an RS be spaced randomly in time: >> >> RFC4861 "ND for IPv6": >> >> 6.2.6. Processing Router Solicitations >> >> [...] >> >> In all cases, Router Advertisements sent in response to a Router >> Solicitation MUST be delayed by a random time between 0 and >> MAX_RA_DELAY_TIME seconds. >> >> >> RFC2461 and 4861 define MAX_RA_DELAY_TIME as 0.5 seconds. I think >> it's very likely to lead to a lot of instantaneous traffic and >> congestion if implemented exactly as specified. >> > > I'm not sure... has one witnessed such implosion when the delay time was > 0.5s? I really don't see why? > > This is the reason for the text; we disagree that this mechanism /as >> defined/ solves the problem; for instance especially on slower 900Mhz >> links, this could completely congest the link as many senders >> contend; this would be unacceptable. >> > > Which link sorry? Which is the link at 900Mhz over which ND would > behave such badly? What's its bandwidth? Is it a ptp or shared link? The ISM band has slots at, for instance 433 and 900Mhz; older Chipcon cc100= 0 radios provided a link at around 75kbps. Now, we generally talk about 802.15.4 (that isn't) but we also don't want to rely on mechanisms that won't work for other links since it's pretty conceivable someone would want to run IP over a slower link (for instance to save power). A 50 byte packe= t at 75kbps is almost 7ms long, so it's not unreasonable to conclude that it won't support densities higher then 25-50 if everyone MUST reply within hal= f a second. In sensor nets reply implosion is pretty common;I'm sure there are other people here will attest to that and you have to be very careful to manage it, for instance using a density-dependent scheme like Trickle. Let's not get sidetracked by ND though; I haven't heard any other concerns about it and I feel like it's known both here and in 6lowpan that new mechanisms are necessary. We'll welcome a look at your NEMO text. Steve > > > Alex > PS: I suggest we go public with this, sorry... > > > --0015175cdaf4861bd5046208f106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I accidentally did not copy the list earlier.  See below.

On Tue, Feb 3, 2009 at 9:49 AM, Alexandru Petrescu <alexand= ru.petrescu@gmail.com> wrote:
Stephen, thanks f= or the email.

I would have liked this to go public though... I don't feel like
exchanging privately at this point about ROLL.

Stephen Dawson-Haggerty a =E9crit :

protocols-survey draft:

The fact that all routers must respond to a Router Solicitation requires th= at the number of routers with a 1-hop neighborhood is small, or there will = be a reply implosion.


Such reply implosion is avoided by the IPv6 ND spec, because it
requires the RAs responding to an RS be spaced randomly in time:

RFC4861 "ND for IPv6":

6.2.6.  Processing Router Solicitations

[...]

In all cases, Router Advertisements sent in response to a Router Solicitati= on MUST be delayed by a random time between 0 and MAX_RA_DELAY_TIME seconds= .


RFC2461 and 4861 define MAX_RA_DELAY_TIME as 0.5 seconds.   I think it's very likely to lead to a lot of instantaneous traffic and
congestion if implemented exactly as specified.

I'm not sure... has one witnessed such implosion when the delay time wa= s
0.5s? I really don't see why? 


This is the reason for the text; we disagree that this mechanism /as
defined/ solves the problem; for instance especially on slower 900Mhz
links, this could completely congest the link as many senders
contend; this would be unacceptable.

Which link sorry?  Which is the link at 900Mhz over which ND would
behave such badly?  What's its bandwidth?  Is it a ptp or sha= red link?

The ISM band has slots at, for instance 433 = and 900Mhz; older Chipcon cc1000 radios provided a link at around 75kbps.&n= bsp; Now, we generally talk about 802.15.4 (that isn't) but we also don= 't want to rely on mechanisms that won't work for other links since= it's pretty conceivable someone would want to run IP over a slower lin= k (for instance to save power).  A 50 byte packet at 75kbps is almost = 7ms long, so it's not unreasonable to conclude that it won't suppor= t densities higher then 25-50 if everyone MUST reply within half a second.&= nbsp;

In sensor nets reply implosion is pretty common;I'm sure there are = other people here will attest to that and you have to be very careful to ma= nage it, for instance using a density-dependent scheme like Trickle.

Let's not get sidetracked by ND though; I haven't heard any oth= er concerns about it and I feel like it's known both here and in 6lowpa= n that new mechanisms are necessary. We'll welcome a look at your NEMO = text.

Steve
 


Alex
PS: I suggest we go public with this, sorry...



--0015175cdaf4861bd5046208f106-- --===============0165052502== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0165052502==-- From roll-bounces@ietf.org Tue Feb 3 12:04:54 2009 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E36053A6A5C; Tue, 3 Feb 2009 12:04:54 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05EBF28C0FC for ; Tue, 3 Feb 2009 12:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.024 X-Spam-Level: X-Spam-Status: No, score=-5.024 tagged_above=-999 required=5 tests=[AWL=1.575, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzbkQ-mjWNN3 for ; Tue, 3 Feb 2009 12:04:53 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id DE58F3A69D1 for ; Tue, 3 Feb 2009 12:04:52 -0800 (PST) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n13K4T6w003920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Feb 2009 12:04:31 -0800 (PST) Message-ID: <4988A348.8030506@eecs.berkeley.edu> Date: Tue, 03 Feb 2009 12:04:24 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Alexandru Petrescu References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <4987899C.3090708@gmail.com> <7C6DC187-681B-48DF-AFF1-FE329EA93CA8@cisco.com> <49885744.3050603@gmail.com> <49885C71.7090009@gmail.com> In-Reply-To: <49885C71.7090009@gmail.com> Cc: roll@ietf.org Subject: Re: [Roll] link-layers for ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org excellent questions, Alex. No doubt there will be many low power and = lossy DLLs for us to route over in the future, but there are several = that are of immediate commercial interest. 802.15.4 is a good place to = start as an example. There are at least a half-dozen different = deeply-duty-cycled DLLs that have been demonstrated for 15.4 radios. = All of them allow for a tradeoff between power consumption and useful = bandwidth, typically over a range of at least three orders of = magnitude. I'd like to make sure that whichever routing protocol we use = (find? create? you tell me) that it can make intelligent use of the = DLL. It's really easy to build a network that runs everything at 1% = duty cycle, but it turns out to give lousy performance in a lot of = commercially relevant scenarios. So in my opinion, our work won't be done until we have a routing = protocol that has some mechanism to 1) be aware of the currently configured capabilities of the DLL , and = the limits of configuration (e.g. I can handle 1 packet/sec right now, = and up to 10 packets/sec if you need me to) 2) be able to configure those capabilities based on the routing decisions I'm not hung up on this being in the routing protocol itself. If you = tell me that the right way to do it is through some other existing = xyz-TE protocol that is independent of the routing protocol, that's = fine. But I'm convinced that the variable power/throughput capabilities = of RoLL DLLs is one of the fundamental differences that makes routing = "interesting" in these networks. ksjp Alexandru Petrescu wrote: > JP, in previous messages you're suggesting my text about link-layers = > are out of context. > > But I consider perfectly legitimate the following questions: which = > link-layers are considered for ROLL WG? How do they present = > themselves to the IP stack? Do they all use the typical Ethernet MAC = > interface? Or point-to-point links? > > Do these link-layer offer hints for defining ROLL energy-oriented = > metrics? > > Alex > > JP Vasseur a =E9crit : >> >> On Feb 3, 2009, at 3:40 PM, Alexandru Petrescu wrote: >> >>> JP Vasseur a =E9crit : >>>> On Feb 3, 2009, at 1:02 AM, Alexandru Petrescu wrote: >>>>> Mischa Dohler a =E9crit : [...] >>>>>> 6LoWPAN: - mainly specifies IPv6 header compression but not = >>>>>> (optimized) routing per se; >>>>> Not only Header Compression, 6lowpan WG seems to also be looking at >>>>> Neighbor Discovery for 802.15.4, which is quite relevant here I = >>>>> believe, because ZigBee was mentioned recently here. >>>> HOLD-ON ... We are NOT working on ZIGBEE here. Let's not go there. = >>>> This is the IETF, we work on IP. >>> >>> I think it is good to mention all link-layers which are addressed by >>> ROLL. The link layer characteristics are of paramount importance on = >>> the >>> subnetting and addressing architecture, and thus on the kind of = >>> protocol >>> needed. >>> >>> (I agree though at IETF we work on IP, independently of the link-layer, >>> and some times dependently on the link-layer: IP-over-foo are typical.) >> >> I do not think that this is the appropriate ML to have such = >> discussion. But no we are not here to list >> all possible link layers (glad we did not do this 20 years ago !). = >> New link layers will be designed in a >> near future (especially true for LLN). And by the way Zigbee is not a = >> PHY/MAC ... >> >>> >>> >>>>>> - [6lowpan] is stuck to IEEE 802.15.4 radios. >>>>> I think it is good to list the radios ROLL looks at: >>>>> IEEE 802.15.4 SP100 http://tinyurl.com/4d3j64 ZigBee HART = >>>>> http://tinyurl.com/4d3j64 >>>> There is quite a bit of confusion. Zigbee is non-IP and build above = >>>> 15.4. We are designing IP-solution and indeed 15.4 is one of the = >>>> PHY/MAC LLN may run onto. >>> >>> I think in the cases a wireless network is made of ZigBee nodes, or >>> 802.15.4 nodes, the entire network is actually a single subnet. And in >>> these cases Neighbor Discovery protocol is very pertinent for ROLL. >> >> Sorry Alex but there is a lot of confusion. Zigbee nodes are NOT = >> running IP. >> Out of context here. >> >>> >>> >>> This would contradict all the inconvenients cited in section 8.1. "IPv6 >>> ND" of protocols-survey draft. HEnce I disagree with this section. I >>> disagree with it for more reasons, one being: >>> >>> protocols-survey draft: >>>> The fact that all routers must respond to a Router Solicitation = >>>> requires that the number of routers with a 1-hop neighborhood is = >>>> small, or there will be a reply implosion. >>> >>> Such reply implosion is avoided by the IPv6 ND spec, because it = >>> requires >>> the RAs responding to an RS are spaced randomly in time: >>> >>> RFC4861 "ND for IPv6": >>>> 6.2.6. Processing Router Solicitations >>> [...] >>>> In all cases, Router Advertisements sent in response to a Router = >>>> Solicitation MUST be delayed by a random time between 0 and = >>>> MAX_RA_DELAY_TIME seconds. >>> >>> Alex >>> >>> >>> _______________________________________________ >>> 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 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Tue Feb 3 12:34:04 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73AD73A6B9F for ; Tue, 3 Feb 2009 12:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CEUhoKeWcRA for ; Tue, 3 Feb 2009 12:34:03 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 4F2163A6B30 for ; Tue, 3 Feb 2009 12:34:01 -0800 (PST) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id 59591940132; Tue, 3 Feb 2009 21:33:38 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 082499400F7; Tue, 3 Feb 2009 21:33:35 +0100 (CET) Message-ID: <4988AA03.802@gmail.com> Date: Tue, 03 Feb 2009 21:33:07 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: JP Vasseur References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> <49887E75.1090705@gmail.com> <7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com> In-Reply-To: <7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090203-0, 03/02/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] suggestion of NEMO text for protocols-survey draft (was: Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 20:34:04 -0000 JP Vasseur a écrit : > Please do ... please do it short and concise ;-) The existing NEMO text is in draft-ietf-roll-protocols-survey-05: > This document does not examine the Network Mobility Basic Support > Protocol (NEMO RFC 3963 [RFC3963]) because it is not a routing > protocol. It does not examine hierarchical NEMO > [I-D.thubert-tree-discovery] as a candidate because it only maintains > a default route and so is insufficient for general routing. Although > NEMO itself is not a suitable routing solution to LLNs, some of its > mechanisms, such as loop-free tree formation, might be useful in an > LLN routing protocol. I suggest replacing the above paragraph with the following longer text, maybe in its own section. In this section we briefly overview the NEMO extensions to Mobile IPv6, its accepted drawbacks, and its features with respect to memory footprint (Table?), protocol reliability (Loss, Control?), energy metrics (Link and Node Cost?) and security. The Network Mobility Basic Support Protocol ("NEMO" RFC 3963, terminology RFC4885) is a set of extensions to the Mobile IPv6 protocol (RFC3775). They extend Mobile IPv6 to accomodate a moving network, i.e. a set of nodes moving together, and connecting to the Internet: laptops in a bus, or a PDA and a camera of a PAN. Arbitrarily "nested" combinations - e.g. a PAN getting into a bus - can equally be accomodated. One noticeable problem is the enforcing of artifically long paths - all traffic between a Correspondent Node and a Local Fixed Node must travel through the Home Agent(s) (RFC4888), despite the existence of shorter straight IP paths. Solutions addressing this problem are in the space of Route Optimization for NEMO (RFC4889), yet none is Standards Track at this point. The Mobile IPv6 protocol has been implemented on a wide range of platforms, of main OS vendors and freely available, from servers to smaller devices. A footprint of a TCP/UDP/ND/IPv6 stack running NEMO and Mobile IPv6 in a Mobile Router is for example 200kb. Although the Mobile IPv6 protocol is basically a two-way exchange, it has lifetimes, timers and retransmission logic such as to accommodate several types of failures of the critical messages; and rate limitation such as to avoid too much noise. The Mobile IPv6 NEMO extensions are used mainly between a Mobile Router and a Home Agent: the MR updates only the HA about its Mobile Network Prefix (MNP); it doesn't update several entities, just one. The Mobile IPv6 protocol and implicitely its NEMO extensions do not currently have any field in the messages, nor any logic in the nodes, relating to energy consumption. One would think that binding lifetimes would need to depend on remaining battery level; and maybe an Error Code from the HA meaning 'not enough battery'; or similar. Other possibilities do exist. An approximation of energy consumption of a particular small device running such an IPv6 stack can be divided as follows: 40% energy to enable the WiFi driver, 1% of energy to send IPv6 packets. The NEMO extensions and the Mobile IPv6 protocol are generally believed to be secure. For through-the-HA communication they make extensive use of IPsec transport and tunnels (RFC4877) whereas for Route Optimization for Mobile Hosts a particular authentication mechanism is used (Return Routability tests). Conclusion: this section surveyed the NEMO (RFC3963) extensions to the Mobile IPv6 protocol, as necessary for a ROLL WG context. It doesn't in any way pretend to be a complete (the protocol has many other features necessary in mobility environments), and errors may have slipped through, this is open to comments. What do you think? Alex From pister@eecs.berkeley.edu Tue Feb 3 12:53:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B56393A6904 for ; Tue, 3 Feb 2009 12:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.339 X-Spam-Level: X-Spam-Status: No, score=-5.339 tagged_above=-999 required=5 tests=[AWL=1.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRGWxYariabB for ; Tue, 3 Feb 2009 12:53:35 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id A52AD3A68A2 for ; Tue, 3 Feb 2009 12:53:35 -0800 (PST) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n13KrAHa005065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Feb 2009 12:53:12 -0800 (PST) Message-ID: <4988AEB1.7050104@eecs.berkeley.edu> Date: Tue, 03 Feb 2009 12:53:05 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Alexandru Petrescu References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> <49887E75.1090705@gmail.com> <7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com> <4988AA03.802@gmail.com> In-Reply-To: <4988AA03.802@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] suggestion of NEMO text for protocols-survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 20:53:36 -0000 Is the footprint really 200kb, which is painful but might be ok, or 200kB? The latter is not going to work for any of the platforms currently addressing the four RoLL applications. I don't understand the 40% WiFi driver and 1% for traffic. What does that mean, exactly? For most of the applications that we're talking about here, you get 10 to 100 microAmps average current. This doesn't have anything to do with radios, DLLs, or routing protocols, it has to do with the acceptable battery size/cost and required lifetime. Anything with "40%" and "WiFi" in the same part of a sentence makes me nervous. ksjp Alexandru Petrescu wrote: > JP Vasseur a écrit : >> Please do ... please do it short and concise ;-) > > The existing NEMO text is in draft-ietf-roll-protocols-survey-05: > >> This document does not examine the Network Mobility Basic Support >> Protocol (NEMO RFC 3963 [RFC3963]) because it is not a routing >> protocol. It does not examine hierarchical NEMO >> [I-D.thubert-tree-discovery] as a candidate because it only maintains >> a default route and so is insufficient for general routing. Although >> NEMO itself is not a suitable routing solution to LLNs, some of its >> mechanisms, such as loop-free tree formation, might be useful in an >> LLN routing protocol. > > I suggest replacing the above paragraph with the following longer > text, maybe in its own section. > > In this section we briefly overview the NEMO extensions to Mobile > IPv6, its accepted drawbacks, and its features with respect to > memory footprint (Table?), protocol reliability (Loss, Control?), > energy metrics (Link and Node Cost?) and security. > > The Network Mobility Basic Support Protocol ("NEMO" RFC 3963, > terminology RFC4885) is a set of extensions to the Mobile IPv6 > protocol (RFC3775). They extend Mobile IPv6 to accomodate a moving > network, i.e. a set of nodes moving together, and connecting to the > Internet: laptops in a bus, or a PDA and a camera of a PAN. > Arbitrarily "nested" combinations - e.g. a PAN getting into a bus - > can equally be accomodated. One noticeable problem is the > enforcing of artifically long paths - all traffic between a > Correspondent Node and a Local Fixed Node must travel through the > Home Agent(s) (RFC4888), despite the existence of shorter straight > IP paths. Solutions addressing this problem are in the space of > Route Optimization for NEMO (RFC4889), yet none is Standards Track > at this point. > > The Mobile IPv6 protocol has been implemented on a wide range of > platforms, of main OS vendors and freely available, from servers to > smaller devices. A footprint of a TCP/UDP/ND/IPv6 stack running > NEMO and Mobile IPv6 in a Mobile Router is for example 200kb. > > Although the Mobile IPv6 protocol is basically a two-way exchange, > it > has lifetimes, timers and retransmission logic such as to > accommodate > several types of failures of the critical messages; and rate > limitation such as to avoid too much noise. > > The Mobile IPv6 NEMO extensions are used mainly between a Mobile > Router and a Home Agent: the MR updates only the HA about its > Mobile > Network Prefix (MNP); it doesn't update several entities, just one. > > The Mobile IPv6 protocol and implicitely its NEMO extensions do not > currently have any field in the messages, nor any logic in the > nodes, > relating to energy consumption. One would think that binding > lifetimes would need to depend on remaining battery level; and > maybe > an Error Code from the HA meaning 'not enough battery'; or similar. > Other possibilities do exist. > > An approximation of energy consumption of a particular small device > running such an IPv6 stack can be divided as follows: 40% energy to > enable the WiFi driver, 1% of energy to send IPv6 packets. > > The NEMO extensions and the Mobile IPv6 protocol are generally > believed to be secure. For through-the-HA communication they make > extensive use of IPsec transport and tunnels (RFC4877) whereas for > Route Optimization for Mobile Hosts a particular authentication > mechanism is used (Return Routability tests). > > Conclusion: this section surveyed the NEMO (RFC3963) extensions to > the Mobile IPv6 protocol, as necessary for a ROLL WG context. It > doesn't in any way pretend to be a complete (the protocol has many > other features necessary in mobility environments), and errors may > have slipped through, this is open to comments. > > What do you think? > > Alex > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Tue Feb 3 12:55:06 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BACF3A6830 for ; Tue, 3 Feb 2009 12:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ay3B+mQ461HC for ; Tue, 3 Feb 2009 12:55:05 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 5636D28C0DC for ; Tue, 3 Feb 2009 12:55:03 -0800 (PST) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id E97109400AA; Tue, 3 Feb 2009 21:54:40 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id A14D6940140; Tue, 3 Feb 2009 21:54:37 +0100 (CET) Message-ID: <4988AEF0.20803@gmail.com> Date: Tue, 03 Feb 2009 21:54:08 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Stephen Dawson-Haggerty References: <20090127000001.9F1F03A6819@core3.amsl.com> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> <49887E75.1090705@gmail.com> <44680fe70902030943q416b0908occe4dbc6b1a331e8@mail.gmail.com> <498883C1.4070703@gmail.com> <44680fe70902031147i3f0a30d8hc1b86c091dfb2792@mail.gmail.com> In-Reply-To: <44680fe70902031147i3f0a30d8hc1b86c091dfb2792@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090203-0, 03/02/2009), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 20:55:06 -0000 Stephen Dawson-Haggerty a écrit : [discussion about RA implosion when RS sent to thousand neighbours, protocols-survey draft] >> Which link sorry? Which is the link at 900Mhz over which ND would >> behave such badly? What's its bandwidth? Is it a ptp or shared >> link? > > The ISM band has slots at, for instance 433 and 900Mhz; older Chipcon > cc1000 radios provided a link at around 75kbps. Now, we generally > talk about 802.15.4 (that isn't) but we also don't want to rely on > mechanisms that won't work for other links since it's pretty > conceivable someone would want to run IP over a slower link (for > instance to save power). A 50 byte packet at 75kbps is almost 7ms > long, so it's not unreasonable to conclude that it won't support > densities higher then 25-50 if everyone MUST reply within half a > second. Stephen, I fully agree the links you mention at 75kbps are pertinent and should be accommodated in ROLL environments. Indeed, 7ms latency is quite high and 1000 such messages wouldn't fit in 500ms, even if randomly spaced: some times there would be 2 or 3 simultaneous messages, maybe not very stormy. PtP? I wanted to ask, arent't these links with high latencies of type point-to-point? I think it's very probably that a link with 75kbps bandwidth be point-to-point. In this case the nodes are neighbors 1-by-1, and thus no implosion (or message 'storm') danger. > In sensor nets reply implosion is pretty common; I'm sure there are > other people here will attest to that and you have to be very careful > to manage it, for instance using a density-dependent scheme like > Trickle. > > Let's not get sidetracked by ND though; I'm using ND and link types as an opportunity to try to describe the addressing architecture and the subnet structure. These are typical for MANET discussion and often helpful to identify what can be done at IP level and what below. Alex From sdhags@gmail.com Tue Feb 3 12:56:15 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94B713A6904 for ; Tue, 3 Feb 2009 12:56:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V37HFvSMzHmt for ; Tue, 3 Feb 2009 12:56:14 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 7E40D3A6830 for ; Tue, 3 Feb 2009 12:56:13 -0800 (PST) Received: by qyk4 with SMTP id 4so2904460qyk.13 for ; Tue, 03 Feb 2009 12:55:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=M0UDYVGjwEnabtchFoZCFyHgva8WdF4PNEjFPUXtPgc=; b=J1+fLp25Xk6sqFbuINT+sHuoBBw1dZfzErtM1+etTfySEx0MfnBYGUOx26lAt7p0fB o1ZC/QI3SXsrzbkvu4sSFCDMfoaenBnZcMzxFO5/wzgLR1vM5BJC6mHd+qEyJkMBQ919 +U5BCdxsaQ7zEGCnetGV5bFrslML6Ax06hOS4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=TT8Jb3IsRBkXosiX6n5WPo09WM7a7TfdlYf0io2Hr7oXGmzmaT9RlQeofZ5sUYbiEZ DD0FTBMXuqNN+cAFpmlq+ICEieF7avVBGcQyyavP7Sc1sLXCvQ+8THk4CwaKPNlEuIL8 6jyCC7RcYNY4bYWz9tcKY3TfgXD10RW9IIdN8= MIME-Version: 1.0 Sender: sdhags@gmail.com Received: by 10.215.14.21 with SMTP id r21mr9080350qai.277.1233694554012; Tue, 03 Feb 2009 12:55:54 -0800 (PST) In-Reply-To: <4988AA03.802@gmail.com> References: <20090127000001.9F1F03A6819@core3.amsl.com> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> <49887E75.1090705@gmail.com> <7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com> <4988AA03.802@gmail.com> Date: Tue, 3 Feb 2009 12:55:53 -0800 X-Google-Sender-Auth: 857cbba4ab7ec842 Message-ID: <44680fe70902031255y78cd6f0aqa6de46c1e2a6f125@mail.gmail.com> From: Stephen Dawson-Haggerty To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=0015175cb096a73d70046209e589 Cc: roll@ietf.org Subject: Re: [Roll] suggestion of NEMO text for protocols-survey draft (was: Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 20:56:15 -0000 --0015175cb096a73d70046209e589 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for the suggestions. I think we may be able to work with some of this. However, some of the language is unnecessarily imprecise ("maybe an Error Code from the HA meaning 'not enough battery'; or similar.", "avoid too much noise. "). Including power numbers is inappropriate because as we state in section 3.3 we do not consider any particular implementation. Discussing security is important and has been discussed on the list, however, section 10 indicates that it is out of scope; it is yet another reason this document is "necessary but not sufficient" (3.2). I believe the goal for an updated paragraph should be to (a) briefly define what NEMO is/does (we don't really do this now) and (b) why certain mechanims are desirable to consider it when actually designing a routing protocol (we have only a sentence on this now), and finally (c) justify wh= y it is not included in Table 1 (we do this). So, expanding on the (a) and (b) seems worthwhile, but not in more then a couple of sentences each. JP asked (and we authors feel), short and concise :) The below accomplishe= s (a) and (c). We might want to identify more specific ways NEMO mechanisms could be used in a ROLL solution to deal with (b). Thoughts? Thanks for your suggestions. Steve The Network Mobility Basic Support Protocol ("NEMO" RFC 3963, terminology RFC4885) is a set of extensions to the Mobile IPv6 protocol (RFC3775). They extend Mobile IPv6 to accomodate a moving network, i.e. a set of nodes moving together, and connecting to the Internet: laptops in a bus, or a PDA and a camera of a PAN. Arbitrarily "nested" combinations - e.g. a PAN getting into a bus - can equally be accomodated. This document does not examine (NEMO RFC 396= 3 [RFC3963]) because it is not a routing protocol. It does not examine hierarchical NEMO [I-D.thubert-tree-discovery] as a candidate because it only maintains a default route and so is insufficient for general routing. Although NEMO itself is not a suitable routing solution to LLNs, some of its mechanisms, such as loop-free tree formation, might be useful in an LLN routing protocol. On Tue, Feb 3, 2009 at 12:33 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > JP Vasseur a =E9crit : > >> Please do ... please do it short and concise ;-) >> > > The existing NEMO text is in draft-ietf-roll-protocols-survey-05: > > This document does not examine the Network Mobility Basic Support Protoc= ol >> (NEMO RFC 3963 [RFC3963]) because it is not a routing protocol. It does= not >> examine hierarchical NEMO [I-D.thubert-tree-discovery] as a candidate >> because it only maintains >> a default route and so is insufficient for general routing. Although >> NEMO itself is not a suitable routing solution to LLNs, some of its >> mechanisms, such as loop-free tree formation, might be useful in an >> LLN routing protocol. >> > > I suggest replacing the above paragraph with the following longer > text, maybe in its own section. > > In this section we briefly overview the NEMO extensions to Mobile > IPv6, its accepted drawbacks, and its features with respect to > memory footprint (Table?), protocol reliability (Loss, Control?), > energy metrics (Link and Node Cost?) and security. > > The Network Mobility Basic Support Protocol ("NEMO" RFC 3963, > terminology RFC4885) is a set of extensions to the Mobile IPv6 > protocol (RFC3775). They extend Mobile IPv6 to accomodate a moving > network, i.e. a set of nodes moving together, and connecting to the > Internet: laptops in a bus, or a PDA and a camera of a PAN. > Arbitrarily "nested" combinations - e.g. a PAN getting into a bus - > can equally be accomodated. One noticeable problem is the > enforcing of artifically long paths - all traffic between a > Correspondent Node and a Local Fixed Node must travel through the > Home Agent(s) (RFC4888), despite the existence of shorter straight > IP paths. Solutions addressing this problem are in the space of > Route Optimization for NEMO (RFC4889), yet none is Standards Track > at this point. > > The Mobile IPv6 protocol has been implemented on a wide range of > platforms, of main OS vendors and freely available, from servers to > smaller devices. A footprint of a TCP/UDP/ND/IPv6 stack running > NEMO and Mobile IPv6 in a Mobile Router is for example 200kb. > > Although the Mobile IPv6 protocol is basically a two-way exchange, it > > has lifetimes, timers and retransmission logic such as to accommodate > > several types of failures of the critical messages; and rate > limitation such as to avoid too much noise. > > The Mobile IPv6 NEMO extensions are used mainly between a Mobile > Router and a Home Agent: the MR updates only the HA about its Mobile > Network Prefix (MNP); it doesn't update several entities, just one. > > The Mobile IPv6 protocol and implicitely its NEMO extensions do not > currently have any field in the messages, nor any logic in the nodes, > > relating to energy consumption. One would think that binding > > lifetimes would need to depend on remaining battery level; and maybe > an Error Code from the HA meaning 'not enough battery'; or similar. > Other possibilities do exist. > > An approximation of energy consumption of a particular small device > running such an IPv6 stack can be divided as follows: 40% energy to > enable the WiFi driver, 1% of energy to send IPv6 packets. > > The NEMO extensions and the Mobile IPv6 protocol are generally > believed to be secure. For through-the-HA communication they make > extensive use of IPsec transport and tunnels (RFC4877) whereas for > Route Optimization for Mobile Hosts a particular authentication > mechanism is used (Return Routability tests). > > Conclusion: this section surveyed the NEMO (RFC3963) extensions to > the Mobile IPv6 protocol, as necessary for a ROLL WG context. It > doesn't in any way pretend to be a complete (the protocol has many > other features necessary in mobility environments), and errors may > have slipped through, this is open to comments. > > What do you think? > > Alex > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --0015175cb096a73d70046209e589 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for the suggestions.  I think we may be able to work with some = of this.  However, some of the language is unnecessarily imprecise (&q= uot;maybe an Error Code from the HA meaning 'not enough battery'; o= r similar.", "avoid too much noise. ").  Including powe= r numbers is inappropriate because as we state in section 3.3 we do not con= sider any particular implementation.  Discussing security is important= and has been discussed on the list, however, section 10 indicates that it = is out of scope; it is yet another reason this document is "necessary = but not sufficient" (3.2).

I believe the goal for an updated paragraph should be to (a) briefly de= fine what NEMO is/does (we don't really do this now) and (b) why certai= n mechanims are desirable to consider it when actually designing a routing = protocol (we have only a sentence on this now),  and finally (c) justi= fy why it is not included in Table 1 (we do this).  So, expanding on t= he (a) and (b) seems worthwhile, but not in more then a couple of sentences= each.

JP asked (and we authors feel), short and concise :)  The below ac= complishes (a) and (c).  We might want to identify more specific ways = NEMO mechanisms could be used in a ROLL solution to deal with (b).  Th= oughts?

Thanks for your suggestions.
Steve

  The Network Mobilit= y Basic Support Protocol ("NEMO" RFC 3963,
  terminology RFC4885) is a set of extensions to the Mobile IPv6
  protocol (RFC3775).  They extend Mobile IPv6 to accomodate a m= oving
  network, i.e. a set of nodes moving together, and connecting to the=
  Internet: laptops in a bus, or a PDA and a camera of a PAN.
  Arbitrarily "nested" combinations - e.g. a PAN getting in= to a bus -
  can equally be accomodated.  This document does n= ot examine (NEMO RFC 3963 [RFC3963]) because it is not a routing protocol.  It does not examine hierarchical NEMO [I-D.thubert-tree-discovery] as a candidate because it only maintains
a default route and so is insufficient for general routing.  Although<= br> NEMO itself is not a suitable routing solution to LLNs, some of its
mechanisms, such as loop-free tree formation, might be useful in an
LLN routing protocol.




On Tue,= Feb 3, 2009 at 12:33 PM, Alexandru Petrescu <alexandru.petrescu@gmail.com&g= t; wrote:
JP Vasseur a =E9c= rit :
Please do ... please do it short and concise ;-)

The existing NEMO text is in draft-ietf-roll-protocols-survey-05:

This document does not examine the Network Mobility Basic Support Protocol = (NEMO RFC 3963 [RFC3963]) because it is not a routing protocol.  It do= es not examine hierarchical NEMO [I-D.thubert-tree-discovery] as a candidat= e because it only maintains
a default route and so is insufficient for general routing.  Although<= br> NEMO itself is not a suitable routing solution to LLNs, some of its
mechanisms, such as loop-free tree formation, might be useful in an
LLN routing protocol.

I suggest replacing the above paragraph with the following longer
text, maybe in its own section.

  In this section we briefly overview the NEMO extensions to Mobile   IPv6, its accepted drawbacks, and its features with respect to
  memory footprint (Table?), protocol reliability (Loss, Control?),   energy metrics (Link and Node Cost?) and security.

  The Network Mobility Basic Support Protocol ("NEMO" RFC 3= 963,
  terminology RFC4885) is a set of extensions to the Mobile IPv6
  protocol (RFC3775).  They extend Mobile IPv6 to accomodate a m= oving
  network, i.e. a set of nodes moving together, and connecting to the=
  Internet: laptops in a bus, or a PDA and a camera of a PAN.
  Arbitrarily "nested" combinations - e.g. a PAN getting in= to a bus -
  can equally be accomodated.  One noticeable problem is the
  enforcing of artifically long paths - all traffic between a
  Correspondent Node and a Local Fixed Node must travel through the   Home Agent(s) (RFC4888), despite the existence of shorter straight<= br>   IP paths.  Solutions addressing this problem are in the space = of
  Route Optimization for NEMO (RFC4889), yet none is Standards Track<= br>   at this point.

  The Mobile IPv6 protocol has been implemented on a wide range of   platforms, of main OS vendors and freely available, from servers to=
  smaller devices.  A footprint of a TCP/UDP/ND/IPv6 stack runni= ng
  NEMO and Mobile IPv6 in a Mobile Router is for example 200kb.

  Although the Mobile IPv6 protocol is basically a two-way exchange, = it        
  has lifetimes, timers and retransmission logic such as to accommoda= te        
  several types of failures of the critical messages; and rate  =      
  limitation such as to avoid too much noise.       &n= bsp;                  
                    &nbs= p;                     &n= bsp;                     =        
  The Mobile IPv6 NEMO extensions are used mainly between a Mobile &n= bsp;  
  Router and a Home Agent: the MR updates only the HA about its Mobil= e
  Network Prefix (MNP); it doesn't update several entities, just = one.  
                    &nbs= p;                     &n= bsp;                     =        
  The Mobile IPv6 protocol and implicitely its NEMO extensions do not=  
  currently have any field in the messages, nor any logic in the node= s,        
  relating to energy consumption.  One would think that binding =                
  lifetimes would need to depend on remaining battery level; and mayb= e
  an Error Code from the HA meaning 'not enough battery'; or = similar.  
  Other possibilities do exist.

  An approximation of energy consumption of a particular small device=
  running such an IPv6 stack can be divided as follows: 40% energy to=
  enable the WiFi driver, 1% of energy to send IPv6 packets.

  The NEMO extensions and the Mobile IPv6 protocol are generally
  believed to be secure.  For through-the-HA communication they = make
  extensive use of IPsec transport and tunnels (RFC4877) whereas for<= br>   Route Optimization for Mobile Hosts a particular authentication
  mechanism is used (Return Routability tests).

  Conclusion: this section surveyed the NEMO (RFC3963) extensions to<= br>   the Mobile IPv6 protocol, as necessary for a ROLL WG context.  = ;It
  doesn't in any way pretend to be a complete (the protocol has m= any
  other features necessary in mobility environments), and errors may<= br>   have slipped through, this is open to comments.

What do you think?

Alex

_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

--0015175cb096a73d70046209e589-- From sdhags@gmail.com Tue Feb 3 12:58:41 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3641B3A6B30 for ; Tue, 3 Feb 2009 12:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SylzM5xqkELZ for ; Tue, 3 Feb 2009 12:58:40 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 06DCF3A69ED for ; Tue, 3 Feb 2009 12:58:39 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so852197qwe.31 for ; Tue, 03 Feb 2009 12:58:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=+ER6yotzirCBAtOSNgq0vJdENtGQBoQnyM+FMQPGcsE=; b=Tf4Fh408Qlgjb1iUgVRQLcJ3WULftCpvUMaKvN3QVFHaY6DvV7k8HWm2SsT4Q9/XQb C32PoBy7dZ3sr/uBqoD984FXZ+oIll7VqRewDL/griQlG8cxOTB+E9VooVtlvxOEo+96 L/LXGtlZEet1mRUB6AmdcgZLol0aXYBrjdCX0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=A8BQA5qDm9XZrcd0cqeKO4WVa0FvY8bT4Ir8jvC3z2sOYHyy0lczmGHLD8wgu4zcq4 7AMiGiOj8I0LgGGXhBS3yhOYca2dOGlf3f7zWxQvbwhNTyANUY4oZOV0un9s0MMR1jGc SP5edx1u8LdxiyVdXiaFNjdpqN/xbgbD6mFRU= MIME-Version: 1.0 Sender: sdhags@gmail.com Received: by 10.214.215.18 with SMTP id n18mr9085310qag.278.1233694699456; Tue, 03 Feb 2009 12:58:19 -0800 (PST) In-Reply-To: <4988AEF0.20803@gmail.com> References: <20090127000001.9F1F03A6819@core3.amsl.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> <49887E75.1090705@gmail.com> <44680fe70902030943q416b0908occe4dbc6b1a331e8@mail.gmail.com> <498883C1.4070703@gmail.com> <44680fe70902031147i3f0a30d8hc1b86c091dfb2792@mail.gmail.com> <4988AEF0.20803@gmail.com> Date: Tue, 3 Feb 2009 12:58:19 -0800 X-Google-Sender-Auth: bbaa62d9f5bbaad9 Message-ID: <44680fe70902031258o54190cfdl6e5ce794e9b61e12@mail.gmail.com> From: Stephen Dawson-Haggerty To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=0015175cde3252899a046209ee94 Cc: ROLL WG Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 20:58:41 -0000 --0015175cde3252899a046209ee94 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Kris also brought up another good point which is that if the links are aggressively duty cycled (we consider that likely) matters are likely to be even worse. Also, most discussion in this group has not considered point t= o point links; I don't believe they are prevalent in this design space. Thanks, Steve On Tue, Feb 3, 2009 at 12:54 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Stephen Dawson-Haggerty a =E9crit : > [discussion about RA implosion when RS sent to thousand neighbours, > protocols-survey draft] > > Which link sorry? Which is the link at 900Mhz over which ND would >>> behave such badly? What's its bandwidth? Is it a ptp or shared link? >>> >> >> The ISM band has slots at, for instance 433 and 900Mhz; older Chipcon >> cc1000 radios provided a link at around 75kbps. Now, we generally talk >> about 802.15.4 (that isn't) but we also don't want to rely on mechanisms >> that won't work for other links since it's pretty conceivable someone wo= uld >> want to run IP over a slower link (for instance to save power). A 50 by= te >> packet at 75kbps is almost 7ms long, so it's not unreasonable to conclud= e >> that it won't support densities higher then 25-50 if everyone MUST reply >> within half a second. >> > > Stephen, I fully agree the links you mention at 75kbps are pertinent and > should be accommodated in ROLL environments. > > Indeed, 7ms latency is quite high and 1000 such messages wouldn't fit in > 500ms, even if randomly spaced: some times there would be 2 or 3 > simultaneous messages, maybe not very stormy. > > PtP? I wanted to ask, arent't these links with high latencies of type > point-to-point? I think it's very probably that a link with 75kbps > bandwidth be point-to-point. In this case the nodes are neighbors > 1-by-1, and thus no implosion (or message 'storm') danger. > > In sensor nets reply implosion is pretty common; I'm sure there are othe= r >> people here will attest to that and you have to be very careful >> to manage it, for instance using a density-dependent scheme like Trickl= e. >> >> Let's not get sidetracked by ND though; >> > > I'm using ND and link types as an opportunity to try to describe the > addressing architecture and the subnet structure. These are typical for > MANET discussion and often helpful to identify what can be done at IP lev= el > and what below. > > Alex > > --0015175cde3252899a046209ee94 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Kris also brought up another good point which is that if the links are aggr= essively duty cycled (we consider that likely) matters are likely to be eve= n worse.  Also, most discussion in this group has not considered point= to point links; I don't believe they are prevalent in this design spac= e.

Thanks,
Steve

On Tue, Feb 3, 2009 = at 12:54 PM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrot= e:
Stephen Dawson-Haggerty a =E9crit :
[discussion about RA implosion when RS sent to thousand neighbours,
 protocols-survey draft]


Which link sorry?  Which is the link at 900Mhz over which ND would
 behave such badly?  What's its bandwidth?  Is it a ptp = or shared link?

The ISM band has slots at, for instance 433 and 900Mhz; older Chipcon
 cc1000 radios provided a link at around 75kbps.  Now, we general= ly talk about 802.15.4 (that isn't) but we also don't want to rely = on mechanisms that won't work for other links since it's pretty con= ceivable someone would want to run IP over a slower link (for instance to s= ave power).  A 50 byte packet at 75kbps is almost 7ms long, so it'= s not unreasonable to conclude that it won't support densities higher t= hen 25-50 if everyone MUST reply within half a second.

Stephen, I fully agree the links you mention at 75kbps are pertinent and should be accommodated in ROLL environments.

Indeed, 7ms latency is quite high and 1000 such messages wouldn't fit i= n
500ms, even if randomly spaced: some times there would be 2 or 3
simultaneous messages, maybe not very stormy.

PtP? I wanted to ask, arent't these links with high latencies of type point-to-point?  I think it's very probably that a link with 75kbp= s
bandwidth be point-to-point.  In this case the nodes are neighbors
1-by-1, and thus no implosion (or message 'storm') danger.


In sensor nets reply implosion is pretty common; I'm sure there are oth= er people here will attest to that and you have to be very careful
 to manage it, for instance using a density-dependent scheme like Tric= kle.

Let's not get sidetracked by ND though;

I'm using ND and link types as an opportunity to try to describe the ad= dressing architecture and the subnet structure.  These are typical for= MANET discussion and often helpful to identify what can be done at IP leve= l and what below.

Alex


--0015175cde3252899a046209ee94-- From zach@sensinode.com Tue Feb 3 13:01:32 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F25BB3A6AEA for ; Tue, 3 Feb 2009 13:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+86nUTODGSx for ; Tue, 3 Feb 2009 13:01:32 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 03BA93A69D0 for ; Tue, 3 Feb 2009 13:01:29 -0800 (PST) Received: from snl-zach.local (line-17193.dyn.kponet.fi [85.29.113.153]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n13L13R9008779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 3 Feb 2009 23:01:04 +0200 Message-ID: <4988B0A4.5070407@sensinode.com> Date: Tue, 03 Feb 2009 23:01:24 +0200 From: Zach Shelby User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: ROLL WG References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498874A8.9030206@ekasystems.com> In-Reply-To: <498874A8.9030206@ekasystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review and comments draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 21:01:33 -0000 I fully agree. The WG documents and approach have my support and it is definitely time to start rechartering. - Zach M. B. Anand wrote: > JP Vasseur wrote: >> >> *-> Yes we need to rush out. Why ? Because proprietary or semi-closed >> non-IP solutions are being deployed at a fairly large scale. I do not >> think that I have to convince anybody on this list that this is the >> WRONG approach for a number of reasons. The industry is asking for an >> IP solution *now*.* > Indeed. And the bold letters are quite warranted. As we speak, actual > legislation is moving through Congress in the US that specifies > "Internet-enabled technologies" as a condition for grants in smart grid > applications. Who knows what such technologies are ? There is no routing > standard, there is no standard on any number of other things although > there are bits and pieces of standards here and there. Billions of > dollars are about to be handed out in the very near future and in the > absence of any standards, practically everything is going to get claimed > to be IP. The window is closing very, very fast. > > While all this is surely not an excuse to produce shoddy work, it is > certainly a tremendous driver to move. The sole reason for those of us > engaged in the application space to be involved and contribute actively > here is that there is a group of experts who having been doing > networking for decades and there is an unrivaled body of knowledge at > IETF on how to do networking correctly. That includes all the working > groups. It needs to be done here and it needs to be done soon. >> >>> This would make a large chunk of my concerns and issues vanish, and >>> allow correctly interpreting and evaluating the rest of the document. >> >> That said, question for the WG. Who think that such criteria should be >> added to move forward ? Please reply. > As has been said here many times, the purpose of this document is to > evaluate the suitability of existing IETF protocols for their > suitability for intersection of ROLL requirements. The document itself > is very clear and states: "this document simply seeks to answer the > question: do LLNs require a new protocol specification document at > all?" So, no, it is not superfluous, because this question needed to be > answered. It is expressly not the purpose of this document to decide > what is a useful approach or a starting point for any new protocol. It > seems to get interpreted that way in many of these discussions and that > is not its purpose. > > In a recent email, Emmanuel states: > "Basically, everybody agrees that something special must be done for > sensor ad hoc connectivity with IP, and everybody wants to reach the > next phase ASAP (i.e. work on solutions). " > > If everybody agrees on this, then this document should close without > needing any further discussion. The whole purpose of the document is to > document what everyone seems to agree on. Then, what is the disagreement ? > > I suggest we restrict the discussion to the following: > 1. Are there any disagreements on the analysis ? - Seems not at the > present time, or any such issues have already been addressed. > 2. Should any criteria be removed and if so why ? - Again, I haven't > seen anyone state this. > 3. Let's not add any criteria - because that is not going to magically > make the conclusion - i.e., the fact no existing protocol, unchanged, > suits the requirements (which, BTW, everyone agrees on) change. > > All the other discussions on ROLL, MANET, 6LoW etc. are perhaps valuable > and there is a time and place for those, but it has little to do with > this draft. > > Best regards, > Anand. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti FINLAND mobile: +358 40 7796297 This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. From alexandru.petrescu@gmail.com Tue Feb 3 13:05:15 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D7413A6BF0 for ; Tue, 3 Feb 2009 13:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.071 X-Spam-Level: X-Spam-Status: No, score=-2.071 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tt5ake5mCB8k for ; Tue, 3 Feb 2009 13:05:14 -0800 (PST) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by core3.amsl.com (Postfix) with ESMTP id 641EE3A69D0 for ; Tue, 3 Feb 2009 13:05:12 -0800 (PST) Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id 249024B002A; Tue, 3 Feb 2009 22:04:49 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp2-g21.free.fr (Postfix) with ESMTP id 0E71B4B0184; Tue, 3 Feb 2009 22:04:46 +0100 (CET) Message-ID: <4988B152.3030409@gmail.com> Date: Tue, 03 Feb 2009 22:04:18 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Kris Pister References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <4987899C.3090708@gmail.com> <7C6DC187-681B-48DF-AFF1-FE329EA93CA8@cisco.com> <49885744.3050603@gmail.com> <49885C71.7090009@gmail.com> <4988A348.8030506@eecs.berkeley.edu> In-Reply-To: <4988A348.8030506@eecs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090203-0, 03/02/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] link-layers for ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 21:05:15 -0000 Kris Pister a écrit : > excellent questions, Alex. No doubt there will be many low power and > lossy DLLs for us to route over in the future, but there are several > that are of immediate commercial interest. 802.15.4 is a good place to > start as an example. There are at least a half-dozen different > deeply-duty-cycled DLLs that have been demonstrated for 15.4 radios. > All of them allow for a tradeoff between power consumption and useful > bandwidth, typically over a range of at least three orders of > magnitude. I'd like to make sure that whichever routing protocol we use > (find? create? you tell me) that it can make intelligent use of the > DLL. It's really easy to build a network that runs everything at 1% > duty cycle, but it turns out to give lousy performance in a lot of > commercially relevant scenarios. > > So in my opinion, our work won't be done until we have a routing > protocol that has some mechanism to > 1) be aware of the currently configured capabilities of the DLL , and > the limits of configuration (e.g. I can handle 1 packet/sec right now, > and up to 10 packets/sec if you need me to) > 2) be able to configure those capabilities based on the routing decisions > > I'm not hung up on this being in the routing protocol itself. If you > tell me that the right way to do it is through some other existing > xyz-TE protocol that is independent of the routing protocol, that's > fine. But I'm convinced that the variable power/throughput capabilities > of RoLL DLLs is one of the fundamental differences that makes routing > "interesting" in these networks. Trying to identify to what extent the interesting part is already addressed at link-layer... A link with its own routing (isa100.11a) talks to another link with its own other link routing (zigbee) through an IP router. This wouldn't run any routing protocol, because the link-layer routing is enough. I'm not sure I understand how variable power/throughput capabilities of RoLL DLLs make IP routing interesting for these networks. Alex From alexandru.petrescu@gmail.com Tue Feb 3 13:09:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3546B3A6AEA for ; Tue, 3 Feb 2009 13:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TH1kZa82uC08 for ; Tue, 3 Feb 2009 13:09:46 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 2CF8D3A69D0 for ; Tue, 3 Feb 2009 13:09:44 -0800 (PST) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id 099F1940072; Tue, 3 Feb 2009 22:09:21 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 907529401D2; Tue, 3 Feb 2009 22:09:18 +0100 (CET) Message-ID: <4988B262.2090904@gmail.com> Date: Tue, 03 Feb 2009 22:08:50 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Kris Pister References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498878B9.80403@eecs.berkeley.edu> <49888244.2030008@gmail.com> <49889A43.8040903@eecs.berkeley.edu> In-Reply-To: <49889A43.8040903@eecs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090203-0, 03/02/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 21:09:47 -0000 Kris Pister a écrit : > Alex - I can't speak for the other applications, but it is misleading > to use the industrial requirements document to support a need for > mobility. There are 14 "MUST"s in the industrial requirements > document. None of them is associated with mobility. There are a few > "SHOULD"s associated with mobility. It would be nice to have, but > not at the expense of any of the MUSTs. > > I don't understand the discussion about the protocol survey document. > It seems like the discussion is distracting us from the main goal: > finding a routing protocol that works. If there is a protocol that > satisfies the routing requirement MUSTs in my document and the other > three, then let's implement it on motes and move on, and we won't > care too much about whether RoLL recharters or not, and we certainly > won't care what gets listed in the protocol survey document. If such > a protocol doesn't exist, then please let's recharter and create one. I also highly appreciate implementations. The question about rechartering: implementations for a charter need to know what to implement, lazily. I think we (at least not me) don't know what to implement at this point about ROLL. On one hand it's very specific (routing, energy, latency, etc) on another hand I can't find a single hammer to address them. Alex > > > ksjp > > Alexandru Petrescu wrote: >> David E. Culler a écrit : [...] >>> 2. The charter of ROLL >>> (http://www.ietf.org/html.charters/roll-charter.html) only >>> mentions the word MOBILE in making clear that it must be >>> considered as part of the due diligence associated with the >>> routing requirements. If the process of turning over all the >>> stones should bring mobility to the surface as a primary issue, >>> then it would make sense to consider the overlap carefully. They >>> don't. All the requirements are stationary. Mobility within >>> them is extremely constrained. >> >> More to the point, current ROLL req drafts mentioning mobility are >> as follows: >> >> Industrial: 5 - Mobility: wireless worker, mobile field devices, >> speed 35kmph >> >> Home: 2 - Support of Mobility: multi-purpose remote, mobile >> wearable >> >> Building: 3 - Mobility: mobile device association in 15s, location >> tracking >> >> These kinds of key words have often been addressed with Mobile IP >> based protocols (of which NEMO are extensions), for example in a >> IPv6-enabled wearable PAN, or a bus connected to Internet, etc. >> >> Given that, I am surprised it's said that all requirements are >> stationary and mobility within them is extremely constrained(?) >> >> Alex >> >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Tue Feb 3 13:18:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25C6228C147 for ; Tue, 3 Feb 2009 13:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drEcLI3WvBLd for ; Tue, 3 Feb 2009 13:18:02 -0800 (PST) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by core3.amsl.com (Postfix) with ESMTP id 3B4453A6BF0 for ; Tue, 3 Feb 2009 13:17:57 -0800 (PST) Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id 103948181A3; Tue, 3 Feb 2009 22:17:33 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp3-g21.free.fr (Postfix) with ESMTP id B3A27818224; Tue, 3 Feb 2009 22:17:30 +0100 (CET) Message-ID: <4988B44E.3070706@gmail.com> Date: Tue, 03 Feb 2009 22:17:02 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Kris Pister References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> <49887E75.1090705@gmail.com> <7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com> <4988AA03.802@gmail.com> <4988AEB1.7050104@eecs.berkeley.edu> In-Reply-To: <4988AEB1.7050104@eecs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090203-0, 03/02/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] suggestion of NEMO text for protocols-survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 21:18:03 -0000 Kris Pister a écrit : > Is the footprint really 200kb, which is painful but might be ok, or > 200kB? The latter is not going to work for any of the platforms > currently addressing the four RoLL applications. 200k_B_. I consider it small. A large part of an IPv6 stack is taken by TCP code. ND also may have large state machine for NUD, but could be stripped. Are RoLL applications relying on TCP or not? Is UDP sufficient? > I don't understand the 40% WiFi driver and 1% for traffic. What does > that mean, exactly? It means the proportion of the consumption is veyr much taken by the wifi chipset, and very very little by sending/receiving a packet. > For most of the applications that we're talking about here, you get > 10 to 100 microAmps average current. This doesn't have anything to > do with radios, DLLs, or routing protocols, it has to do with the > acceptable battery size/cost and required lifetime. Anything with > "40%" and "WiFi" in the same part of a sentence makes me nervous. :-) In the reassuring applications: do we have an idea about the percentage of consumption of turning the radio on, as compared to sending/receiving an IP packet? And the name of that particular link layer? One would prefer be sure when optimizing energy consumption that s/he addresses the right weaknesses, at the right layers. A quantitative approach would involve measuring these... Alex > > ksjp > > Alexandru Petrescu wrote: >> JP Vasseur a écrit : >>> Please do ... please do it short and concise ;-) >> >> The existing NEMO text is in draft-ietf-roll-protocols-survey-05: >> >>> This document does not examine the Network Mobility Basic Support >>> Protocol (NEMO RFC 3963 [RFC3963]) because it is not a routing >>> protocol. It does not examine hierarchical NEMO >>> [I-D.thubert-tree-discovery] as a candidate because it only >>> maintains a default route and so is insufficient for general >>> routing. Although NEMO itself is not a suitable routing solution >>> to LLNs, some of its mechanisms, such as loop-free tree >>> formation, might be useful in an LLN routing protocol. >> >> I suggest replacing the above paragraph with the following longer >> text, maybe in its own section. >> >> In this section we briefly overview the NEMO extensions to Mobile >> IPv6, its accepted drawbacks, and its features with respect to >> memory footprint (Table?), protocol reliability (Loss, Control?), >> energy metrics (Link and Node Cost?) and security. >> >> The Network Mobility Basic Support Protocol ("NEMO" RFC 3963, >> terminology RFC4885) is a set of extensions to the Mobile IPv6 >> protocol (RFC3775). They extend Mobile IPv6 to accomodate a moving >> network, i.e. a set of nodes moving together, and connecting to >> the Internet: laptops in a bus, or a PDA and a camera of a PAN. >> Arbitrarily "nested" combinations - e.g. a PAN getting into a bus - >> can equally be accomodated. One noticeable problem is the >> enforcing of artifically long paths - all traffic between a >> Correspondent Node and a Local Fixed Node must travel through the >> Home Agent(s) (RFC4888), despite the existence of shorter straight >> IP paths. Solutions addressing this problem are in the space of >> Route Optimization for NEMO (RFC4889), yet none is Standards Track >> at this point. >> >> The Mobile IPv6 protocol has been implemented on a wide range of >> platforms, of main OS vendors and freely available, from servers to >> smaller devices. A footprint of a TCP/UDP/ND/IPv6 stack running >> NEMO and Mobile IPv6 in a Mobile Router is for example 200kb. >> >> Although the Mobile IPv6 protocol is basically a two-way exchange, >> it has lifetimes, timers and retransmission logic such as to >> accommodate several types of failures of the critical >> messages; and rate limitation such as to avoid too much >> noise. The >> Mobile IPv6 NEMO extensions are used mainly between a Mobile Router >> and a Home Agent: the MR updates only the HA about its Mobile >> Network Prefix (MNP); it doesn't update several entities, just one. >> The Mobile IPv6 protocol and implicitely its NEMO extensions do >> not currently have any field in the messages, nor any logic in the >> nodes, relating to energy consumption. One would think that >> binding lifetimes would need to depend on remaining battery level; >> and maybe an Error Code from the HA meaning 'not enough battery'; >> or similar. Other possibilities do exist. >> >> An approximation of energy consumption of a particular small device >> running such an IPv6 stack can be divided as follows: 40% energy >> to enable the WiFi driver, 1% of energy to send IPv6 packets. >> >> The NEMO extensions and the Mobile IPv6 protocol are generally >> believed to be secure. For through-the-HA communication they make >> extensive use of IPsec transport and tunnels (RFC4877) whereas for >> Route Optimization for Mobile Hosts a particular authentication >> mechanism is used (Return Routability tests). >> >> Conclusion: this section surveyed the NEMO (RFC3963) extensions to >> the Mobile IPv6 protocol, as necessary for a ROLL WG context. It >> doesn't in any way pretend to be a complete (the protocol has many >> other features necessary in mobility environments), and errors may >> have slipped through, this is open to comments. >> >> What do you think? >> >> Alex >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Tue Feb 3 13:19:52 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C3FE28C162 for ; Tue, 3 Feb 2009 13:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFuZnPx6swjZ for ; Tue, 3 Feb 2009 13:19:51 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 7410428C0D6 for ; Tue, 3 Feb 2009 13:19:49 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 34D77E0815A; Tue, 3 Feb 2009 22:19:26 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp6-g21.free.fr (Postfix) with ESMTP id 0E761E08188; Tue, 3 Feb 2009 22:19:23 +0100 (CET) Message-ID: <4988B4BF.8020000@gmail.com> Date: Tue, 03 Feb 2009 22:18:55 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Stephen Dawson-Haggerty References: <20090127000001.9F1F03A6819@core3.amsl.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> <49887E75.1090705@gmail.com> <44680fe70902030943q416b0908occe4dbc6b1a331e8@mail.gmail.com> <498883C1.4070703@gmail.com> <44680fe70902031147i3f0a30d8hc1b86c091dfb2792@mail.gmail.com> <4988AEF0.20803@gmail.com> <44680fe70902031258o54190cfdl6e5ce794e9b61e12@mail.gmail.com> In-Reply-To: <44680fe70902031258o54190cfdl6e5ce794e9b61e12@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090203-0, 03/02/2009), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 21:19:52 -0000 Stephen Dawson-Haggerty a écrit : > Kris also brought up another good point which is that if the links > are aggressively duty cycled (we consider that likely) matters are > likely to be even worse. Also, most discussion in this group has not > considered point to point links; I don't believe they are prevalent > in this design space. I think the slower the link, and the higher latency, the more chances are it's a ptp link. I think some Bluetooth serial links are ptp. I think serial rs-232 is ptp. I think these are potentially used in this space. Alex > > Thanks, Steve > > On Tue, Feb 3, 2009 at 12:54 PM, Alexandru Petrescu > > > wrote: > > Stephen Dawson-Haggerty a écrit : [discussion about RA implosion when > RS sent to thousand neighbours, protocols-survey draft] > > > Which link sorry? Which is the link at 900Mhz over which ND would > behave such badly? What's its bandwidth? Is it a ptp or shared > link? > > > The ISM band has slots at, for instance 433 and 900Mhz; older Chipcon > cc1000 radios provided a link at around 75kbps. Now, we generally > talk about 802.15.4 (that isn't) but we also don't want to rely on > mechanisms that won't work for other links since it's pretty > conceivable someone would want to run IP over a slower link (for > instance to save power). A 50 byte packet at 75kbps is almost 7ms > long, so it's not unreasonable to conclude that it won't support > densities higher then 25-50 if everyone MUST reply within half a > second. > > > Stephen, I fully agree the links you mention at 75kbps are pertinent > and should be accommodated in ROLL environments. > > Indeed, 7ms latency is quite high and 1000 such messages wouldn't fit > in 500ms, even if randomly spaced: some times there would be 2 or 3 > simultaneous messages, maybe not very stormy. > > PtP? I wanted to ask, arent't these links with high latencies of type > point-to-point? I think it's very probably that a link with 75kbps > bandwidth be point-to-point. In this case the nodes are neighbors > 1-by-1, and thus no implosion (or message 'storm') danger. > > > In sensor nets reply implosion is pretty common; I'm sure there are > other people here will attest to that and you have to be very careful > to manage it, for instance using a density-dependent scheme like > Trickle. > > Let's not get sidetracked by ND though; > > > I'm using ND and link types as an opportunity to try to describe the > addressing architecture and the subnet structure. These are typical > for MANET discussion and often helpful to identify what can be done > at IP level and what below. > > Alex > > From alexandru.petrescu@gmail.com Tue Feb 3 13:36:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFD7E3A68A2 for ; Tue, 3 Feb 2009 13:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wI9vSI+Jqo1 for ; Tue, 3 Feb 2009 13:36:13 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 101713A680C for ; Tue, 3 Feb 2009 13:36:10 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 3A097E0807E; Tue, 3 Feb 2009 22:35:47 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp6-g21.free.fr (Postfix) with ESMTP id 0A0EFE0822F; Tue, 3 Feb 2009 22:35:44 +0100 (CET) Message-ID: <4988B894.7090808@gmail.com> Date: Tue, 03 Feb 2009 22:35:16 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Stephen Dawson-Haggerty References: <20090127000001.9F1F03A6819@core3.amsl.com> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> <49887E75.1090705@gmail.com> <7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com> <4988AA03.802@gmail.com> <44680fe70902031255y78cd6f0aqa6de46c1e2a6f125@mail.gmail.com> In-Reply-To: <44680fe70902031255y78cd6f0aqa6de46c1e2a6f125@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090203-0, 03/02/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] suggestion of NEMO text for protocols-survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 21:36:14 -0000 Stephen Dawson-Haggerty a écrit : > Thanks for the suggestions. I think we may be able to work with some > of this. However, some of the language is unnecessarily imprecise > ("maybe an Error Code from the HA meaning 'not enough battery'; or > similar.", "avoid too much noise. "). Imprecise because avoid being restrictive. "avoid too much noise" - maybe "avoid protocol chattiness"? I'd agree to another more literate re-formulation. > Including power numbers is inappropriate because as we state in > section 3.3 we do not consider any particular implementation. Well these are not power numbers but percentage, reports, hinting between link layers and network layers. > Discussing security is important and has been discussed on the list, > however, section 10 indicates that it is out of scope; it is yet > another reason this document is "necessary but not sufficient" (3.2). Do you mind mentioning NEMO rfc3963 is believed to be secure? Do you think otherwise? > I believe the goal for an updated paragraph should be to (a) briefly > define what NEMO is/does (we don't really do this now) and (b) why > certain mechanims are desirable to consider it when actually > designing a routing protocol (we have only a sentence on this now), > and finally (c) justify why it is not included in Table 1 (we do > this). So, expanding on the (a) and (b) seems worthwhile, but not in > more then a couple of sentences each. I understand what you want in (a) but could you clarify what you want in (b)? why certain mechanisms are desirable to consider when designing a routing protocol? Which mechanisms? > JP asked (and we authors feel), short and concise :) Trying to be concise. > The below accomplishes (a) and (c). We might want to identify more > specific ways NEMO mechanisms could be used in a ROLL solution to > deal with (b). Thoughts? I don't understand, do you want me to describe personal proposals (non WG items, non RFC) about how some NEMO extensions could be used in ROLL? Wouldn't that be too much for this WG? (and be more pertinent for MEXT WG). Alex > Thanks for your suggestions. Steve > > The Network Mobility Basic Support Protocol ("NEMO" RFC 3963, > terminology RFC4885) is a set of extensions to the Mobile IPv6 > protocol (RFC3775). They extend Mobile IPv6 to accomodate a moving > network, i.e. a set of nodes moving together, and connecting to the > Internet: laptops in a bus, or a PDA and a camera of a PAN. > Arbitrarily "nested" combinations - e.g. a PAN getting into a bus - > can equally be accomodated. This document does not examine (NEMO RFC > 3963 [RFC3963]) because it is not a routing protocol. It does not > examine hierarchical NEMO [I-D.thubert-tree-discovery] as a candidate > because it only maintains a default route and so is insufficient for > general routing. Although NEMO itself is not a suitable routing > solution to LLNs, some of its mechanisms, such as loop-free tree > formation, might be useful in an LLN routing protocol. > > > > > On Tue, Feb 3, 2009 at 12:33 PM, Alexandru Petrescu > > > wrote: > > JP Vasseur a écrit : > > Please do ... please do it short and concise ;-) > > > The existing NEMO text is in draft-ietf-roll-protocols-survey-05: > > This document does not examine the Network Mobility Basic Support > Protocol (NEMO RFC 3963 [RFC3963]) because it is not a routing > protocol. It does not examine hierarchical NEMO > [I-D.thubert-tree-discovery] as a candidate because it only maintains > a default route and so is insufficient for general routing. Although > NEMO itself is not a suitable routing solution to LLNs, some of its > mechanisms, such as loop-free tree formation, might be useful in an > LLN routing protocol. > > > I suggest replacing the above paragraph with the following longer > text, maybe in its own section. > > In this section we briefly overview the NEMO extensions to Mobile > IPv6, its accepted drawbacks, and its features with respect to memory > footprint (Table?), protocol reliability (Loss, Control?), energy > metrics (Link and Node Cost?) and security. > > The Network Mobility Basic Support Protocol ("NEMO" RFC 3963, > terminology RFC4885) is a set of extensions to the Mobile IPv6 > protocol (RFC3775). They extend Mobile IPv6 to accomodate a moving > network, i.e. a set of nodes moving together, and connecting to the > Internet: laptops in a bus, or a PDA and a camera of a PAN. > Arbitrarily "nested" combinations - e.g. a PAN getting into a bus - > can equally be accomodated. One noticeable problem is the enforcing > of artifically long paths - all traffic between a Correspondent Node > and a Local Fixed Node must travel through the Home Agent(s) > (RFC4888), despite the existence of shorter straight IP paths. > Solutions addressing this problem are in the space of Route > Optimization for NEMO (RFC4889), yet none is Standards Track at this > point. > > The Mobile IPv6 protocol has been implemented on a wide range of > platforms, of main OS vendors and freely available, from servers to > smaller devices. A footprint of a TCP/UDP/ND/IPv6 stack running NEMO > and Mobile IPv6 in a Mobile Router is for example 200kb. > > Although the Mobile IPv6 protocol is basically a two-way exchange, it > has lifetimes, timers and retransmission logic such as to > accommodate several types of failures of the critical messages; and > rate limitation such as to avoid too much noise. > > > The Mobile IPv6 NEMO extensions are used mainly between a Mobile > Router and a Home Agent: the MR updates only the HA about its Mobile > Network Prefix (MNP); it doesn't update several entities, just one. > > > The Mobile IPv6 protocol and implicitely its NEMO extensions do not > currently have any field in the messages, nor any logic in the nodes, > relating to energy consumption. One would think that binding > > > lifetimes would need to depend on remaining battery level; and maybe > an Error Code from the HA meaning 'not enough battery'; or similar. > Other possibilities do exist. > > An approximation of energy consumption of a particular small device > running such an IPv6 stack can be divided as follows: 40% energy to > enable the WiFi driver, 1% of energy to send IPv6 packets. > > The NEMO extensions and the Mobile IPv6 protocol are generally > believed to be secure. For through-the-HA communication they make > extensive use of IPsec transport and tunnels (RFC4877) whereas for > Route Optimization for Mobile Hosts a particular authentication > mechanism is used (Return Routability tests). > > Conclusion: this section surveyed the NEMO (RFC3963) extensions to > the Mobile IPv6 protocol, as necessary for a ROLL WG context. It > doesn't in any way pretend to be a complete (the protocol has many > other features necessary in mobility environments), and errors may > have slipped through, this is open to comments. > > What do you think? > > Alex > > _______________________________________________ Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > From pister@eecs.berkeley.edu Tue Feb 3 13:45:32 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D1DF3A6805 for ; Tue, 3 Feb 2009 13:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.549 X-Spam-Level: X-Spam-Status: No, score=-5.549 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAvIt9pAZsn6 for ; Tue, 3 Feb 2009 13:45:31 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 337A33A67DF for ; Tue, 3 Feb 2009 13:45:31 -0800 (PST) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n13Lj8b6006296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Feb 2009 13:45:10 -0800 (PST) Message-ID: <4988BADF.3050801@eecs.berkeley.edu> Date: Tue, 03 Feb 2009 13:45:03 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Alexandru Petrescu References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498878B9.80403@eecs.berkeley.edu> <49888244.2030008@gmail.com> <49889A43.8040903@eecs.berkeley.edu> <4988B262.2090904@gmail.com> In-Reply-To: <4988B262.2090904@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 21:45:32 -0000 Alexandru Petrescu wrote: > Kris Pister a écrit : >> Alex - I can't speak for the other applications, but it is misleading >> to use the industrial requirements document to support a need for >> mobility. There are 14 "MUST"s in the industrial requirements >> document. None of them is associated with mobility. There are a few >> "SHOULD"s associated with mobility. It would be nice to have, but >> not at the expense of any of the MUSTs. >> >> I don't understand the discussion about the protocol survey document. >> It seems like the discussion is distracting us from the main goal: >> finding a routing protocol that works. If there is a protocol that >> satisfies the routing requirement MUSTs in my document and the other >> three, then let's implement it on motes and move on, and we won't >> care too much about whether RoLL recharters or not, and we certainly >> won't care what gets listed in the protocol survey document. If such >> a protocol doesn't exist, then please let's recharter and create one. > > I also highly appreciate implementations. > > The question about rechartering: implementations for a charter need to > know what to implement, lazily. I think we (at least not me) don't > know what to implement at this point about ROLL. > > On one hand it's very specific (routing, energy, latency, etc) on > another hand I can't find a single hammer to address them. Hence the need to recharter to build the right hammer. ksjp > > Alex > >> >> >> ksjp >> >> Alexandru Petrescu wrote: >>> David E. Culler a écrit : [...] >>>> 2. The charter of ROLL >>>> (http://www.ietf.org/html.charters/roll-charter.html) only >>>> mentions the word MOBILE in making clear that it must be >>>> considered as part of the due diligence associated with the >>>> routing requirements. If the process of turning over all the >>>> stones should bring mobility to the surface as a primary issue, >>>> then it would make sense to consider the overlap carefully. They >>>> don't. All the requirements are stationary. Mobility within >>>> them is extremely constrained. >>> >>> More to the point, current ROLL req drafts mentioning mobility are >>> as follows: >>> >>> Industrial: 5 - Mobility: wireless worker, mobile field devices, >>> speed 35kmph >>> >>> Home: 2 - Support of Mobility: multi-purpose remote, mobile >>> wearable >>> >>> Building: 3 - Mobility: mobile device association in 15s, location >>> tracking >>> >>> These kinds of key words have often been addressed with Mobile IP >>> based protocols (of which NEMO are extensions), for example in a >>> IPv6-enabled wearable PAN, or a bus connected to Internet, etc. >>> >>> Given that, I am surprised it's said that all requirements are >>> stationary and mobility within them is extremely constrained(?) >>> >>> Alex >>> >>> >>> _______________________________________________ Roll mailing list >>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> > From pister@eecs.berkeley.edu Tue Feb 3 14:02:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 937373A69E7 for ; Tue, 3 Feb 2009 14:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ps3LPMszf7U1 for ; Tue, 3 Feb 2009 14:02:46 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id BD4993A67DF for ; Tue, 3 Feb 2009 14:01:58 -0800 (PST) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n13M1ajF006735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Feb 2009 14:01:37 -0800 (PST) Message-ID: <4988BEBB.5060600@eecs.berkeley.edu> Date: Tue, 03 Feb 2009 14:01:31 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Alexandru Petrescu References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> <49887E75.1090705@gmail.com> <7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com> <4988AA03.802@gmail.com> <4988AEB1.7050104@eecs.berkeley.edu> <4988B44E.3070706@gmail.com> In-Reply-To: <4988B44E.3070706@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] suggestion of NEMO text for protocols-survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 22:02:47 -0000 Alexandru Petrescu wrote: > Kris Pister a écrit : >> Is the footprint really 200kb, which is painful but might be ok, or >> 200kB? The latter is not going to work for any of the platforms >> currently addressing the four RoLL applications. > > 200k_B_. I consider it small. I think that this may be one of the points of disconnect. The wireless sensor network products that are shipping today in industrial, building, home, and urban applications all have far less than 200kB of program memory. 50kB might be close to average. In this amount of space, protocols have implemented RS, RA, ND, multi-topology routing, reliable and best-effort transport, etc., in addition to the DLL and application. So space is very tight, but there are existence proofs that it's possible. There's a huge body of literature describing the academic side of this, and a couple of very thick standards documents describing HART, ISA100, etc. > > A large part of an IPv6 stack is taken by TCP code. ND also may have > large state machine for NUD, but could be stripped. > > Are RoLL applications relying on TCP or not? Is UDP sufficient? Both reliable and best-effort transport are required for industrial automation. Applications don't use TCP today because they don't use IP today. > >> I don't understand the 40% WiFi driver and 1% for traffic. What does >> that mean, exactly? > > It means the proportion of the consumption is veyr much taken by the > wifi chipset, and very very little by sending/receiving a packet. We don't have that luxury. If sending/receiving the packet isn't in the tens of percent of the overall node power consumption, the protocol stack is not likely to see widespread adoption. Anything less means you're just not efficient enough of with your radio. > >> For most of the applications that we're talking about here, you get >> 10 to 100 microAmps average current. This doesn't have anything to >> do with radios, DLLs, or routing protocols, it has to do with the >> acceptable battery size/cost and required lifetime. Anything with >> "40%" and "WiFi" in the same part of a sentence makes me nervous. > > :-) > > In the reassuring applications: do we have an idea about the percentage > of consumption of turning the radio on, as compared to sending/receiving > an IP packet? And the name of that particular link layer? For 15.4 radios, turning on the radio costs you very roughly 1ms worth of equivalent radio on-time. that translates to 30B worth of sending/receiving (250kbps is the most common raw bit rate). > > One would prefer be sure when optimizing energy consumption that s/he > addresses the right weaknesses, at the right layers. A quantitative > approach would involve measuring these... The measurements have been done. There are lots and lots of papers and some datasheets with these measurements for a wide range of platforms. > > Alex ksjp > >> >> ksjp >> >> Alexandru Petrescu wrote: >>> JP Vasseur a écrit : >>>> Please do ... please do it short and concise ;-) >>> >>> The existing NEMO text is in draft-ietf-roll-protocols-survey-05: >>> >>>> This document does not examine the Network Mobility Basic Support >>>> Protocol (NEMO RFC 3963 [RFC3963]) because it is not a routing >>>> protocol. It does not examine hierarchical NEMO >>>> [I-D.thubert-tree-discovery] as a candidate because it only >>>> maintains a default route and so is insufficient for general >>>> routing. Although NEMO itself is not a suitable routing solution >>>> to LLNs, some of its mechanisms, such as loop-free tree formation, >>>> might be useful in an LLN routing protocol. >>> >>> I suggest replacing the above paragraph with the following longer >>> text, maybe in its own section. >>> >>> In this section we briefly overview the NEMO extensions to Mobile >>> IPv6, its accepted drawbacks, and its features with respect to >>> memory footprint (Table?), protocol reliability (Loss, Control?), >>> energy metrics (Link and Node Cost?) and security. >>> >>> The Network Mobility Basic Support Protocol ("NEMO" RFC 3963, >>> terminology RFC4885) is a set of extensions to the Mobile IPv6 >>> protocol (RFC3775). They extend Mobile IPv6 to accomodate a moving >>> network, i.e. a set of nodes moving together, and connecting to the >>> Internet: laptops in a bus, or a PDA and a camera of a PAN. >>> Arbitrarily "nested" combinations - e.g. a PAN getting into a bus - >>> can equally be accomodated. One noticeable problem is the >>> enforcing of artifically long paths - all traffic between a >>> Correspondent Node and a Local Fixed Node must travel through the >>> Home Agent(s) (RFC4888), despite the existence of shorter straight >>> IP paths. Solutions addressing this problem are in the space of >>> Route Optimization for NEMO (RFC4889), yet none is Standards Track >>> at this point. >>> >>> The Mobile IPv6 protocol has been implemented on a wide range of >>> platforms, of main OS vendors and freely available, from servers to >>> smaller devices. A footprint of a TCP/UDP/ND/IPv6 stack running >>> NEMO and Mobile IPv6 in a Mobile Router is for example 200kb. >>> >>> Although the Mobile IPv6 protocol is basically a two-way exchange, >>> it has lifetimes, timers and retransmission logic such as to >>> accommodate several types of failures of the critical messages; >>> and rate limitation such as to avoid too much >>> noise. The >>> Mobile IPv6 NEMO extensions are used mainly between a Mobile Router >>> and a Home Agent: the MR updates only the HA about its Mobile >>> Network Prefix (MNP); it doesn't update several entities, just one. >>> The Mobile IPv6 protocol and implicitely its NEMO extensions do >>> not currently have any field in the messages, nor any logic in the >>> nodes, relating to energy consumption. One would think that binding >>> lifetimes would need to depend on remaining battery level; and maybe >>> an Error Code from the HA meaning 'not enough battery'; or >>> similar. Other possibilities do exist. >>> >>> An approximation of energy consumption of a particular small device >>> running such an IPv6 stack can be divided as follows: 40% energy to >>> enable the WiFi driver, 1% of energy to send IPv6 packets. >>> >>> The NEMO extensions and the Mobile IPv6 protocol are generally >>> believed to be secure. For through-the-HA communication they make >>> extensive use of IPsec transport and tunnels (RFC4877) whereas for >>> Route Optimization for Mobile Hosts a particular authentication >>> mechanism is used (Return Routability tests). >>> >>> Conclusion: this section surveyed the NEMO (RFC3963) extensions to >>> the Mobile IPv6 protocol, as necessary for a ROLL WG context. It >>> doesn't in any way pretend to be a complete (the protocol has many >>> other features necessary in mobility environments), and errors may >>> have slipped through, this is open to comments. >>> >>> What do you think? >>> >>> Alex >>> >>> _______________________________________________ Roll mailing list >>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> > From pister@eecs.berkeley.edu Tue Feb 3 14:11:56 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E40863A6A8E for ; Tue, 3 Feb 2009 14:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.811 X-Spam-Level: X-Spam-Status: No, score=-5.811 tagged_above=-999 required=5 tests=[AWL=0.788, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcPHF1ZnZydb for ; Tue, 3 Feb 2009 14:11:56 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 0ACC73A6A40 for ; Tue, 3 Feb 2009 14:11:56 -0800 (PST) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n13MBXPd006979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Feb 2009 14:11:34 -0800 (PST) Message-ID: <4988C110.4090902@eecs.berkeley.edu> Date: Tue, 03 Feb 2009 14:11:28 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Alexandru Petrescu References: <20090127000001.9F1F03A6819@core3.amsl.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> <49887E75.1090705@gmail.com> <44680fe70902030943q416b0908occe4dbc6b1a331e8@mail.gmail.com> <498883C1.4070703@gmail.com> <44680fe70902031147i3f0a30d8hc1b86c091dfb2792@mail.gmail.com> <4988AEF0.20803@gmail.com> <44680fe70902031258o54190cfdl6e5ce794e9b61e12@mail.gmail.com> <4988B4BF.8020000@gmail.com> In-Reply-To: <4988B4BF.8020000@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 22:11:57 -0000 Alexandru Petrescu wrote: > Stephen Dawson-Haggerty a écrit : >> Kris also brought up another good point which is that if the links >> are aggressively duty cycled (we consider that likely) matters are >> likely to be even worse. Also, most discussion in this group has not >> considered point to point links; I don't believe they are prevalent >> in this design space. > > I think the slower the link, and the higher latency, the more chances > are it's a ptp link. I think some Bluetooth serial links are ptp. I > think serial rs-232 is ptp. I think these are potentially used in > this space. I've deployed countless networks with 76.8kbps and 250kbps raw bit rate radios. In both cases, the typical duty cycle on the radio is below 0.1%, for an effective link data rate of at most a few tens to hundreds of bits per second, and latencies of very roughly 1 second per hop. These networks contain hundreds of nodes, and are tens of hops across. You are probably right that traditionally slower links were point-to-point. Point-to-point links don't deliver the range and reliability required in this space, whereas mesh networks do. Hence the need for routing. Hence the need for RoLL. Hence the need to recharter. :) ksjp > > Alex > >> >> Thanks, Steve >> >> On Tue, Feb 3, 2009 at 12:54 PM, Alexandru Petrescu >> > >> wrote: >> >> Stephen Dawson-Haggerty a écrit : [discussion about RA implosion when >> RS sent to thousand neighbours, protocols-survey draft] >> >> >> Which link sorry? Which is the link at 900Mhz over which ND would >> behave such badly? What's its bandwidth? Is it a ptp or shared >> link? >> >> >> The ISM band has slots at, for instance 433 and 900Mhz; older Chipcon >> cc1000 radios provided a link at around 75kbps. Now, we generally >> talk about 802.15.4 (that isn't) but we also don't want to rely on >> mechanisms that won't work for other links since it's pretty >> conceivable someone would want to run IP over a slower link (for >> instance to save power). A 50 byte packet at 75kbps is almost 7ms >> long, so it's not unreasonable to conclude that it won't support >> densities higher then 25-50 if everyone MUST reply within half a >> second. >> >> >> Stephen, I fully agree the links you mention at 75kbps are pertinent >> and should be accommodated in ROLL environments. >> >> Indeed, 7ms latency is quite high and 1000 such messages wouldn't fit >> in 500ms, even if randomly spaced: some times there would be 2 or 3 >> simultaneous messages, maybe not very stormy. >> >> PtP? I wanted to ask, arent't these links with high latencies of type >> point-to-point? I think it's very probably that a link with 75kbps >> bandwidth be point-to-point. In this case the nodes are neighbors >> 1-by-1, and thus no implosion (or message 'storm') danger. >> >> >> In sensor nets reply implosion is pretty common; I'm sure there are >> other people here will attest to that and you have to be very careful >> to manage it, for instance using a density-dependent scheme like >> Trickle. >> >> Let's not get sidetracked by ND though; >> >> >> I'm using ND and link types as an opportunity to try to describe the >> addressing architecture and the subnet structure. These are typical >> for MANET discussion and often helpful to identify what can be done >> at IP level and what below. >> >> Alex >> >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Tue Feb 3 14:20:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 746F628C18B for ; Tue, 3 Feb 2009 14:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.204 X-Spam-Level: X-Spam-Status: No, score=-10.204 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pf94yCR8XAoY for ; Tue, 3 Feb 2009 14:20:50 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id EAF363A6B44 for ; Tue, 3 Feb 2009 14:20:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,374,1231113600"; d="scan'208,217";a="32757676" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2009 22:20:23 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n13MKNwi008915; Tue, 3 Feb 2009 23:20:23 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n13MKNOf003362; Tue, 3 Feb 2009 22:20:23 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 23:20:23 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 23:20:22 +0100 Message-Id: From: JP Vasseur To: ROLL WG , Thomas Heide Clausen , Alexandru Petrescu , Emmanuel Baccelli , Kris Pister In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-126--158132702 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Feb 2009 23:20:21 +0100 References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <7F8459D1-3464-435A-AF8F-F9C437036FDF@cisco.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Feb 2009 22:20:22.0462 (UTC) FILETIME=[9ACED5E0:01C9864D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=53129; t=1233699623; x=1234563623; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20If=20possible=20... |Sender:=20; bh=ewfHz1EKPyUmbbqurSK9mkec/2t5h71UGc07HEPXyp4=; b=S2ros8D2bfCMQiCyq0Y+IL6Ndkt9ktHno/eQFsPboSpriyj4vrufaObxAM GopINBC82pNuTYqMDPlbRgEe8h4GsMhDlRDq82VaTQAvXAjpH/H/ugUTbg2l D8XtQCjlBr; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Ross Callon Subject: [Roll] If possible ... X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 22:20:53 -0000 --Apple-Mail-126--158132702 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear all, Great to see all these discussions, but in light of the discussions today I would like to *converge* - I did propose a plan (below). Until we have concluded on the protocol survey (we're close) and re- chartering (coming soon), can we focus the discussion, it goes in all directions. Many Thanks. JP. On Feb 3, 2009, at 6:36 PM, JP Vasseur wrote: > Thanks Dave for AD's feed-back. > > We *are* making progress and looking at all the interest that we are > gathering from many participants, this is a good sign of strong > participation for the next phase, a key of success. > > First of all, I would like to remind that all the routing > requirements documents are finalized. I asked for a last revision of > the building routing requirements documents before publication > request. And then we will be done for this part. Lot of work. > > Here is what I propose: > > 1) I guess that things have been clarified on the WG positioning > issue. > 2) Many supportive request to close on this and move forward. > 3) Still there are a few requests that have been made by Thomas, > Alex, ... that we should try to address. > May I ask you to try to limit as much as possible your request and > we will do everything possible to address them. > 4) End of this week, we will close on the protocol survey. > 5) Right after we'll propose you a new charter (one week discussion) > before IESG submission. > 6) If/once re-chartered, we count on everybody's help to continue > the good work. > > Thanks. > > JP. > > > On Feb 3, 2009, at 5:52 PM, David Ward wrote: > >> All - >> >> We debated the delta between these three WGs when chartering ROLL >> for a considerable period of time. I do not want to revisit that >> debate but, I will quickly summarize here >> >> - 6LOWPAN is not working at the IP layer so, the overlap here is >> really not an issue. >> - MANET is and has been working on routing protocols for mobile, ad >> hoc networks with specific requirements and use cases. Some of >> those use cases may or may not overlap with ROLL. There will be >> lessons to be learned but, the primary use cases being worked on >> appeared by all the chairs and ADs involved to be different enough >> to warrant a new WG in this area. >> - ROLL was originally chartered to write the requirements and >> evaluate existing protocols for low power, lossy networks running >> over IP (some call these "sensor networks"). ROLL is only >> chartered to work on the routing protocol portion. Not the >> transport, encap or other topics at this time. Also note that >> mobility is not under consideration at this time. >> >> ROLL WG appears to have come to consensus on the requirement docs >> that state specific functions, attributes, power/memory envelope >> and algorithmic considerations that must be "in the routing >> protocol" for these networks. The survey ID (which is of course a >> snapshot at one point in time) puts some bounds on mapping the >> required functions, attributes and other considerations into >> protocols available *today.* >> >> Given the real work of designing a protocol hasn't begun by the >> ROLL WG participants; holding up the WG to begin taking what they >> currently defined as a very complex, multivariate problem and begin >> whittling it down to something solvable via theoretical and >> hypothetical exercises seems like an unwise use of time given the >> experience and energy of the WG in this problem space. The WG must >> move beyond the moderately high-level boundary setting exercise >> (which I believe there is consensus) and move onto the more >> challenging work of defining the objects, algorithms, semantics, >> state machines and functionality of the protocol. In the design >> phase (vs the survey phase) a better evaluation can be made of the >> ease or difficulty of "from scratch" or "modify what we have" can >> be made. I expect "wild swings" of the design pattern of the >> protocol during the first year of the design effort. I attempted to >> make this clear at the mic in Minneapolis that the current >> trajectory is very complex problem domain that hasn't born a lot of >> fruit but, that in the design phase reducing the complexity must >> occur. Members of the WG who have vast experience in these types of >> networks and have widely deployed products have stated that the >> routing protocol issues are solvable problems with some simplifying >> assumptions. I look forward to the WG making these design decisions >> and tradeoffs and debating the structure of the protocol. Any >> protocol reuse, experience, etc will be critical at this point to >> make the correct choices and I look to MANET, ROLL, MEXT, 6LOWPAN >> and other IETF'ers with routing protocol experience to contribute. >> This is an industry important juncture and moving LPLN to IP is a >> critical change. >> >> I am looking to the WG chairs to declare loose consensus on the >> documents (when appropriate) so that the rechartering of the WG to >> enter the design phase can occur. WIthout a doubt, the requirements >> as-is have defined the boundary of the work effort and I believe it >> is clear what is the difference between the WGs. >> >> >> HIH >> >> -DWard >> >> >> >> >> On Feb 3, 2009, at 7:14 AM, Thomas Heide Clausen wrote: >> >>> Dear JP, dear ADs, dear WG, >>> >>> (I Cc the other INT chair, as he's following 6lowpan) >>> >>> For the record, I am not arguing that MANET protocols should be >>> applied or be applicable -- as you seem to suggest in your email. >>> I believe that I have stated so repeatedly. >>> >>> I submit, however, that as it is currently exposed, ROLL, MANET >>> and 6LOW seem to be operating within the same space -- to the >>> untrained eye, in exactly the same space. My position is that it >>> would be very unfortunate having one WG creating confusion on the >>> applicability of the work of itself and of other IETF wg's, by >>> simple omission of suitable perimeter definitions. >>> >>> In that sort of situation, the IETF needs to be extra prudent to >>> make sure to clearly spell out suitable perimeter definitions >>> prior to, or conjointly with, the first publication cycle. In this >>> case, before or with the survey I-D. >>> >>> Sincerely, >>> >>> Thomas >>> >>> >>> On Feb 3, 2009, at 1:19 PM, JP Vasseur wrote: >>> >>>> Dear WG and ADs, >>>> >>>> Two issues are raised here for which we would appreciate ADs' >>>> point of view and feed-back from the WG. Please see in line. >>>> >>>> >>>> Dear Thomas, >>>> >>>> At the risk of repeating myself, I'd like to make a few important >>>> statements before *hopefully* come to a closure ;-) >>>> >>>> -> As you know, many of the ROLL WG active participants have been >>>> working quite hard to produce a detailed set of requirements, >>>> discuss how to proceed on the protocol survey document, and other >>>> ID are in the works. >>>> -> We managed to get highly experienced contributors in the field >>>> that have designed and deployed solutions so they not only have >>>> an excellent expertise of the requirements but also on solutions, >>>> -> Yes we need to rush out. Why ? Because proprietary or semi- >>>> closed non-IP solutions are being deployed at a fairly large >>>> scale. I do not think that I have to convince anybody on this >>>> list that this is the WRONG approach for a number of reasons. The >>>> industry is asking for an IP solution *now*. >>>> -> No we do not want to re-invent the wheel (see our presentation >>>> at the routing plenary in Chicago). Anything that already exists >>>> MUST (rfc2119 ;-)) be used provided that it meets our >>>> requirements. And if we can adapt an existing protocol, we are >>>> all for it ! >>>> -> Yes these requirements are quite specifics and this is >>>> precisely why ROLL has been formed, 4 application-specific >>>> routing requirements have been produced (to reduce the scope). >>>> Even if at a first sight, it looks very much similar to a MANET >>>> issue (and there ARE similarities but also very different >>>> requirements), having to deal with a highly static network of >>>> hundreds of thousands of battery operated sleeping nodes with 4K >>>> of RAM is quite specific. Note that this is not a random example, >>>> but an on-going non-IP deployed network. >>>> >>>> And to conclude on this introduction ... after an outstanding >>>> progress on the WG during the first 6-8 months, we have been >>>> slowed down dramatically for the last 2 months, thus it is time >>>> to close and move on to quickly re-charter and start the protocol >>>> work (hopefully as light as possible) to see IP-based solution >>>> deployed. I know that we are on the same page, we just need to >>>> find a good compromise on both "sides". >>>> >>>> Nothing new so far, let's move to a proposed resolution - See in >>>> line, >>>> >>>> On Feb 2, 2009, at 7:37 PM, Thomas Heide Clausen wrote: >>>> >>>>> All, >>>>> >>>>> I promised a review, and I apologize that I wasn't able to do so >>>>> before the weekend as originally projected. >>>>> >>>>> Other than some typos that Chris and others have pointed out, >>>>> I'll try to offer my understanding of the problem space and >>>>> suggest some ways of addressing my main concerns.... >>>>> >>>>> My first main concern remain that it is not clear, still, how >>>>> ROLL positions itself with respect to MANET, 6LOW et. al, all of >>>>> which appear to be within the same space and within the IETF. >>>>> This I-D sees ROLL as presented with entirely new problems (the >>>>> use of "novel" in the abstract, the statement that "existing >>>>> protocols were not designed with these requirements in mind" >>>>> seem to confirm this). >>>>> >>>>> Looking at the requirements listed, including "low power, low >>>>> bandwidth, low footprint", these appear similar to those which >>>>> are also brought forward in e.g. MANET and 6LOW. Reading >>>>> (quickly, I confess) the various requirements documents of the >>>>> draft-ietf-roll series present scenarios which are similar to >>>>> those where MANETs are deployed, and are thought deployed, as >>>>> well. >>>>> >>>>> I also note that many additional (and unstated) characteristics >>>>> between ROLL and e.g. MANET are the same: mobile, wireless, >>>>> fragility, auto-configuration, IP routing, interface/link >>>>> issues... >>>>> >>>>> Arguing that, as does this I-D, despite the above impression >>>>> "ROLL is novel and different" invites asking "how, exactly?" I >>>>> think that this question is valid, and merits being answered, >>>>> before the evaluations in this I-D can be judged fairly. >>>>> >>>>> Note that I come from a MANET background, and so I *could* >>>>> interpret from the ROLL discussion that where MANETs may aim for >>>>> "low power, low bandwidth, ....", ROLL may be able to quantify >>>>> these as "below this firm threshold" -- i.e. as a sort of >>>>> "extreme" or "constrained" MANET. >>>>> >>>>> This is a personal observation, I note, which would allow me to >>>>> comprehend how ROLL and MANET are positioned relative to one >>>>> another -- but one which neither this I-D nor the requirements >>>>> document spell out or quantify -- or, for that matter, debunk. >>>>> >>>>> I think it's critical to understand this, in order to understand >>>>> the need for a new protocol development. I think it is important >>>>> to document this understanding in something with more persistency. >>>>> >>>>> If what I suggest above makes sense as a way of positioning ROLL >>>>> and MANET relative to one another, I'd suggest including >>>>> something to this effect in the survey I-D, as this I-D is the >>>>> one making a *direct* reference to the applicability of MANET >>>>> protocols to ROLL. >>>>> >>>>> If what I suggest doesn't make sense at all, then I'd be happy >>>>> to have it debunked and, hopefully, through that debunking a >>>>> positioning/description that does ring true with us all can be >>>>> produced? >>>>> >>>>> My second main concern is, that I still think that the choice of >>>>> criteria is unfortunate (not the word, Phill has me convinced on >>>>> that front, but the actual criteria). Control cost is, by all >>>>> means, a rather meaningless criteria when taken in isolation. >>>>> I've sketched a "zero-control-cost" routing protocol (flood all >>>>> data - say use SMF, also a MANET protocol, and also a rather >>>>> "mature" I-D and wg item) which would score well on the control >>>>> cost criteria, but would likely be an extremely bad choice for >>>>> delivering unicast data. >>>>> >>>>> The metric which matters, and which should matter to ROLL in >>>>> particular, is "the total cost of getting user data through the >>>>> network, including control cost necessary to set up paths" -- as >>>>> we know, every packet sent and received costs bandwidth, energy >>>>> and cycles -- user data no different from contro. >>>>> >>>>> According to the criterions as set up by this I-D, a protocol >>>>> producing "longer than shortest paths" at the benefit of >>>>> slightly lower control cost would score better than a protocol >>>>> producing "shortest paths" with slightly higher control cost. >>>>> This is not hypothetical, btw., there are plenty of studies >>>>> observing and reflecting upon this regarding the different MANET >>>>> protocols, in academic literature -- and observed in real >>>>> networks as well. >>>>> >>>>> I note that this trade-off (slightly longer paths for lower >>>>> control cost) may be perfectly fair, assuming that very low >>>>> amounts of user data traffic transit through the network. >>>>> However, I do not see this assumption mentioned as a >>>>> justification for focusing on the control cost metric and >>>>> discarding the "path length" or the "total cost of getting user >>>>> data through the network". >>>>> >>>>> I believe that either these assumptions should be made explicit >>>>> ("there's so little user data traffic in a ROLL network that we >>>>> do not care about shortest paths") or -- if these assumptions do >>>>> not hold, that the evaluation criteria are incomplete. >>>>> >>>>> I note that it's true that we can always add another criteria ad >>>>> infinitum, and that's CLEARLY not what we want to do. However >>>>> when I say "incomplete" in the above, I simply suggest that >>>>> based on what is presented one cannot draw conclusions based on >>>>> the evaluation criteria....or, worse, that one draws the wrong >>>>> conclusions based on the information presented. >>>> >>>> It is not easy to answer each of your point without running the >>>> risk to start a debate that will never end. You raised some >>>> excellent points that I agree with and others that I firmly >>>> disagree with ... So let me try to make a few observations: >>>> 1) As pointed out earlier, yes there are similarities between >>>> MANET and ROLL. I do not see this as an issue. >>>> 2) The aim of the protocol survey IS NOT to exclude MANET >>>> protocols. As mentioned many times on the list, we *only* wanted >>>> to show that existing protocols, with no change, could not be >>>> used in LLNs. This has been clarified in the document as your >>>> request and it HAD to be clarified. >>>> 3) We could have used two different approaches for the survey: >>>> - Look at all MUST from the requirements documents >>>> - Try to derive a subset of necessary but not sufficient >>>> criteria, which the WG chose to do (consensus). Yes this list is >>>> not perfect, >>>> criteria could be changed, removed or added but looked good >>>> enough with excellent consensus until LC. >>>> 4) With regards to 6lowpan (I copy the chair), I do not see any >>>> overlap at all. Please refer to their charter and WG items. The >>>> only place that required clarification was the routing >>>> requirements and I was personally opposed to it but this was >>>> adopted as a 6lowpan WG item by consensus. We're are working >>>> together and managed to sort this out. This document will be >>>> 6lowpan specific. >>>> >>>> What I want to avoid is an endless discussion on the positioning >>>> of ROLL, MANET, 6lowpan and quite frankly we could add other WGs >>>> to the list. >>>> >>>> So what is the bottom line ? >>>> >>>> We just need to agree on the fact that there is no existing >>>> protocol that meets the ROLL requirements and move to the next >>>> step (re-chartering) to select one (hopefully not two) routing >>>> protocols in light of the routing requirement (NOT the protocol >>>> survey), which can either be an adapted MANET protocol or a new >>>> protocol. >>>> >>>> Now moving to your proposed resolution. >>>> >>>>> >>>>> >>>>> So, in a nutshell, I suggest that we address (i) the positioning >>>>> issue and (ii) the criteria issue thus: >>>>> >>>>> o Describe as I proposed above if ROLL and MANETs position >>>>> themselves as I >>>>> have deducted. If my deduction is incorrect, then let's >>>>> quickly iterate on the list >>>>> as to understand how to do produce an alternative description. >>>>> If we can't do this, >>>>> then the conclusion can be that "we do not know how ROLL and >>>>> MANET position >>>>> themselves wrt each other", and we could then state that >>>>> clearly? >>>>> >>>>> It *should* not be more than a couple of paragraphs worth of >>>>> text to add, I gather? >>>>> >>>> >>>> If you find a way to word this, please feel free and I'd be happy >>>> to help but feel it as necessary ... Any opinion from our RTG and >>>> INT ADs ? >>>> >>>>> o To the criteria, either of: >>>>> >>>>> - Add the assumption that "user data traffic is so low that >>>>> path lengths do not >>>>> matter nor does the cost of carrying user data traffice" >>>>> >>>> >>>> The motivation for selecting a longer path is not tied to the >>>> amount of traffic here but the level of constraints. Note that >>>> this is also true for several other technologies such as MPLS-TE. >>>> You may have large amount of traffic and still require to follow >>>> a non-shortest path (constrained based routing). This is detailed >>>> in several requirements IDs. Criticality of data is of course >>>> different, thus the requirements for potentially different data >>>> paths according to packet marking using DSCP. >>>> >>>>> - Add a criteria & evaluation of "path length" >>>>> >>>>> - Add a criteria & evaluation of "total cost for getting user >>>>> data through the network" >>>>> >>>> >>>> And we can add many more but if the current protocol do not >>>> satisfy existing requirements, isn't it sufficient to answer the >>>> question on whether one can find an existing protocol? >>>> >>>>> This would make a large chunk of my concerns and issues vanish, >>>>> and allow correctly interpreting and evaluating the rest of the >>>>> document. >>>> >>>> That said, question for the WG. Who think that such criteria >>>> should be added to move forward ? Please reply. >>>> >>>>> >>>>> >>>>> How does that sound as an approach forward? >>>>> >>>> >>>> Thanks for helping out. >>>> >>>> Cheers. >>>> >>>> JP. >>>> >>>>> Cheers, >>>>> >>>>> Thomas >>>>> >>>>> On Jan 27, 2009, at 1:00 AM, Internet-Drafts@ietf.org wrote: >>>>> >>>>>> A New Internet-Draft is available from the on-line Internet- >>>>>> Drafts >>>>>> directories. >>>>>> This draft is a work item of the Routing Over Low power and >>>>>> Lossy networks Working Group of the IETF. >>>>>> >>>>>> Title : Overview of Existing Routing Protocols for Low Power >>>>>> and Lossy Networks >>>>>> Author(s) : A. Tavakoli, S. Dawson-Haggerty, P. Levis >>>>>> Filename : draft-ietf-roll-protocols-survey-05.txt >>>>>> Pages : 26 >>>>>> Date : 2009-1-26 >>>>>> >>>>>> Networks of low power wireless devices introduce novel IP routing >>>>>> issues. Low-power wireless devices, such as sensors, >>>>>> actuators and >>>>>> smart objects, have difficult constraints: very limited memory, >>>>>> little processing power, and long sleep periods. As most of >>>>>> these >>>>>> devices are battery-powered, energy efficiency is critically >>>>>> important. Wireless link qualities can vary significantly >>>>>> over time, >>>>>> requiring protocols to make agile decisions yet minimize >>>>>> topology >>>>>> change energy costs. Routing over such low power and lossy >>>>>> networks >>>>>> has novel requirements that existing protocols may not >>>>>> address. This >>>>>> document provides a brief survey of the strengths and >>>>>> weaknesses of >>>>>> existing protocols with respect to this class of networks. >>>>>> From this >>>>>> survey it examines whether existing and mature IETF protocols >>>>>> can be >>>>>> used without modification in these networks, or whether >>>>>> further work >>>>>> is necessary. >>>>>> is necessary. >>>>>> >>>>>> A URL for this Internet-Draft is: >>>>>> http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-survey-05.txt >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> Below is the data which will enable a MIME compliant mail reader >>>>>> implementation to automatically retrieve the ASCII version of the >>>>>> Internet-Draft. >>>>>> Content-Type: text/plain >>>>>> Content-ID: <2009-1-26155804.I-D@ietf.org> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-126--158132702 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Dear all,

Great to see all these = discussions, but in light of the discussions today I would like to = *converge* - I did propose a plan (below). Until we have concluded on = the protocol survey (we're close) and re-chartering (coming soon), can = we focus the discussion, it goes in all = directions.

Many = Thanks.

JP.

O= n Feb 3, 2009, at 6:36 PM, JP Vasseur wrote:

Thanks Dave for AD's = feed-back.

We *are* making progress and looking at = all the interest that we are gathering from many participants, this is a = good sign of strong participation for the next phase, a key of = success.

First of all, I would like to remind = that all the routing requirements documents are finalized. I asked for a = last revision of the building routing requirements documents before = publication request. And then we will be done for this part. Lot of = work.

Here is what I = propose:

1) I guess that things have been = clarified on the WG positioning issue.
2) Many supportive = request to close on this and move forward.
3) Still there = are a few requests that have been made by Thomas, Alex, ... that we = should try to address.
May I ask you to try to limit as = much as possible your request and we will do everything possible to = address them.
4) End of this week, we will close on the = protocol survey.
5) Right after we'll propose you a new = charter (one week discussion) before IESG submission.
6) = If/once re-chartered, we count on everybody's help to continue the good = work.

Thanks.

JP.
<= div>

On Feb 3, 2009, at 5:52 PM, David = Ward wrote:

All = -

We debated the delta between these three WGs = when chartering ROLL for a considerable period of time. I do not want to = revisit that debate but, I will quickly summarize = here

- 6LOWPAN is not working at the IP layer = so, the overlap here is really not an issue.
- MANET is and = has been working on routing protocols for mobile, ad hoc networks with = specific requirements and use cases. Some of those use cases may or may = not overlap with ROLL. There will be lessons to be learned but, the = primary use cases being worked on appeared by all the chairs and ADs = involved to be different enough to warrant a new WG in this = area.
- ROLL was originally chartered to write the = requirements and evaluate existing protocols for low power, lossy = networks running over IP (some call these  "sensor networks"). ROLL = is only chartered to work on the routing protocol portion. Not the = transport, encap or other topics at this time. Also note that mobility = is not under consideration at this time.

ROLL = WG appears to have come to consensus on the requirement docs that state = specific functions, attributes, power/memory envelope and algorithmic = considerations that must be "in the routing protocol" for these = networks. The survey ID (which is of course a snapshot at one point in = time) puts some bounds on mapping the required functions, attributes and = other considerations into protocols available = *today.*

Given the real work of designing a = protocol hasn't begun by the ROLL WG participants; holding up the WG to = begin taking what they currently defined as a very complex, multivariate = problem and begin whittling it down to something solvable via = theoretical and hypothetical exercises seems like an unwise use of time = given the experience and energy of the WG in this problem space. =  The WG must move beyond the moderately high-level boundary setting = exercise (which I believe there is consensus) and move onto the more = challenging work of defining the objects, algorithms, semantics, state = machines and functionality of the protocol.  In the design phase = (vs the survey phase) a better evaluation can be made of the ease or = difficulty of "from scratch" or "modify what we have" can be made. I = expect "wild swings" of the design pattern of the protocol during the = first year of the design effort. I attempted to make this clear at the = mic in Minneapolis that the current trajectory is very complex problem = domain that hasn't born a lot of fruit but, that in the design phase = reducing the complexity must occur. Members of the WG who have vast = experience in these types of networks and have widely deployed products = have stated that the routing protocol issues are solvable problems with = some simplifying assumptions. I look forward to the WG making these = design decisions and tradeoffs and debating the structure of the = protocol. Any protocol reuse, experience, etc will be critical at this = point to make the correct choices and I look to MANET, ROLL, MEXT, = 6LOWPAN and other IETF'ers with routing protocol experience to = contribute. This is an industry important juncture and moving LPLN to IP = is a critical change.

I am looking to the WG = chairs to declare loose consensus on the documents  (when = appropriate) so that the rechartering of the WG to enter the design = phase can occur. WIthout a doubt, the requirements as-is have defined = the boundary of the work effort and I believe it is clear what is the = difference between the = WGs.


HIH

= -DWard




On = Feb 3, 2009, at 7:14 AM, Thomas Heide Clausen wrote:

Dear JP, dear ADs, dear = WG,

(I Cc the other INT chair, as he's following = 6lowpan)

For the record, I am not arguing that = MANET protocols should be applied or be applicable -- as you seem to = suggest in your email. I believe that I have stated so = repeatedly.

I submit, = however, that as it is currently exposed, ROLL, MANET and 6LOW seem to = be operating within the same space -- to the untrained eye, in exactly = the same space. My position is that it would be very unfortunate = having one WG creating confusion on the applicability of the work of = itself and of other IETF wg's, by simple omission of suitable perimeter = definitions. 

In that sort of situation, the IETF needs to be = extra prudent to make sure to clearly spell out suitable perimeter = definitions prior to, or conjointly with, the first publication cycle. = In this case, before or with the survey I-D.


Thomas

On Feb 3, = 2009, at 1:19 PM, JP Vasseur wrote:

Dear = WG and ADs,

Two issues are raised here for = which we would appreciate ADs' point of view and feed-back from the WG. = Please see in line.


Dear = Thomas,

At the risk of repeating myself, I'd like to = make a few important statements before *hopefully* come to a closure = ;-)

-> As you know, many of the ROLL WG active = participants have been working quite hard to produce a detailed set of = requirements, discuss how to proceed on the protocol survey document, = and other ID are in the works.
-> We managed to get highly = experienced contributors in the field that have designed and = deployed solutions so they not only have an excellent expertise of the = requirements but also on solutions,
-> Yes we need to rush = out. Why ? Because proprietary or semi-closed non-IP solutions are being = deployed at a fairly large scale. I do not think that I have to convince = anybody on this list that this is the WRONG approach for a number of = reasons. The industry is asking for an IP solution = *now*.
-> No we do not want to re-invent the wheel (see = our presentation at the routing plenary in Chicago). Anything that = already exists MUST (rfc2119 ;-)) be used provided that it meets our = requirements. And if we can adapt an existing protocol, we are all for = it !
-> Yes these requirements are quite specifics and this is = precisely why ROLL has been formed, 4 application-specific routing = requirements have been produced (to reduce the scope). Even if at a = first sight, it looks very much similar to a MANET issue (and there ARE = similarities but also very different requirements), having to deal with = a highly static network of hundreds of thousands of battery operated = sleeping nodes with 4K of RAM is quite specific. Note that this is not a = random example, but an on-going non-IP deployed = network.

And to conclude on this introduction = ... after an outstanding progress on the WG during the first 6-8 months, = we have been slowed down dramatically for the last 2 months, thus it is = time to close and move on to quickly re-charter and start the protocol = work (hopefully as light as possible) to see IP-based solution deployed. = I know that we are on the same page, we just need to find a good = compromise on both "sides".

Nothing new so far, = let's move to a proposed resolution - See in = line,

On Feb 2, 2009, at 7:37 PM, = Thomas Heide Clausen wrote:

All,

I promised a review, and I apologize that = I wasn't able to do so before the weekend as originally = projected.

Other than some typos that Chris and others have = pointed out, I'll try to offer my understanding of the problem space and = suggest some ways of addressing my main concerns....

My first = main concern remain that it is not clear, still, how ROLL positions = itself with respect to MANET, 6LOW et. al, all of which appear to be = within the same space and within the IETF. This I-D sees ROLL as = presented with entirely new problems (the use of "novel" in the = abstract, the statement that "existing protocols were not designed with = these requirements in mind" seem to confirm this).

Looking at the =  requirements listed, including "low power, low bandwidth, low = footprint", these appear similar to those which are also brought forward = in e.g. MANET and 6LOW. Reading (quickly, I confess) the various = requirements documents  of the draft-ietf-roll series present = scenarios which are similar to those where MANETs are deployed, and are = thought deployed, as well.

I also note that many additional (and = unstated) characteristics between ROLL and e.g. MANET are the same: = mobile, wireless, fragility, auto-configuration, IP routing, = interface/link issues...

Arguing that, as does this I-D, despite = the above impression "ROLL is novel and different" invites asking "how, = exactly?" I think that this question is valid, and merits being = answered, before the evaluations in this I-D can be judged = fairly.

Note that I come from a MANET background, and so I = *could* interpret from the ROLL discussion that where MANETs may aim for = "low power, low bandwidth, ....", ROLL may be able to quantify these as = "below this firm threshold" -- i.e. as a sort of "extreme" or = "constrained" MANET.

This is a personal observation, I note, = which would allow me to comprehend how ROLL and MANET are positioned = relative to one another -- but one which neither this I-D nor the = requirements document spell out or quantify -- or, for that matter, = debunk.

I think it's critical to understand this, in order to = understand the need for a new protocol development. I think it is = important to document this understanding in something with more = persistency.

If what I suggest above makes sense as a way of = positioning ROLL and MANET relative to one another, I'd suggest = including something to this effect in the survey I-D, as this I-D is the = one making a *direct* reference to the applicability of MANET protocols = to ROLL.

If what I suggest doesn't make sense at all, then I'd be = happy to have it debunked and, hopefully, through that debunking a = positioning/description that does ring true with us all can be = produced?

My second main concern is, that I still think that the = choice of criteria is unfortunate (not the word, Phill has me convinced = on that front, but the actual criteria). Control cost is, by all means, = a rather meaningless criteria when taken in isolation. I've sketched a = "zero-control-cost" routing protocol (flood all data - say use SMF, also = a MANET protocol, and also a rather "mature" I-D and wg item) which = would score well on the control cost criteria, but would likely be an = extremely bad choice for delivering unicast data.

The metric = which matters, and which should matter to ROLL in particular, is "the = total cost of getting user data through the network, including control = cost necessary to set up paths" -- as we know, every packet sent and = received costs bandwidth, energy and cycles -- user data no different = from contro.

According to the criterions as set up by this I-D, a = protocol producing "longer than shortest paths" at the benefit of = slightly lower control cost would score better than a protocol producing = "shortest paths" with slightly higher control cost. This is not = hypothetical, btw., there are plenty of studies observing and reflecting = upon this regarding the different MANET protocols, in academic = literature -- and observed in real networks as well.

I note that = this trade-off (slightly longer paths for lower control cost) may be = perfectly fair, assuming that very low amounts of user data traffic = transit through the network. However, I do not see this assumption = mentioned as a justification for focusing on the control cost metric and = discarding the "path length" or the "total cost of getting user data = through the network".

I believe that either these assumptions = should be made explicit ("there's so little user data traffic in a ROLL = network that we do not care about shortest paths") or -- if these = assumptions do not hold, that the evaluation criteria are = incomplete.

I note that it's true that we can always add another = criteria ad infinitum, and that's CLEARLY not what we want to do. = However when I say "incomplete" in the above, I simply suggest that = based on what is presented one cannot draw conclusions based on the = evaluation criteria....or, worse, that one draws the wrong conclusions = based on the information = presented.

It is not easy to = answer each of your point without running the risk to start a debate = that will never end. You raised some excellent points that I agree with = and others that I firmly disagree with ... So let me try to make a few = observations:
1) As pointed out earlier, yes there are = similarities between MANET and ROLL. I do not see this as an = issue.
2) The aim of the protocol survey IS NOT to exclude = MANET protocols. As mentioned many times on the list, we *only* wanted = to show that existing protocols, with no change, could not be used in = LLNs. This has been clarified in the document as your request and it HAD = to be clarified.
3) We could have used two different = approaches for the survey:
- Look at all MUST from the = requirements documents
- Try to derive a subset of = necessary but not sufficient criteria, which the WG chose to do = (consensus). Yes this list is not perfect,
criteria = could be changed, removed or added but looked good enough with excellent = consensus until LC.
4) With regards to 6lowpan (I copy the = chair), I do not see any overlap at all. Please refer to their charter = and WG items. The only place that required clarification was the routing = requirements and I was personally opposed to it but this was adopted as = a 6lowpan WG item by consensus. We're are working together and = managed to sort this out. This document will be 6lowpan = specific.

What I want to avoid is an endless = discussion on the positioning of ROLL, MANET, 6lowpan and quite frankly = we could add other WGs to the list.

So what = is the bottom line ?

We just need to agree = on the fact that there is no existing protocol that meets the ROLL = requirements and move to the next step (re-chartering) to select one = (hopefully not two) routing protocols in light of the routing = requirement (NOT the protocol survey), which can either be an adapted = MANET protocol or a new protocol.

Now moving to = your proposed resolution.



So, in a nutshell, I suggest that we address = (i) the positioning issue and (ii) the criteria issue thus:

o Describe = as I proposed above if ROLL and MANETs position themselves as I
have = deducted. If my deduction is incorrect, then let's quickly iterate on = the list
= = as to understand how to do produce an alternative description. If = we can't do this,
then the conclusion can be that = "we do not know how ROLL and MANET position
= themselves wrt each other", and we could then state that = clearly?
= =
= = It *should* not be more than a couple of paragraphs worth of text = to add, I gather?


If you find a = way to word this, please feel free and I'd be happy to help but feel it = as necessary ... Any opinion from our RTG and INT ADs = ?

o To the = criteria, either of:

- Add the assumption that "user = data traffic is so low that path lengths do not
matter = nor does the cost of carrying user data = traffice"


The motivation = for selecting a longer path is not tied to the amount of traffic here = but the level of constraints. Note that this is also true for several = other technologies such as MPLS-TE. You may have large amount of traffic = and still require to follow a non-shortest path (constrained based = routing). This is detailed in several requirements IDs. Criticality of = data is of course different, thus the requirements for potentially = different data paths according to packet marking using = DSCP.

- Add a = criteria & evaluation of "path length"

- Add a = criteria & evaluation of "total cost for getting user data through = the network"


And we can = add many more but if the current protocol do not satisfy existing = requirements, isn't it sufficient to answer the question on whether one = can find an existing protocol?

This would make a large chunk of my concerns and = issues vanish, and allow correctly interpreting and evaluating the rest = of the document.

That said, = question for the WG. Who think that such criteria should be added to = move forward ? Please reply.



How does that sound as an approach = forward?


Thanks for = helping = out.

Cheers.

JP.
Cheers,

Thomas

On Jan 27, = 2009, at 1:00 AM, Internet-Drafts@ietf.org = wrote:

A New Internet-Draft is = available from the on-line Internet-Drafts
directories.
This = draft is a work item of the Routing Over Low power and Lossy networks = Working Group of the IETF.

= Title = = : Overview of Existing Routing Protocols for Low Power and Lossy = Networks
= Author(s) = : A. Tavakoli, S. Dawson-Haggerty, P. = Levis
= Filename = : = draft-ietf-roll-protocols-survey-05.txt
= Pages = = : 26
Date : = 2009-1-26
=
Networks of low power = wireless devices introduce novel IP routing
  issues.  Low-power wireless devices, = such as sensors, actuators and
=   smart objects, have difficult constraints: very limited = memory,
  little = processing power, and long sleep periods.  As most of = these
  devices are = battery-powered, energy efficiency is = critically
=   important.  Wireless link qualities can vary = significantly over time,
=   requiring protocols to make agile decisions yet minimize = topology
  change = energy costs.  Routing over such low power and lossy = networks
  has = novel requirements that existing protocols may not address. =  This
=   document provides a brief survey of the strengths and = weaknesses of
=   existing protocols with respect to this class of networks. =  =46rom this
=   survey it examines whether existing and mature IETF = protocols can be
=   used without modification in these networks, or whether = further work
  is = necessary.
  is = necessary.

A URL for this = Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-s= urvey-05.txt

Internet-Drafts = are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-d= rafts/

Below is the = data which will enable a MIME compliant mail = reader
implementation to = automatically retrieve the ASCII version of = the
Internet-Draft.
Content-Type: text/plain
Content-ID: <2009-1-26155804.I-D@ietf.org<= /a>>

_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

_____________________________= __________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll



_______________________________________________
Rol= l mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-126--158132702-- From pister@eecs.berkeley.edu Tue Feb 3 14:20:56 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E11E28C1B0 for ; Tue, 3 Feb 2009 14:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JemR35vUezo for ; Tue, 3 Feb 2009 14:20:55 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 0028A28C1A1 for ; Tue, 3 Feb 2009 14:20:54 -0800 (PST) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n13MKWgV007217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Feb 2009 14:20:33 -0800 (PST) Message-ID: <4988C32B.6020702@eecs.berkeley.edu> Date: Tue, 03 Feb 2009 14:20:27 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Alexandru Petrescu References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <4987899C.3090708@gmail.com> <7C6DC187-681B-48DF-AFF1-FE329EA93CA8@cisco.com> <49885744.3050603@gmail.com> <49885C71.7090009@gmail.com> <4988A348.8030506@eecs.berkeley.edu> <4988B152.3030409@gmail.com> In-Reply-To: <4988B152.3030409@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] link-layers for ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 22:20:56 -0000 Alexandru Petrescu wrote: > Kris Pister a écrit : >> excellent questions, Alex. No doubt there will be many low power and >> lossy DLLs for us to route over in the future, but there are several >> that are of immediate commercial interest. 802.15.4 is a good place >> to start as an example. There are at least a half-dozen different >> deeply-duty-cycled DLLs that have been demonstrated for 15.4 radios. >> All of them allow for a tradeoff between power consumption and useful >> bandwidth, typically over a range of at least three orders of >> magnitude. I'd like to make sure that whichever routing protocol we >> use (find? create? you tell me) that it can make intelligent use of >> the DLL. It's really easy to build a network that runs everything at >> 1% duty cycle, but it turns out to give lousy performance in a lot of >> commercially relevant scenarios. >> >> So in my opinion, our work won't be done until we have a routing >> protocol that has some mechanism to >> 1) be aware of the currently configured capabilities of the DLL , and >> the limits of configuration (e.g. I can handle 1 packet/sec right >> now, and up to 10 packets/sec if you need me to) >> 2) be able to configure those capabilities based on the routing >> decisions >> >> I'm not hung up on this being in the routing protocol itself. If you >> tell me that the right way to do it is through some other existing >> xyz-TE protocol that is independent of the routing protocol, that's >> fine. But I'm convinced that the variable power/throughput >> capabilities of RoLL DLLs is one of the fundamental differences that >> makes routing "interesting" in these networks. > > Trying to identify to what extent the interesting part is already > addressed at link-layer... > > A link with its own routing (isa100.11a) talks to another link with > its own other link routing (zigbee) through an IP router. This > wouldn't run any routing protocol, because the link-layer routing is > enough. That would require protocol translation at the router. 6LoWPAN with the mesh under option might be a better example. Companies X, Y, and Z can all build 4944-compliant networks that will form multi-hop meshes internally, but present it all as a single IP link. > > I'm not sure I understand how variable power/throughput capabilities > of RoLL DLLs make IP routing interesting for these networks. You aren't alone. :) At this point, if there's group consensus it's probably that I'm wrong. It's incumbent on me to explain why I think that this is true, or to learn enough from the group to understand why it's not. Assuming that we recharter, I'll get started on that effort. ksjp > > Alex > From jvasseur@cisco.com Tue Feb 3 14:26:32 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5D0F3A6C05 for ; Tue, 3 Feb 2009 14:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.204 X-Spam-Level: X-Spam-Status: No, score=-10.204 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxWnH3A83lXs for ; Tue, 3 Feb 2009 14:26:32 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 6DFE33A66B4 for ; Tue, 3 Feb 2009 14:26:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,374,1231113600"; d="scan'208,217";a="32757843" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2009 22:26:10 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n13MQAnq009671; Tue, 3 Feb 2009 23:26:10 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n13MQ9pJ003987; Tue, 3 Feb 2009 22:26:09 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 23:26:09 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 23:26:08 +0100 Message-Id: From: JP Vasseur To: ROLL WG , Thomas Heide Clausen , Alexandru Petrescu , Emmanuel Baccelli , Kris Pister In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-126--158132702 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Feb 2009 23:20:21 +0100 References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <7F8459D1-3464-435A-AF8F-F9C437036FDF@cisco.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Feb 2009 22:26:08.0846 (UTC) FILETIME=[6944D6E0:01C9864E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=53129; t=1233699970; x=1234563970; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20If=20possible=20... |Sender:=20; bh=ewfHz1EKPyUmbbqurSK9mkec/2t5h71UGc07HEPXyp4=; b=KFlupImdUCbu5zV3mKpBTZwNqkWI0d8/0spcy5ccfiS/CQZn2XVaVE6YIn JSrMdxdUeSbP30/n9lrLKiWmheXyr7pvXCq4cEwDuvglHkxVw3mE4ISOdHOj jpXrrLYFsx; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Ross Callon Subject: [Roll] If possible ... X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 22:26:33 -0000 --Apple-Mail-126--158132702 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear all, Great to see all these discussions, but in light of the discussions today I would like to *converge* - I did propose a plan (below). Until we have concluded on the protocol survey (we're close) and re- chartering (coming soon), can we focus the discussion, it goes in all directions. Many Thanks. JP. On Feb 3, 2009, at 6:36 PM, JP Vasseur wrote: > Thanks Dave for AD's feed-back. > > We *are* making progress and looking at all the interest that we are > gathering from many participants, this is a good sign of strong > participation for the next phase, a key of success. > > First of all, I would like to remind that all the routing > requirements documents are finalized. I asked for a last revision of > the building routing requirements documents before publication > request. And then we will be done for this part. Lot of work. > > Here is what I propose: > > 1) I guess that things have been clarified on the WG positioning > issue. > 2) Many supportive request to close on this and move forward. > 3) Still there are a few requests that have been made by Thomas, > Alex, ... that we should try to address. > May I ask you to try to limit as much as possible your request and > we will do everything possible to address them. > 4) End of this week, we will close on the protocol survey. > 5) Right after we'll propose you a new charter (one week discussion) > before IESG submission. > 6) If/once re-chartered, we count on everybody's help to continue > the good work. > > Thanks. > > JP. > > > On Feb 3, 2009, at 5:52 PM, David Ward wrote: > >> All - >> >> We debated the delta between these three WGs when chartering ROLL >> for a considerable period of time. I do not want to revisit that >> debate but, I will quickly summarize here >> >> - 6LOWPAN is not working at the IP layer so, the overlap here is >> really not an issue. >> - MANET is and has been working on routing protocols for mobile, ad >> hoc networks with specific requirements and use cases. Some of >> those use cases may or may not overlap with ROLL. There will be >> lessons to be learned but, the primary use cases being worked on >> appeared by all the chairs and ADs involved to be different enough >> to warrant a new WG in this area. >> - ROLL was originally chartered to write the requirements and >> evaluate existing protocols for low power, lossy networks running >> over IP (some call these "sensor networks"). ROLL is only >> chartered to work on the routing protocol portion. Not the >> transport, encap or other topics at this time. Also note that >> mobility is not under consideration at this time. >> >> ROLL WG appears to have come to consensus on the requirement docs >> that state specific functions, attributes, power/memory envelope >> and algorithmic considerations that must be "in the routing >> protocol" for these networks. The survey ID (which is of course a >> snapshot at one point in time) puts some bounds on mapping the >> required functions, attributes and other considerations into >> protocols available *today.* >> >> Given the real work of designing a protocol hasn't begun by the >> ROLL WG participants; holding up the WG to begin taking what they >> currently defined as a very complex, multivariate problem and begin >> whittling it down to something solvable via theoretical and >> hypothetical exercises seems like an unwise use of time given the >> experience and energy of the WG in this problem space. The WG must >> move beyond the moderately high-level boundary setting exercise >> (which I believe there is consensus) and move onto the more >> challenging work of defining the objects, algorithms, semantics, >> state machines and functionality of the protocol. In the design >> phase (vs the survey phase) a better evaluation can be made of the >> ease or difficulty of "from scratch" or "modify what we have" can >> be made. I expect "wild swings" of the design pattern of the >> protocol during the first year of the design effort. I attempted to >> make this clear at the mic in Minneapolis that the current >> trajectory is very complex problem domain that hasn't born a lot of >> fruit but, that in the design phase reducing the complexity must >> occur. Members of the WG who have vast experience in these types of >> networks and have widely deployed products have stated that the >> routing protocol issues are solvable problems with some simplifying >> assumptions. I look forward to the WG making these design decisions >> and tradeoffs and debating the structure of the protocol. Any >> protocol reuse, experience, etc will be critical at this point to >> make the correct choices and I look to MANET, ROLL, MEXT, 6LOWPAN >> and other IETF'ers with routing protocol experience to contribute. >> This is an industry important juncture and moving LPLN to IP is a >> critical change. >> >> I am looking to the WG chairs to declare loose consensus on the >> documents (when appropriate) so that the rechartering of the WG to >> enter the design phase can occur. WIthout a doubt, the requirements >> as-is have defined the boundary of the work effort and I believe it >> is clear what is the difference between the WGs. >> >> >> HIH >> >> -DWard >> >> >> >> >> On Feb 3, 2009, at 7:14 AM, Thomas Heide Clausen wrote: >> >>> Dear JP, dear ADs, dear WG, >>> >>> (I Cc the other INT chair, as he's following 6lowpan) >>> >>> For the record, I am not arguing that MANET protocols should be >>> applied or be applicable -- as you seem to suggest in your email. >>> I believe that I have stated so repeatedly. >>> >>> I submit, however, that as it is currently exposed, ROLL, MANET >>> and 6LOW seem to be operating within the same space -- to the >>> untrained eye, in exactly the same space. My position is that it >>> would be very unfortunate having one WG creating confusion on the >>> applicability of the work of itself and of other IETF wg's, by >>> simple omission of suitable perimeter definitions. >>> >>> In that sort of situation, the IETF needs to be extra prudent to >>> make sure to clearly spell out suitable perimeter definitions >>> prior to, or conjointly with, the first publication cycle. In this >>> case, before or with the survey I-D. >>> >>> Sincerely, >>> >>> Thomas >>> >>> >>> On Feb 3, 2009, at 1:19 PM, JP Vasseur wrote: >>> >>>> Dear WG and ADs, >>>> >>>> Two issues are raised here for which we would appreciate ADs' >>>> point of view and feed-back from the WG. Please see in line. >>>> >>>> >>>> Dear Thomas, >>>> >>>> At the risk of repeating myself, I'd like to make a few important >>>> statements before *hopefully* come to a closure ;-) >>>> >>>> -> As you know, many of the ROLL WG active participants have been >>>> working quite hard to produce a detailed set of requirements, >>>> discuss how to proceed on the protocol survey document, and other >>>> ID are in the works. >>>> -> We managed to get highly experienced contributors in the field >>>> that have designed and deployed solutions so they not only have >>>> an excellent expertise of the requirements but also on solutions, >>>> -> Yes we need to rush out. Why ? Because proprietary or semi- >>>> closed non-IP solutions are being deployed at a fairly large >>>> scale. I do not think that I have to convince anybody on this >>>> list that this is the WRONG approach for a number of reasons. The >>>> industry is asking for an IP solution *now*. >>>> -> No we do not want to re-invent the wheel (see our presentation >>>> at the routing plenary in Chicago). Anything that already exists >>>> MUST (rfc2119 ;-)) be used provided that it meets our >>>> requirements. And if we can adapt an existing protocol, we are >>>> all for it ! >>>> -> Yes these requirements are quite specifics and this is >>>> precisely why ROLL has been formed, 4 application-specific >>>> routing requirements have been produced (to reduce the scope). >>>> Even if at a first sight, it looks very much similar to a MANET >>>> issue (and there ARE similarities but also very different >>>> requirements), having to deal with a highly static network of >>>> hundreds of thousands of battery operated sleeping nodes with 4K >>>> of RAM is quite specific. Note that this is not a random example, >>>> but an on-going non-IP deployed network. >>>> >>>> And to conclude on this introduction ... after an outstanding >>>> progress on the WG during the first 6-8 months, we have been >>>> slowed down dramatically for the last 2 months, thus it is time >>>> to close and move on to quickly re-charter and start the protocol >>>> work (hopefully as light as possible) to see IP-based solution >>>> deployed. I know that we are on the same page, we just need to >>>> find a good compromise on both "sides". >>>> >>>> Nothing new so far, let's move to a proposed resolution - See in >>>> line, >>>> >>>> On Feb 2, 2009, at 7:37 PM, Thomas Heide Clausen wrote: >>>> >>>>> All, >>>>> >>>>> I promised a review, and I apologize that I wasn't able to do so >>>>> before the weekend as originally projected. >>>>> >>>>> Other than some typos that Chris and others have pointed out, >>>>> I'll try to offer my understanding of the problem space and >>>>> suggest some ways of addressing my main concerns.... >>>>> >>>>> My first main concern remain that it is not clear, still, how >>>>> ROLL positions itself with respect to MANET, 6LOW et. al, all of >>>>> which appear to be within the same space and within the IETF. >>>>> This I-D sees ROLL as presented with entirely new problems (the >>>>> use of "novel" in the abstract, the statement that "existing >>>>> protocols were not designed with these requirements in mind" >>>>> seem to confirm this). >>>>> >>>>> Looking at the requirements listed, including "low power, low >>>>> bandwidth, low footprint", these appear similar to those which >>>>> are also brought forward in e.g. MANET and 6LOW. Reading >>>>> (quickly, I confess) the various requirements documents of the >>>>> draft-ietf-roll series present scenarios which are similar to >>>>> those where MANETs are deployed, and are thought deployed, as >>>>> well. >>>>> >>>>> I also note that many additional (and unstated) characteristics >>>>> between ROLL and e.g. MANET are the same: mobile, wireless, >>>>> fragility, auto-configuration, IP routing, interface/link >>>>> issues... >>>>> >>>>> Arguing that, as does this I-D, despite the above impression >>>>> "ROLL is novel and different" invites asking "how, exactly?" I >>>>> think that this question is valid, and merits being answered, >>>>> before the evaluations in this I-D can be judged fairly. >>>>> >>>>> Note that I come from a MANET background, and so I *could* >>>>> interpret from the ROLL discussion that where MANETs may aim for >>>>> "low power, low bandwidth, ....", ROLL may be able to quantify >>>>> these as "below this firm threshold" -- i.e. as a sort of >>>>> "extreme" or "constrained" MANET. >>>>> >>>>> This is a personal observation, I note, which would allow me to >>>>> comprehend how ROLL and MANET are positioned relative to one >>>>> another -- but one which neither this I-D nor the requirements >>>>> document spell out or quantify -- or, for that matter, debunk. >>>>> >>>>> I think it's critical to understand this, in order to understand >>>>> the need for a new protocol development. I think it is important >>>>> to document this understanding in something with more persistency. >>>>> >>>>> If what I suggest above makes sense as a way of positioning ROLL >>>>> and MANET relative to one another, I'd suggest including >>>>> something to this effect in the survey I-D, as this I-D is the >>>>> one making a *direct* reference to the applicability of MANET >>>>> protocols to ROLL. >>>>> >>>>> If what I suggest doesn't make sense at all, then I'd be happy >>>>> to have it debunked and, hopefully, through that debunking a >>>>> positioning/description that does ring true with us all can be >>>>> produced? >>>>> >>>>> My second main concern is, that I still think that the choice of >>>>> criteria is unfortunate (not the word, Phill has me convinced on >>>>> that front, but the actual criteria). Control cost is, by all >>>>> means, a rather meaningless criteria when taken in isolation. >>>>> I've sketched a "zero-control-cost" routing protocol (flood all >>>>> data - say use SMF, also a MANET protocol, and also a rather >>>>> "mature" I-D and wg item) which would score well on the control >>>>> cost criteria, but would likely be an extremely bad choice for >>>>> delivering unicast data. >>>>> >>>>> The metric which matters, and which should matter to ROLL in >>>>> particular, is "the total cost of getting user data through the >>>>> network, including control cost necessary to set up paths" -- as >>>>> we know, every packet sent and received costs bandwidth, energy >>>>> and cycles -- user data no different from contro. >>>>> >>>>> According to the criterions as set up by this I-D, a protocol >>>>> producing "longer than shortest paths" at the benefit of >>>>> slightly lower control cost would score better than a protocol >>>>> producing "shortest paths" with slightly higher control cost. >>>>> This is not hypothetical, btw., there are plenty of studies >>>>> observing and reflecting upon this regarding the different MANET >>>>> protocols, in academic literature -- and observed in real >>>>> networks as well. >>>>> >>>>> I note that this trade-off (slightly longer paths for lower >>>>> control cost) may be perfectly fair, assuming that very low >>>>> amounts of user data traffic transit through the network. >>>>> However, I do not see this assumption mentioned as a >>>>> justification for focusing on the control cost metric and >>>>> discarding the "path length" or the "total cost of getting user >>>>> data through the network". >>>>> >>>>> I believe that either these assumptions should be made explicit >>>>> ("there's so little user data traffic in a ROLL network that we >>>>> do not care about shortest paths") or -- if these assumptions do >>>>> not hold, that the evaluation criteria are incomplete. >>>>> >>>>> I note that it's true that we can always add another criteria ad >>>>> infinitum, and that's CLEARLY not what we want to do. However >>>>> when I say "incomplete" in the above, I simply suggest that >>>>> based on what is presented one cannot draw conclusions based on >>>>> the evaluation criteria....or, worse, that one draws the wrong >>>>> conclusions based on the information presented. >>>> >>>> It is not easy to answer each of your point without running the >>>> risk to start a debate that will never end. You raised some >>>> excellent points that I agree with and others that I firmly >>>> disagree with ... So let me try to make a few observations: >>>> 1) As pointed out earlier, yes there are similarities between >>>> MANET and ROLL. I do not see this as an issue. >>>> 2) The aim of the protocol survey IS NOT to exclude MANET >>>> protocols. As mentioned many times on the list, we *only* wanted >>>> to show that existing protocols, with no change, could not be >>>> used in LLNs. This has been clarified in the document as your >>>> request and it HAD to be clarified. >>>> 3) We could have used two different approaches for the survey: >>>> - Look at all MUST from the requirements documents >>>> - Try to derive a subset of necessary but not sufficient >>>> criteria, which the WG chose to do (consensus). Yes this list is >>>> not perfect, >>>> criteria could be changed, removed or added but looked good >>>> enough with excellent consensus until LC. >>>> 4) With regards to 6lowpan (I copy the chair), I do not see any >>>> overlap at all. Please refer to their charter and WG items. The >>>> only place that required clarification was the routing >>>> requirements and I was personally opposed to it but this was >>>> adopted as a 6lowpan WG item by consensus. We're are working >>>> together and managed to sort this out. This document will be >>>> 6lowpan specific. >>>> >>>> What I want to avoid is an endless discussion on the positioning >>>> of ROLL, MANET, 6lowpan and quite frankly we could add other WGs >>>> to the list. >>>> >>>> So what is the bottom line ? >>>> >>>> We just need to agree on the fact that there is no existing >>>> protocol that meets the ROLL requirements and move to the next >>>> step (re-chartering) to select one (hopefully not two) routing >>>> protocols in light of the routing requirement (NOT the protocol >>>> survey), which can either be an adapted MANET protocol or a new >>>> protocol. >>>> >>>> Now moving to your proposed resolution. >>>> >>>>> >>>>> >>>>> So, in a nutshell, I suggest that we address (i) the positioning >>>>> issue and (ii) the criteria issue thus: >>>>> >>>>> o Describe as I proposed above if ROLL and MANETs position >>>>> themselves as I >>>>> have deducted. If my deduction is incorrect, then let's >>>>> quickly iterate on the list >>>>> as to understand how to do produce an alternative description. >>>>> If we can't do this, >>>>> then the conclusion can be that "we do not know how ROLL and >>>>> MANET position >>>>> themselves wrt each other", and we could then state that >>>>> clearly? >>>>> >>>>> It *should* not be more than a couple of paragraphs worth of >>>>> text to add, I gather? >>>>> >>>> >>>> If you find a way to word this, please feel free and I'd be happy >>>> to help but feel it as necessary ... Any opinion from our RTG and >>>> INT ADs ? >>>> >>>>> o To the criteria, either of: >>>>> >>>>> - Add the assumption that "user data traffic is so low that >>>>> path lengths do not >>>>> matter nor does the cost of carrying user data traffice" >>>>> >>>> >>>> The motivation for selecting a longer path is not tied to the >>>> amount of traffic here but the level of constraints. Note that >>>> this is also true for several other technologies such as MPLS-TE. >>>> You may have large amount of traffic and still require to follow >>>> a non-shortest path (constrained based routing). This is detailed >>>> in several requirements IDs. Criticality of data is of course >>>> different, thus the requirements for potentially different data >>>> paths according to packet marking using DSCP. >>>> >>>>> - Add a criteria & evaluation of "path length" >>>>> >>>>> - Add a criteria & evaluation of "total cost for getting user >>>>> data through the network" >>>>> >>>> >>>> And we can add many more but if the current protocol do not >>>> satisfy existing requirements, isn't it sufficient to answer the >>>> question on whether one can find an existing protocol? >>>> >>>>> This would make a large chunk of my concerns and issues vanish, >>>>> and allow correctly interpreting and evaluating the rest of the >>>>> document. >>>> >>>> That said, question for the WG. Who think that such criteria >>>> should be added to move forward ? Please reply. >>>> >>>>> >>>>> >>>>> How does that sound as an approach forward? >>>>> >>>> >>>> Thanks for helping out. >>>> >>>> Cheers. >>>> >>>> JP. >>>> >>>>> Cheers, >>>>> >>>>> Thomas >>>>> >>>>> On Jan 27, 2009, at 1:00 AM, Internet-Drafts@ietf.org wrote: >>>>> >>>>>> A New Internet-Draft is available from the on-line Internet- >>>>>> Drafts >>>>>> directories. >>>>>> This draft is a work item of the Routing Over Low power and >>>>>> Lossy networks Working Group of the IETF. >>>>>> >>>>>> Title : Overview of Existing Routing Protocols for Low Power >>>>>> and Lossy Networks >>>>>> Author(s) : A. Tavakoli, S. Dawson-Haggerty, P. Levis >>>>>> Filename : draft-ietf-roll-protocols-survey-05.txt >>>>>> Pages : 26 >>>>>> Date : 2009-1-26 >>>>>> >>>>>> Networks of low power wireless devices introduce novel IP routing >>>>>> issues. Low-power wireless devices, such as sensors, >>>>>> actuators and >>>>>> smart objects, have difficult constraints: very limited memory, >>>>>> little processing power, and long sleep periods. As most of >>>>>> these >>>>>> devices are battery-powered, energy efficiency is critically >>>>>> important. Wireless link qualities can vary significantly >>>>>> over time, >>>>>> requiring protocols to make agile decisions yet minimize >>>>>> topology >>>>>> change energy costs. Routing over such low power and lossy >>>>>> networks >>>>>> has novel requirements that existing protocols may not >>>>>> address. This >>>>>> document provides a brief survey of the strengths and >>>>>> weaknesses of >>>>>> existing protocols with respect to this class of networks. >>>>>> From this >>>>>> survey it examines whether existing and mature IETF protocols >>>>>> can be >>>>>> used without modification in these networks, or whether >>>>>> further work >>>>>> is necessary. >>>>>> is necessary. >>>>>> >>>>>> A URL for this Internet-Draft is: >>>>>> http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-survey-05.txt >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> Below is the data which will enable a MIME compliant mail reader >>>>>> implementation to automatically retrieve the ASCII version of the >>>>>> Internet-Draft. >>>>>> Content-Type: text/plain >>>>>> Content-ID: <2009-1-26155804.I-D@ietf.org> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-126--158132702 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Dear all,

Great to see all these = discussions, but in light of the discussions today I would like to = *converge* - I did propose a plan (below). Until we have concluded on = the protocol survey (we're close) and re-chartering (coming soon), can = we focus the discussion, it goes in all = directions.

Many = Thanks.

JP.

O= n Feb 3, 2009, at 6:36 PM, JP Vasseur wrote:

Thanks Dave for AD's = feed-back.

We *are* making progress and looking at = all the interest that we are gathering from many participants, this is a = good sign of strong participation for the next phase, a key of = success.

First of all, I would like to remind = that all the routing requirements documents are finalized. I asked for a = last revision of the building routing requirements documents before = publication request. And then we will be done for this part. Lot of = work.

Here is what I = propose:

1) I guess that things have been = clarified on the WG positioning issue.
2) Many supportive = request to close on this and move forward.
3) Still there = are a few requests that have been made by Thomas, Alex, ... that we = should try to address.
May I ask you to try to limit as = much as possible your request and we will do everything possible to = address them.
4) End of this week, we will close on the = protocol survey.
5) Right after we'll propose you a new = charter (one week discussion) before IESG submission.
6) = If/once re-chartered, we count on everybody's help to continue the good = work.

Thanks.

JP.
<= div>

On Feb 3, 2009, at 5:52 PM, David = Ward wrote:

All = -

We debated the delta between these three WGs = when chartering ROLL for a considerable period of time. I do not want to = revisit that debate but, I will quickly summarize = here

- 6LOWPAN is not working at the IP layer = so, the overlap here is really not an issue.
- MANET is and = has been working on routing protocols for mobile, ad hoc networks with = specific requirements and use cases. Some of those use cases may or may = not overlap with ROLL. There will be lessons to be learned but, the = primary use cases being worked on appeared by all the chairs and ADs = involved to be different enough to warrant a new WG in this = area.
- ROLL was originally chartered to write the = requirements and evaluate existing protocols for low power, lossy = networks running over IP (some call these  "sensor networks"). ROLL = is only chartered to work on the routing protocol portion. Not the = transport, encap or other topics at this time. Also note that mobility = is not under consideration at this time.

ROLL = WG appears to have come to consensus on the requirement docs that state = specific functions, attributes, power/memory envelope and algorithmic = considerations that must be "in the routing protocol" for these = networks. The survey ID (which is of course a snapshot at one point in = time) puts some bounds on mapping the required functions, attributes and = other considerations into protocols available = *today.*

Given the real work of designing a = protocol hasn't begun by the ROLL WG participants; holding up the WG to = begin taking what they currently defined as a very complex, multivariate = problem and begin whittling it down to something solvable via = theoretical and hypothetical exercises seems like an unwise use of time = given the experience and energy of the WG in this problem space. =  The WG must move beyond the moderately high-level boundary setting = exercise (which I believe there is consensus) and move onto the more = challenging work of defining the objects, algorithms, semantics, state = machines and functionality of the protocol.  In the design phase = (vs the survey phase) a better evaluation can be made of the ease or = difficulty of "from scratch" or "modify what we have" can be made. I = expect "wild swings" of the design pattern of the protocol during the = first year of the design effort. I attempted to make this clear at the = mic in Minneapolis that the current trajectory is very complex problem = domain that hasn't born a lot of fruit but, that in the design phase = reducing the complexity must occur. Members of the WG who have vast = experience in these types of networks and have widely deployed products = have stated that the routing protocol issues are solvable problems with = some simplifying assumptions. I look forward to the WG making these = design decisions and tradeoffs and debating the structure of the = protocol. Any protocol reuse, experience, etc will be critical at this = point to make the correct choices and I look to MANET, ROLL, MEXT, = 6LOWPAN and other IETF'ers with routing protocol experience to = contribute. This is an industry important juncture and moving LPLN to IP = is a critical change.

I am looking to the WG = chairs to declare loose consensus on the documents  (when = appropriate) so that the rechartering of the WG to enter the design = phase can occur. WIthout a doubt, the requirements as-is have defined = the boundary of the work effort and I believe it is clear what is the = difference between the = WGs.


HIH

= -DWard




On = Feb 3, 2009, at 7:14 AM, Thomas Heide Clausen wrote:

Dear JP, dear ADs, dear = WG,

(I Cc the other INT chair, as he's following = 6lowpan)

For the record, I am not arguing that = MANET protocols should be applied or be applicable -- as you seem to = suggest in your email. I believe that I have stated so = repeatedly.

I submit, = however, that as it is currently exposed, ROLL, MANET and 6LOW seem to = be operating within the same space -- to the untrained eye, in exactly = the same space. My position is that it would be very unfortunate = having one WG creating confusion on the applicability of the work of = itself and of other IETF wg's, by simple omission of suitable perimeter = definitions. 

In that sort of situation, the IETF needs to be = extra prudent to make sure to clearly spell out suitable perimeter = definitions prior to, or conjointly with, the first publication cycle. = In this case, before or with the survey I-D.


Thomas

On Feb 3, = 2009, at 1:19 PM, JP Vasseur wrote:

Dear = WG and ADs,

Two issues are raised here for = which we would appreciate ADs' point of view and feed-back from the WG. = Please see in line.


Dear = Thomas,

At the risk of repeating myself, I'd like to = make a few important statements before *hopefully* come to a closure = ;-)

-> As you know, many of the ROLL WG active = participants have been working quite hard to produce a detailed set of = requirements, discuss how to proceed on the protocol survey document, = and other ID are in the works.
-> We managed to get highly = experienced contributors in the field that have designed and = deployed solutions so they not only have an excellent expertise of the = requirements but also on solutions,
-> Yes we need to rush = out. Why ? Because proprietary or semi-closed non-IP solutions are being = deployed at a fairly large scale. I do not think that I have to convince = anybody on this list that this is the WRONG approach for a number of = reasons. The industry is asking for an IP solution = *now*.
-> No we do not want to re-invent the wheel (see = our presentation at the routing plenary in Chicago). Anything that = already exists MUST (rfc2119 ;-)) be used provided that it meets our = requirements. And if we can adapt an existing protocol, we are all for = it !
-> Yes these requirements are quite specifics and this is = precisely why ROLL has been formed, 4 application-specific routing = requirements have been produced (to reduce the scope). Even if at a = first sight, it looks very much similar to a MANET issue (and there ARE = similarities but also very different requirements), having to deal with = a highly static network of hundreds of thousands of battery operated = sleeping nodes with 4K of RAM is quite specific. Note that this is not a = random example, but an on-going non-IP deployed = network.

And to conclude on this introduction = ... after an outstanding progress on the WG during the first 6-8 months, = we have been slowed down dramatically for the last 2 months, thus it is = time to close and move on to quickly re-charter and start the protocol = work (hopefully as light as possible) to see IP-based solution deployed. = I know that we are on the same page, we just need to find a good = compromise on both "sides".

Nothing new so far, = let's move to a proposed resolution - See in = line,

On Feb 2, 2009, at 7:37 PM, = Thomas Heide Clausen wrote:

All,

I promised a review, and I apologize that = I wasn't able to do so before the weekend as originally = projected.

Other than some typos that Chris and others have = pointed out, I'll try to offer my understanding of the problem space and = suggest some ways of addressing my main concerns....

My first = main concern remain that it is not clear, still, how ROLL positions = itself with respect to MANET, 6LOW et. al, all of which appear to be = within the same space and within the IETF. This I-D sees ROLL as = presented with entirely new problems (the use of "novel" in the = abstract, the statement that "existing protocols were not designed with = these requirements in mind" seem to confirm this).

Looking at the =  requirements listed, including "low power, low bandwidth, low = footprint", these appear similar to those which are also brought forward = in e.g. MANET and 6LOW. Reading (quickly, I confess) the various = requirements documents  of the draft-ietf-roll series present = scenarios which are similar to those where MANETs are deployed, and are = thought deployed, as well.

I also note that many additional (and = unstated) characteristics between ROLL and e.g. MANET are the same: = mobile, wireless, fragility, auto-configuration, IP routing, = interface/link issues...

Arguing that, as does this I-D, despite = the above impression "ROLL is novel and different" invites asking "how, = exactly?" I think that this question is valid, and merits being = answered, before the evaluations in this I-D can be judged = fairly.

Note that I come from a MANET background, and so I = *could* interpret from the ROLL discussion that where MANETs may aim for = "low power, low bandwidth, ....", ROLL may be able to quantify these as = "below this firm threshold" -- i.e. as a sort of "extreme" or = "constrained" MANET.

This is a personal observation, I note, = which would allow me to comprehend how ROLL and MANET are positioned = relative to one another -- but one which neither this I-D nor the = requirements document spell out or quantify -- or, for that matter, = debunk.

I think it's critical to understand this, in order to = understand the need for a new protocol development. I think it is = important to document this understanding in something with more = persistency.

If what I suggest above makes sense as a way of = positioning ROLL and MANET relative to one another, I'd suggest = including something to this effect in the survey I-D, as this I-D is the = one making a *direct* reference to the applicability of MANET protocols = to ROLL.

If what I suggest doesn't make sense at all, then I'd be = happy to have it debunked and, hopefully, through that debunking a = positioning/description that does ring true with us all can be = produced?

My second main concern is, that I still think that the = choice of criteria is unfortunate (not the word, Phill has me convinced = on that front, but the actual criteria). Control cost is, by all means, = a rather meaningless criteria when taken in isolation. I've sketched a = "zero-control-cost" routing protocol (flood all data - say use SMF, also = a MANET protocol, and also a rather "mature" I-D and wg item) which = would score well on the control cost criteria, but would likely be an = extremely bad choice for delivering unicast data.

The metric = which matters, and which should matter to ROLL in particular, is "the = total cost of getting user data through the network, including control = cost necessary to set up paths" -- as we know, every packet sent and = received costs bandwidth, energy and cycles -- user data no different = from contro.

According to the criterions as set up by this I-D, a = protocol producing "longer than shortest paths" at the benefit of = slightly lower control cost would score better than a protocol producing = "shortest paths" with slightly higher control cost. This is not = hypothetical, btw., there are plenty of studies observing and reflecting = upon this regarding the different MANET protocols, in academic = literature -- and observed in real networks as well.

I note that = this trade-off (slightly longer paths for lower control cost) may be = perfectly fair, assuming that very low amounts of user data traffic = transit through the network. However, I do not see this assumption = mentioned as a justification for focusing on the control cost metric and = discarding the "path length" or the "total cost of getting user data = through the network".

I believe that either these assumptions = should be made explicit ("there's so little user data traffic in a ROLL = network that we do not care about shortest paths") or -- if these = assumptions do not hold, that the evaluation criteria are = incomplete.

I note that it's true that we can always add another = criteria ad infinitum, and that's CLEARLY not what we want to do. = However when I say "incomplete" in the above, I simply suggest that = based on what is presented one cannot draw conclusions based on the = evaluation criteria....or, worse, that one draws the wrong conclusions = based on the information = presented.

It is not easy to = answer each of your point without running the risk to start a debate = that will never end. You raised some excellent points that I agree with = and others that I firmly disagree with ... So let me try to make a few = observations:
1) As pointed out earlier, yes there are = similarities between MANET and ROLL. I do not see this as an = issue.
2) The aim of the protocol survey IS NOT to exclude = MANET protocols. As mentioned many times on the list, we *only* wanted = to show that existing protocols, with no change, could not be used in = LLNs. This has been clarified in the document as your request and it HAD = to be clarified.
3) We could have used two different = approaches for the survey:
- Look at all MUST from the = requirements documents
- Try to derive a subset of = necessary but not sufficient criteria, which the WG chose to do = (consensus). Yes this list is not perfect,
criteria = could be changed, removed or added but looked good enough with excellent = consensus until LC.
4) With regards to 6lowpan (I copy the = chair), I do not see any overlap at all. Please refer to their charter = and WG items. The only place that required clarification was the routing = requirements and I was personally opposed to it but this was adopted as = a 6lowpan WG item by consensus. We're are working together and = managed to sort this out. This document will be 6lowpan = specific.

What I want to avoid is an endless = discussion on the positioning of ROLL, MANET, 6lowpan and quite frankly = we could add other WGs to the list.

So what = is the bottom line ?

We just need to agree = on the fact that there is no existing protocol that meets the ROLL = requirements and move to the next step (re-chartering) to select one = (hopefully not two) routing protocols in light of the routing = requirement (NOT the protocol survey), which can either be an adapted = MANET protocol or a new protocol.

Now moving to = your proposed resolution.



So, in a nutshell, I suggest that we address = (i) the positioning issue and (ii) the criteria issue thus:

o Describe = as I proposed above if ROLL and MANETs position themselves as I
have = deducted. If my deduction is incorrect, then let's quickly iterate on = the list
= = as to understand how to do produce an alternative description. If = we can't do this,
then the conclusion can be that = "we do not know how ROLL and MANET position
= themselves wrt each other", and we could then state that = clearly?
= =
= = It *should* not be more than a couple of paragraphs worth of text = to add, I gather?


If you find a = way to word this, please feel free and I'd be happy to help but feel it = as necessary ... Any opinion from our RTG and INT ADs = ?

o To the = criteria, either of:

- Add the assumption that "user = data traffic is so low that path lengths do not
matter = nor does the cost of carrying user data = traffice"


The motivation = for selecting a longer path is not tied to the amount of traffic here = but the level of constraints. Note that this is also true for several = other technologies such as MPLS-TE. You may have large amount of traffic = and still require to follow a non-shortest path (constrained based = routing). This is detailed in several requirements IDs. Criticality of = data is of course different, thus the requirements for potentially = different data paths according to packet marking using = DSCP.

- Add a = criteria & evaluation of "path length"

- Add a = criteria & evaluation of "total cost for getting user data through = the network"


And we can = add many more but if the current protocol do not satisfy existing = requirements, isn't it sufficient to answer the question on whether one = can find an existing protocol?

This would make a large chunk of my concerns and = issues vanish, and allow correctly interpreting and evaluating the rest = of the document.

That said, = question for the WG. Who think that such criteria should be added to = move forward ? Please reply.



How does that sound as an approach = forward?


Thanks for = helping = out.

Cheers.

JP.
Cheers,

Thomas

On Jan 27, = 2009, at 1:00 AM, Internet-Drafts@ietf.org = wrote:

A New Internet-Draft is = available from the on-line Internet-Drafts
directories.
This = draft is a work item of the Routing Over Low power and Lossy networks = Working Group of the IETF.

= Title = = : Overview of Existing Routing Protocols for Low Power and Lossy = Networks
= Author(s) = : A. Tavakoli, S. Dawson-Haggerty, P. = Levis
= Filename = : = draft-ietf-roll-protocols-survey-05.txt
= Pages = = : 26
Date : = 2009-1-26
=
Networks of low power = wireless devices introduce novel IP routing
  issues.  Low-power wireless devices, = such as sensors, actuators and
=   smart objects, have difficult constraints: very limited = memory,
  little = processing power, and long sleep periods.  As most of = these
  devices are = battery-powered, energy efficiency is = critically
=   important.  Wireless link qualities can vary = significantly over time,
=   requiring protocols to make agile decisions yet minimize = topology
  change = energy costs.  Routing over such low power and lossy = networks
  has = novel requirements that existing protocols may not address. =  This
=   document provides a brief survey of the strengths and = weaknesses of
=   existing protocols with respect to this class of networks. =  =46rom this
=   survey it examines whether existing and mature IETF = protocols can be
=   used without modification in these networks, or whether = further work
  is = necessary.
  is = necessary.

A URL for this = Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-s= urvey-05.txt

Internet-Drafts = are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-d= rafts/

Below is the = data which will enable a MIME compliant mail = reader
implementation to = automatically retrieve the ASCII version of = the
Internet-Draft.
Content-Type: text/plain
Content-ID: <2009-1-26155804.I-D@ietf.org<= /a>>

_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

_____________________________= __________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll



_______________________________________________
Rol= l mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-126--158132702-- From root@core3.amsl.com Tue Feb 3 14:30:01 2009 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7EC803A6904; Tue, 3 Feb 2009 14:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090203223001.7EC803A6904@core3.amsl.com> Date: Tue, 3 Feb 2009 14:30:01 -0800 (PST) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-building-routing-reqs-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 22:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Building Automation Routing Requirements in Low Power and Lossy Networks Author(s) : J. Martocci, et al. Filename : draft-ietf-roll-building-routing-reqs-04.txt Pages : 29 Date : 2009-02-03 The Routing Over Low power and Lossy network (ROLL) Working Group has been chartered to work on routing solutions for Low Power and Lossy networks (LLN) in various markets: Industrial, Commercial (Building), Home and Urban. Pursuant to this effort, this document defines the routing requirements for building automation. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-building-routing-reqs-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-building-routing-reqs-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-03141805.I-D@ietf.org> --NextPart-- From alexandru.petrescu@gmail.com Tue Feb 3 14:33:25 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F9003A6904 for ; Tue, 3 Feb 2009 14:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcYoRHgaexgw for ; Tue, 3 Feb 2009 14:33:24 -0800 (PST) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by core3.amsl.com (Postfix) with ESMTP id 34F5F3A67D7 for ; Tue, 3 Feb 2009 14:33:22 -0800 (PST) Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id 66AF84B0178; Tue, 3 Feb 2009 23:32:59 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp2-g21.free.fr (Postfix) with ESMTP id 25E184B00BC; Tue, 3 Feb 2009 23:32:57 +0100 (CET) Message-ID: <4988C5FC.5080806@gmail.com> Date: Tue, 03 Feb 2009 23:32:28 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Kris Pister References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <4987899C.3090708@gmail.com> <7C6DC187-681B-48DF-AFF1-FE329EA93CA8@cisco.com> <49885744.3050603@gmail.com> <49885C71.7090009@gmail.com> <4988A348.8030506@eecs.berkeley.edu> <4988B152.3030409@gmail.com> <4988C32B.6020702@eecs.berkeley.edu> In-Reply-To: <4988C32B.6020702@eecs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090203-0, 03/02/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] link-layers for ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 22:33:25 -0000 Kris Pister a écrit : > Alexandru Petrescu wrote: >> Kris Pister a écrit : >>> excellent questions, Alex. No doubt there will be many low power >>> and lossy DLLs for us to route over in the future, but there are >>> several that are of immediate commercial interest. 802.15.4 is a >>> good place to start as an example. There are at least a >>> half-dozen different deeply-duty-cycled DLLs that have been >>> demonstrated for 15.4 radios. All of them allow for a tradeoff >>> between power consumption and useful bandwidth, typically over a >>> range of at least three orders of magnitude. I'd like to make >>> sure that whichever routing protocol we use (find? create? you >>> tell me) that it can make intelligent use of the DLL. It's >>> really easy to build a network that runs everything at 1% duty >>> cycle, but it turns out to give lousy performance in a lot of >>> commercially relevant scenarios. >>> >>> So in my opinion, our work won't be done until we have a routing >>> protocol that has some mechanism to 1) be aware of the currently >>> configured capabilities of the DLL , and the limits of >>> configuration (e.g. I can handle 1 packet/sec right now, and up >>> to 10 packets/sec if you need me to) 2) be able to configure >>> those capabilities based on the routing decisions >>> >>> I'm not hung up on this being in the routing protocol itself. If >>> you tell me that the right way to do it is through some other >>> existing xyz-TE protocol that is independent of the routing >>> protocol, that's fine. But I'm convinced that the variable >>> power/throughput capabilities of RoLL DLLs is one of the >>> fundamental differences that makes routing "interesting" in these >>> networks. >> >> Trying to identify to what extent the interesting part is already >> addressed at link-layer... >> >> A link with its own routing (isa100.11a) talks to another link with >> its own other link routing (zigbee) through an IP router. This >> wouldn't run any routing protocol, because the link-layer routing >> is enough. > > That would require protocol translation at the router. No it wouldn't require translation, it would simply be an IP router with two different interfaces, a routing table and a search algorithm. The effort would be in spec'ing and porting IP over foo. And if foo already specifies a 802.3 MAC interface then IP over foo is straightforward. > 6LoWPAN with the mesh under option might be a better example. > Companies X, Y, and Z can all build 4944-compliant networks that will > form multi-hop meshes internally, but present it all as a single IP > link. I think this is pertinent. I think these kinds of networks wouldn't require complex IP routing. >> I'm not sure I understand how variable power/throughput >> capabilities of RoLL DLLs make IP routing interesting for these >> networks. > > You aren't alone. :) At this point, if there's group consensus it's > probably that I'm wrong. It's incumbent on me to explain why I think > that this is true, or to learn enough from the group to understand > why it's not. Assuming that we recharter, I'll get started on that > effort. Ok that. Alex > > ksjp >> >> Alex >> > From jvasseur@cisco.com Tue Feb 3 14:36:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31A443A6B3F for ; Tue, 3 Feb 2009 14:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.202 X-Spam-Level: X-Spam-Status: No, score=-10.202 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gv-WPRQg+Tj for ; Tue, 3 Feb 2009 14:36:08 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id BA65C3A6904 for ; Tue, 3 Feb 2009 14:36:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,374,1231113600"; d="scan'208";a="32758226" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2009 22:35:46 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n13MZkhF011125; Tue, 3 Feb 2009 23:35:46 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n13MZksP005268; Tue, 3 Feb 2009 22:35:46 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 23:35:46 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 23:35:45 +0100 Message-Id: <6CBF56E2-EEE7-4020-BFFA-130DC86E10A6@cisco.com> From: JP Vasseur To: Kris Pister , Alexandru Petrescu In-Reply-To: <4988C5FC.5080806@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Feb 2009 23:35:44 +0100 References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <4987899C.3090708@gmail.com> <7C6DC187-681B-48DF-AFF1-FE329EA93CA8@cisco.com> <49885744.3050603@gmail.com> <49885C71.7090009@gmail.com> <4988A348.8030506@eecs.berkeley.edu> <4988B152.3030409@gmail.com> <4988C32B.6020702@eecs.berkeley.edu> <4988C5FC.5080806@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Feb 2009 22:35:45.0777 (UTC) FILETIME=[C1258610:01C9864F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3669; t=1233700546; x=1234564546; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20link-layers=20for=20ROLL |Sender:=20; bh=7QIKRtTPsRbZts4ET0+5PW+OEj/WGxpxRvrEmnZagEU=; b=TsoQA+YE5ScBFlZw8o2cCG/Ot6jGKU2AYBqQowtFoyM/3ftMroYOFkvNB2 Eg8vmLNXWn1FB7wYlSAp8Gb/s5LvOrkbVYI3OoLLSC0R3yGsCbkx2GpSvp5p OzqFwdFIgM; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG Subject: Re: [Roll] link-layers for ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 22:36:09 -0000 I would have a lot to comment also here ;-) but I'll restrain myself =20 until we get a close on the other aspects. More later ... On Feb 3, 2009, at 11:32 PM, Alexandru Petrescu wrote: > Kris Pister a =E9crit : >> Alexandru Petrescu wrote: >>> Kris Pister a =E9crit : >>>> excellent questions, Alex. No doubt there will be many low power >>>> and lossy DLLs for us to route over in the future, but there are >>>> several that are of immediate commercial interest. 802.15.4 is a >>>> good place to start as an example. There are at least a >>>> half-dozen different deeply-duty-cycled DLLs that have been >>>> demonstrated for 15.4 radios. All of them allow for a tradeoff >>>> between power consumption and useful bandwidth, typically over a >>>> range of at least three orders of magnitude. I'd like to make >>>> sure that whichever routing protocol we use (find? create? you >>>> tell me) that it can make intelligent use of the DLL. It's >>>> really easy to build a network that runs everything at 1% duty >>>> cycle, but it turns out to give lousy performance in a lot of =20 >>>> commercially relevant scenarios. >>>> So in my opinion, our work won't be done until we have a routing >>>> protocol that has some mechanism to 1) be aware of the currently >>>> configured capabilities of the DLL , and the limits of >>>> configuration (e.g. I can handle 1 packet/sec right now, and up >>>> to 10 packets/sec if you need me to) 2) be able to configure >>>> those capabilities based on the routing decisions >>>> I'm not hung up on this being in the routing protocol itself. If >>>> you tell me that the right way to do it is through some other >>>> existing xyz-TE protocol that is independent of the routing >>>> protocol, that's fine. But I'm convinced that the variable >>>> power/throughput capabilities of RoLL DLLs is one of the >>>> fundamental differences that makes routing "interesting" in these >>>> networks. >>> Trying to identify to what extent the interesting part is already =20= >>> addressed at link-layer... >>> A link with its own routing (isa100.11a) talks to another link with >>> its own other link routing (zigbee) through an IP router. This =20 >>> wouldn't run any routing protocol, because the link-layer routing >>> is enough. >> That would require protocol translation at the router. > > No it wouldn't require translation, it would simply be an IP router =20= > with > two different interfaces, a routing table and a search algorithm. The > effort would be in spec'ing and porting IP over foo. And if foo =20 > already specifies a 802.3 MAC interface then IP over foo is =20 > straightforward. > >> 6LoWPAN with the mesh under option might be a better example. >> Companies X, Y, and Z can all build 4944-compliant networks that will >> form multi-hop meshes internally, but present it all as a single IP >> link. > > I think this is pertinent. I think these kinds of networks wouldn't =20= > require complex IP routing. > >>> I'm not sure I understand how variable power/throughput >>> capabilities of RoLL DLLs make IP routing interesting for these >>> networks. > > >> You aren't alone. :) At this point, if there's group consensus it's >> probably that I'm wrong. It's incumbent on me to explain why I think >> that this is true, or to learn enough from the group to understand >> why it's not. Assuming that we recharter, I'll get started on that >> effort. > > Ok that. > > Alex > >> ksjp >>> Alex > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Tue Feb 3 14:37:54 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 917C03A6B9F for ; Tue, 3 Feb 2009 14:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[AWL=-0.373, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_BACKHAIR_44=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuGdMMHRX8je for ; Tue, 3 Feb 2009 14:37:53 -0800 (PST) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by core3.amsl.com (Postfix) with ESMTP id 9C7283A6C55 for ; Tue, 3 Feb 2009 14:37:47 -0800 (PST) Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id CB5B58180DE; Tue, 3 Feb 2009 23:37:24 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp3-g21.free.fr (Postfix) with ESMTP id F20A681816C; Tue, 3 Feb 2009 23:37:20 +0100 (CET) Message-ID: <4988C703.6090805@gmail.com> Date: Tue, 03 Feb 2009 23:36:51 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Kris Pister References: <20090127000001.9F1F03A6819@core3.amsl.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> <49887E75.1090705@gmail.com> <44680fe70902030943q416b0908occe4dbc6b1a331e8@mail.gmail.com> <498883C1.4070703@gmail.com> <44680fe70902031147i3f0a30d8hc1b86c091dfb2792@mail.gmail.com> <4988AEF0.20803@gmail.com> <44680fe70902031258o54190cfdl6e5ce794e9b61e12@mail.gmail.com> <4988B4BF.8020000@gmail.com> <4988C110.4090902@eecs.berkeley.edu> In-Reply-To: <4988C110.4090902@eecs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090203-0, 03/02/2009), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 22:37:54 -0000 Kris Pister a écrit : > Alexandru Petrescu wrote: >> Stephen Dawson-Haggerty a écrit : >>> Kris also brought up another good point which is that if the links >>> are aggressively duty cycled (we consider that likely) matters are >>> likely to be even worse. Also, most discussion in this group has not >>> considered point to point links; I don't believe they are prevalent >>> in this design space. >> >> I think the slower the link, and the higher latency, the more chances >> are it's a ptp link. I think some Bluetooth serial links are ptp. I >> think serial rs-232 is ptp. I think these are potentially used in >> this space. > > I've deployed countless networks with 76.8kbps and 250kbps raw bit rate > radios. In both cases, the typical duty cycle on the radio is below > 0.1%, for an effective link data rate of at most a few tens to hundreds > of bits per second, and latencies of very roughly 1 second per hop. > These networks contain hundreds of nodes, and are tens of hops across. Is each hop-to-hop link a ptp link? I believe so: node<---ptplink---->node<----ptplink---->... 76kbps 76kbps I don't see any problem running ND on each ptplink, no risk of message storm. Alex > You are probably right that traditionally slower links were point-to-point. > Point-to-point links don't deliver the range and reliability required in > this space, whereas mesh networks do. > Hence the need for routing. > Hence the need for RoLL. > Hence the need to recharter. :) > > ksjp >> >> Alex >> >>> >>> Thanks, Steve >>> >>> On Tue, Feb 3, 2009 at 12:54 PM, Alexandru Petrescu >>> > >>> wrote: >>> >>> Stephen Dawson-Haggerty a écrit : [discussion about RA implosion when >>> RS sent to thousand neighbours, protocols-survey draft] >>> >>> >>> Which link sorry? Which is the link at 900Mhz over which ND would >>> behave such badly? What's its bandwidth? Is it a ptp or shared >>> link? >>> >>> >>> The ISM band has slots at, for instance 433 and 900Mhz; older Chipcon >>> cc1000 radios provided a link at around 75kbps. Now, we generally >>> talk about 802.15.4 (that isn't) but we also don't want to rely on >>> mechanisms that won't work for other links since it's pretty >>> conceivable someone would want to run IP over a slower link (for >>> instance to save power). A 50 byte packet at 75kbps is almost 7ms >>> long, so it's not unreasonable to conclude that it won't support >>> densities higher then 25-50 if everyone MUST reply within half a >>> second. >>> >>> >>> Stephen, I fully agree the links you mention at 75kbps are pertinent >>> and should be accommodated in ROLL environments. >>> >>> Indeed, 7ms latency is quite high and 1000 such messages wouldn't fit >>> in 500ms, even if randomly spaced: some times there would be 2 or 3 >>> simultaneous messages, maybe not very stormy. >>> >>> PtP? I wanted to ask, arent't these links with high latencies of type >>> point-to-point? I think it's very probably that a link with 75kbps >>> bandwidth be point-to-point. In this case the nodes are neighbors >>> 1-by-1, and thus no implosion (or message 'storm') danger. >>> >>> >>> In sensor nets reply implosion is pretty common; I'm sure there are >>> other people here will attest to that and you have to be very careful >>> to manage it, for instance using a density-dependent scheme like >>> Trickle. >>> >>> Let's not get sidetracked by ND though; >>> >>> >>> I'm using ND and link types as an opportunity to try to describe the >>> addressing architecture and the subnet structure. These are typical >>> for MANET discussion and often helpful to identify what can be done >>> at IP level and what below. >>> >>> Alex >>> >>> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Tue Feb 3 14:42:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB2CE3A67DF for ; Tue, 3 Feb 2009 14:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4NmcFFZAdqk for ; Tue, 3 Feb 2009 14:42:16 -0800 (PST) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by core3.amsl.com (Postfix) with ESMTP id 3B6443A67A5 for ; Tue, 3 Feb 2009 14:42:14 -0800 (PST) Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id 50A4E818082; Tue, 3 Feb 2009 23:41:51 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp3-g21.free.fr (Postfix) with ESMTP id E7DAE8180DE; Tue, 3 Feb 2009 23:41:48 +0100 (CET) Message-ID: <4988C810.4090804@gmail.com> Date: Tue, 03 Feb 2009 23:41:20 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: JP Vasseur References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <7F8459D1-3464-435A-AF8F-F9C437036FDF@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090203-0, 03/02/2009), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] If possible ... X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 22:42:18 -0000 JP Vasseur a écrit : > Dear all, > > Great to see all these discussions, but in light of the discussions > today I would like to *converge* - I did propose a plan (below). Until > we have concluded on the protocol survey (we're close) and re-chartering > (coming soon), can we focus the discussion, it goes in all directions. I agree, I'm waiting for comments from protocols-survey draft Authors about how should I improve the suggested NEMO-related text. http://www.ietf.org/mail-archive/web/roll/current/msg00847.html Alex > > Many Thanks. > > JP. > > On Feb 3, 2009, at 6:36 PM, JP Vasseur wrote: > >> Thanks Dave for AD's feed-back. >> >> We *are* making progress and looking at all the interest that we are >> gathering from many participants, this is a good sign >> of strong participation for the next phase, a key of success. >> >> First of all, I would like to remind that all the routing requirements >> documents are finalized. I asked for a last revision of the building >> routing requirements documents before publication request. And then we >> will be done for this part. Lot of work. >> >> Here is what I propose: >> >> 1) I guess that things have been clarified on the WG positioning issue. >> 2) Many supportive request to close on this and move forward. >> *3) Still there are a few requests that have been made by Thomas, >> Alex, ... that we should try to address.* >> May I ask you to try to limit as much as possible your request and we >> will do everything possible to address them. >> 4) End of this week, we will close on the protocol survey. >> 5) Right after we'll propose you a new charter (one week discussion) >> before IESG submission. >> 6) If/once re-chartered, we count on everybody's help to continue the >> good work. >> >> Thanks. >> >> JP. >> >> >> On Feb 3, 2009, at 5:52 PM, David Ward wrote: >> >>> All - >>> >>> We debated the delta between these three WGs when chartering ROLL for >>> a considerable period of time. I do not want to revisit that debate >>> but, I will quickly summarize here >>> >>> - 6LOWPAN is not working at the IP layer so, the overlap here is >>> really not an issue. >>> - MANET is and has been working on routing protocols for mobile, ad >>> hoc networks with specific requirements and use cases. Some of those >>> use cases may or may not overlap with ROLL. There will be lessons to >>> be learned but, the primary use cases being worked on appeared by all >>> the chairs and ADs involved to be different enough to warrant a new >>> WG in this area. >>> - ROLL was originally chartered to write the requirements and >>> evaluate existing protocols for low power, lossy networks running >>> over IP (some call these "sensor networks"). ROLL is only chartered >>> to work on the routing protocol portion. Not the transport, encap or >>> other topics at this time. Also note that mobility is not under >>> consideration at this time. >>> >>> ROLL WG appears to have come to consensus on the requirement docs >>> that state specific functions, attributes, power/memory envelope and >>> algorithmic considerations that must be "in the routing protocol" for >>> these networks. The survey ID (which is of course a snapshot at one >>> point in time) puts some bounds on mapping the required functions, >>> attributes and other considerations into protocols available *today.* >>> >>> Given the real work of designing a protocol hasn't begun by the ROLL >>> WG participants; holding up the WG to begin taking what they >>> currently defined as a very complex, multivariate problem and begin >>> whittling it down to something solvable via theoretical and >>> hypothetical exercises seems like an unwise use of time given the >>> experience and energy of the WG in this problem space. The WG must >>> move beyond the moderately high-level boundary setting exercise >>> (which I believe there is consensus) and move onto the more >>> challenging work of defining the objects, algorithms, semantics, >>> state machines and functionality of the protocol. In the design >>> phase (vs the survey phase) a better evaluation can be made of the >>> ease or difficulty of "from scratch" or "modify what we have" can be >>> made. I expect "wild swings" of the design pattern of the protocol >>> during the first year of the design effort. I attempted to make this >>> clear at the mic in Minneapolis that the current trajectory is very >>> complex problem domain that hasn't born a lot of fruit but, that in >>> the design phase reducing the complexity must occur. Members of the >>> WG who have vast experience in these types of networks and have >>> widely deployed products have stated that the routing protocol issues >>> are solvable problems with some simplifying assumptions. I look >>> forward to the WG making these design decisions and tradeoffs and >>> debating the structure of the protocol. Any protocol reuse, >>> experience, etc will be critical at this point to make the correct >>> choices and I look to MANET, ROLL, MEXT, 6LOWPAN and other IETF'ers >>> with routing protocol experience to contribute. This is an industry >>> important juncture and moving LPLN to IP is a critical change. >>> >>> I am looking to the WG chairs to declare loose consensus on the >>> documents (when appropriate) so that the rechartering of the WG to >>> enter the design phase can occur. WIthout a doubt, the requirements >>> as-is have defined the boundary of the work effort and I believe it >>> is clear what is the difference between the WGs. >>> >>> >>> HIH >>> >>> -DWard >>> >>> >>> >>> >>> On Feb 3, 2009, at 7:14 AM, Thomas Heide Clausen wrote: >>> >>>> Dear JP, dear ADs, dear WG, >>>> >>>> (I Cc the other INT chair, as he's following 6lowpan) >>>> >>>> For the record, I am not arguing that MANET protocols should be >>>> applied or be applicable -- as you seem to suggest in your email. I >>>> believe that I have stated so repeatedly. >>>> >>>> I submit, however, that as it is currently exposed, ROLL, MANET and >>>> 6LOW seem to be operating within the same space -- to the untrained >>>> eye, in exactly the same space. My position is that it would be very >>>> unfortunate having one WG creating confusion on the applicability of >>>> the work of itself and of other IETF wg's, by simple omission of >>>> suitable perimeter definitions. >>>> >>>> In that sort of situation, the IETF needs to be extra prudent to >>>> make sure to clearly spell out suitable perimeter definitions prior >>>> to, or conjointly with, the first publication cycle. In this case, >>>> before or with the survey I-D. >>>> >>>> Sincerely, >>>> >>>> Thomas >>>> >>>> >>>> On Feb 3, 2009, at 1:19 PM, JP Vasseur wrote: >>>> >>>>> Dear WG and ADs, >>>>> >>>>> Two issues are raised here for which we would appreciate ADs' point >>>>> of view and feed-back from the WG. Please see in line. >>>>> >>>>> >>>>> Dear Thomas, >>>>> >>>>> At the risk of repeating myself, I'd like to make a few important >>>>> statements before *hopefully* come to a closure ;-) >>>>> >>>>> -> As you know, many of the ROLL WG active participants have been >>>>> working quite hard to produce a detailed set of requirements, >>>>> discuss how to proceed on the protocol survey document, and other >>>>> ID are in the works. >>>>> -> We managed to get highly experienced contributors in the field >>>>> that have designed and deployed solutions so they not only have an >>>>> excellent expertise of the requirements but also on solutions, >>>>> *-> Yes we need to rush out. Why ? Because proprietary or >>>>> semi-closed non-IP solutions are being deployed at a fairly large >>>>> scale. I do not think that I have to convince anybody on this list >>>>> that this is the WRONG approach for a number of reasons. The >>>>> industry is asking for an IP solution *now*.* >>>>> -> No we do not want to re-invent the wheel (see our presentation >>>>> at the routing plenary in Chicago). Anything that already exists >>>>> MUST (rfc2119 ;-)) be used provided that it meets our requirements. >>>>> And if we can adapt an existing protocol, we are all for it ! >>>>> -> Yes these requirements are quite specifics and this is precisely >>>>> why ROLL has been formed, 4 application-specific routing >>>>> requirements have been produced (to reduce the scope). Even if at a >>>>> first sight, it looks very much similar to a MANET issue (and there >>>>> ARE similarities but also very different requirements), having to >>>>> deal with a highly static network of hundreds of thousands of >>>>> battery operated sleeping nodes with 4K of RAM is quite specific. >>>>> Note that this is not a random example, but an on-going non-IP >>>>> deployed network. >>>>> >>>>> And to conclude on this introduction ... after an outstanding >>>>> progress on the WG during the first 6-8 months, we have been slowed >>>>> down dramatically for the last 2 months, thus it is time to close >>>>> and move on to quickly re-charter and start the protocol work >>>>> (hopefully as light as possible) to see IP-based solution deployed. >>>>> I know that we are on the same page, we just need to find a good >>>>> compromise on both "sides". >>>>> >>>>> Nothing new so far, let's move to a proposed resolution - See in line, >>>>> >>>>> On Feb 2, 2009, at 7:37 PM, Thomas Heide Clausen wrote: >>>>> >>>>>> All, >>>>>> >>>>>> I promised a review, and I apologize that I wasn't able to do so >>>>>> before the weekend as originally projected. >>>>>> >>>>>> Other than some typos that Chris and others have pointed out, I'll >>>>>> try to offer my understanding of the problem space and suggest >>>>>> some ways of addressing my main concerns.... >>>>>> >>>>>> My first main concern remain that it is not clear, still, how ROLL >>>>>> positions itself with respect to MANET, 6LOW et. al, all of which >>>>>> appear to be within the same space and within the IETF. This I-D >>>>>> sees ROLL as presented with entirely new problems (the use of >>>>>> "novel" in the abstract, the statement that "existing protocols >>>>>> were not designed with these requirements in mind" seem to confirm >>>>>> this). >>>>>> >>>>>> Looking at the requirements listed, including "low power, low >>>>>> bandwidth, low footprint", these appear similar to those which are >>>>>> also brought forward in e.g. MANET and 6LOW. Reading (quickly, I >>>>>> confess) the various requirements documents of the >>>>>> draft-ietf-roll series present scenarios which are similar to >>>>>> those where MANETs are deployed, and are thought deployed, as well. >>>>>> >>>>>> I also note that many additional (and unstated) characteristics >>>>>> between ROLL and e.g. MANET are the same: mobile, wireless, >>>>>> fragility, auto-configuration, IP routing, interface/link issues... >>>>>> >>>>>> Arguing that, as does this I-D, despite the above impression "ROLL >>>>>> is novel and different" invites asking "how, exactly?" I think >>>>>> that this question is valid, and merits being answered, before the >>>>>> evaluations in this I-D can be judged fairly. >>>>>> >>>>>> Note that I come from a MANET background, and so I *could* >>>>>> interpret from the ROLL discussion that where MANETs may aim for >>>>>> "low power, low bandwidth, ....", ROLL may be able to quantify >>>>>> these as "below this firm threshold" -- i.e. as a sort of >>>>>> "extreme" or "constrained" MANET. >>>>>> >>>>>> This is a personal observation, I note, which would allow me to >>>>>> comprehend how ROLL and MANET are positioned relative to one >>>>>> another -- but one which neither this I-D nor the requirements >>>>>> document spell out or quantify -- or, for that matter, debunk. >>>>>> >>>>>> I think it's critical to understand this, in order to understand >>>>>> the need for a new protocol development. I think it is important >>>>>> to document this understanding in something with more persistency. >>>>>> >>>>>> If what I suggest above makes sense as a way of positioning ROLL >>>>>> and MANET relative to one another, I'd suggest including something >>>>>> to this effect in the survey I-D, as this I-D is the one making a >>>>>> *direct* reference to the applicability of MANET protocols to ROLL. >>>>>> >>>>>> If what I suggest doesn't make sense at all, then I'd be happy to >>>>>> have it debunked and, hopefully, through that debunking a >>>>>> positioning/description that does ring true with us all can be >>>>>> produced? >>>>>> >>>>>> My second main concern is, that I still think that the choice of >>>>>> criteria is unfortunate (not the word, Phill has me convinced on >>>>>> that front, but the actual criteria). Control cost is, by all >>>>>> means, a rather meaningless criteria when taken in isolation. I've >>>>>> sketched a "zero-control-cost" routing protocol (flood all data - >>>>>> say use SMF, also a MANET protocol, and also a rather "mature" I-D >>>>>> and wg item) which would score well on the control cost criteria, >>>>>> but would likely be an extremely bad choice for delivering unicast >>>>>> data. >>>>>> >>>>>> The metric which matters, and which should matter to ROLL in >>>>>> particular, is "the total cost of getting user data through the >>>>>> network, including control cost necessary to set up paths" -- as >>>>>> we know, every packet sent and received costs bandwidth, energy >>>>>> and cycles -- user data no different from contro. >>>>>> >>>>>> According to the criterions as set up by this I-D, a protocol >>>>>> producing "longer than shortest paths" at the benefit of slightly >>>>>> lower control cost would score better than a protocol producing >>>>>> "shortest paths" with slightly higher control cost. This is not >>>>>> hypothetical, btw., there are plenty of studies observing and >>>>>> reflecting upon this regarding the different MANET protocols, in >>>>>> academic literature -- and observed in real networks as well. >>>>>> >>>>>> I note that this trade-off (slightly longer paths for lower >>>>>> control cost) may be perfectly fair, assuming that very low >>>>>> amounts of user data traffic transit through the network. However, >>>>>> I do not see this assumption mentioned as a justification for >>>>>> focusing on the control cost metric and discarding the "path >>>>>> length" or the "total cost of getting user data through the network". >>>>>> >>>>>> I believe that either these assumptions should be made explicit >>>>>> ("there's so little user data traffic in a ROLL network that we do >>>>>> not care about shortest paths") or -- if these assumptions do not >>>>>> hold, that the evaluation criteria are incomplete. >>>>>> >>>>>> I note that it's true that we can always add another criteria ad >>>>>> infinitum, and that's CLEARLY not what we want to do. However when >>>>>> I say "incomplete" in the above, I simply suggest that based on >>>>>> what is presented one cannot draw conclusions based on the >>>>>> evaluation criteria....or, worse, that one draws the wrong >>>>>> conclusions based on the information presented. >>>>> >>>>> It is not easy to answer each of your point without running the >>>>> risk to start a debate that will never end. You raised some >>>>> excellent points that I agree with and others that I firmly >>>>> disagree with ... So let me try to make a few observations: >>>>> 1) As pointed out earlier, yes there are similarities between MANET >>>>> and ROLL. I do not see this as an issue. >>>>> 2) The aim of the protocol survey IS NOT to exclude MANET >>>>> protocols. As mentioned many times on the list, we *only* wanted to >>>>> show that existing protocols, with no change, could not be used in >>>>> LLNs. This has been clarified in the document as your request and >>>>> it HAD to be clarified. >>>>> 3) We could have used two different approaches for the survey: >>>>> - Look at all MUST from the requirements documents >>>>> - Try to derive a subset of necessary but not sufficient criteria, >>>>> which the WG chose to do (consensus). Yes this list is not perfect, >>>>> criteria could be changed, removed or added but looked good enough >>>>> with excellent consensus until LC. >>>>> 4) With regards to 6lowpan (I copy the chair), I do not see any >>>>> overlap at all. Please refer to their charter and WG items. The >>>>> only place that required clarification was the routing requirements >>>>> and I was personally opposed to it but this was adopted as a >>>>> 6lowpan WG item *by consensus*. We're are working together and >>>>> managed to sort this out. This document will be 6lowpan specific. >>>>> >>>>> What I want to avoid is an endless discussion on the positioning of >>>>> ROLL, MANET, 6lowpan and quite frankly we could add other WGs to >>>>> the list. >>>>> >>>>> /So what is the bottom line ?/ >>>>> >>>>> We just need to agree on the fact that there is no existing >>>>> protocol that meets the ROLL requirements and move to the next step >>>>> (re-chartering) to select one (hopefully not two) routing protocols >>>>> in light of the routing requirement (NOT the protocol survey), >>>>> which can either be an adapted MANET protocol or a new protocol. >>>>> >>>>> Now moving to your proposed resolution. >>>>> >>>>>> >>>>>> >>>>>> So, in a nutshell, I suggest that we address (i) the positioning >>>>>> issue and (ii) the criteria issue thus: >>>>>> >>>>>> o Describe as I proposed above if ROLL and MANETs position >>>>>> themselves as I >>>>>> have deducted. If my deduction is incorrect, then let's quickly >>>>>> iterate on the list >>>>>> as to understand how to do produce an alternative description. If >>>>>> we can't do this, >>>>>> then the conclusion can be that "we do not know how ROLL and MANET >>>>>> position >>>>>> themselves wrt each other", and we could then state that clearly? >>>>>> >>>>>> It *should* not be more than a couple of paragraphs worth of text >>>>>> to add, I gather? >>>>>> >>>>> >>>>> If you find a way to word this, please feel free and I'd be happy >>>>> to help but feel it as necessary ... Any opinion from our RTG and >>>>> INT ADs ? >>>>> >>>>>> o To the criteria, either of: >>>>>> >>>>>> - Add the assumption that "user data traffic is so low that path >>>>>> lengths do not >>>>>> matter nor does the cost of carrying user data traffice" >>>>>> >>>>> >>>>> The motivation for selecting a longer path is not tied to the >>>>> amount of traffic here but the level of constraints. Note that this >>>>> is also true for several other technologies such as MPLS-TE. You >>>>> may have large amount of traffic and still require to follow a >>>>> non-shortest path (constrained based routing). This is detailed in >>>>> several requirements IDs. Criticality of data is of course >>>>> different, thus the requirements for potentially different data >>>>> paths according to packet marking using DSCP. >>>>> >>>>>> - Add a criteria & evaluation of "path length" >>>>>> >>>>>> - Add a criteria & evaluation of "total cost for getting user data >>>>>> through the network" >>>>>> >>>>> >>>>> And we can add many more but if the current protocol do not satisfy >>>>> existing requirements, isn't it sufficient to answer the question >>>>> on whether one can find an existing protocol? >>>>> >>>>>> This would make a large chunk of my concerns and issues vanish, >>>>>> and allow correctly interpreting and evaluating the rest of the >>>>>> document. >>>>> >>>>> That said, question for the WG. Who think that such criteria should >>>>> be added to move forward ? Please reply. >>>>> >>>>>> >>>>>> >>>>>> How does that sound as an approach forward? >>>>>> >>>>> >>>>> Thanks for helping out. >>>>> >>>>> Cheers. >>>>> >>>>> JP. >>>>> >>>>>> Cheers, >>>>>> >>>>>> Thomas >>>>>> >>>>>> On Jan 27, 2009, at 1:00 AM, Internet-Drafts@ietf.org >>>>>> wrote: >>>>>> >>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>>> directories. >>>>>>> This draft is a work item of the Routing Over Low power and Lossy >>>>>>> networks Working Group of the IETF. >>>>>>> >>>>>>> Title : Overview of Existing Routing Protocols for Low Power and >>>>>>> Lossy Networks >>>>>>> Author(s) : A. Tavakoli, S. Dawson-Haggerty, P. Levis >>>>>>> Filename : draft-ietf-roll-protocols-survey-05.txt >>>>>>> Pages : 26 >>>>>>> Date : 2009-1-26 >>>>>>> >>>>>>> Networks of low power wireless devices introduce novel IP routing >>>>>>> issues. Low-power wireless devices, such as sensors, actuators and >>>>>>> smart objects, have difficult constraints: very limited memory, >>>>>>> little processing power, and long sleep periods. As most of these >>>>>>> devices are battery-powered, energy efficiency is critically >>>>>>> important. Wireless link qualities can vary significantly over >>>>>>> time, >>>>>>> requiring protocols to make agile decisions yet minimize topology >>>>>>> change energy costs. Routing over such low power and lossy >>>>>>> networks >>>>>>> has novel requirements that existing protocols may not address. >>>>>>> This >>>>>>> document provides a brief survey of the strengths and weaknesses of >>>>>>> existing protocols with respect to this class of networks. >>>>>>> From this >>>>>>> survey it examines whether existing and mature IETF protocols >>>>>>> can be >>>>>>> used without modification in these networks, or whether further >>>>>>> work >>>>>>> is necessary. >>>>>>> is necessary. >>>>>>> >>>>>>> A URL for this Internet-Draft is: >>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-survey-05.txt >>>>>>> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>> >>>>>>> Below is the data which will enable a MIME compliant mail reader >>>>>>> implementation to automatically retrieve the ASCII version of the >>>>>>> Internet-Draft. >>>>>>> Content-Type: text/plain >>>>>>> Content-ID: <2009-1-26155804.I-D@ietf.org >>>>>>> > >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>> >>> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > From Jerald.P.Martocci@jci.com Tue Feb 3 14:48:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C911C3A6A30; Tue, 3 Feb 2009 14:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8FgrQWD6IQG; Tue, 3 Feb 2009 14:48:13 -0800 (PST) Received: from exprod8og101.obsmtp.com (exprod8og101.obsmtp.com [64.18.3.82]) by core3.amsl.com (Postfix) with ESMTP id D3D293A66B4; Tue, 3 Feb 2009 14:48:12 -0800 (PST) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob101.postini.com ([64.18.7.12]) with SMTP ID DSNKSYjJmCFZkeZqqzO3hupapO8OdnVgRh6B@postini.com; Tue, 03 Feb 2009 14:47:54 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009020316481057-532363 ; Tue, 3 Feb 2009 16:48:10 -0600 In-Reply-To: <20090203223001.7EC803A6904@core3.amsl.com> MIME-Version: 1.0 To: Internet-Drafts@ietf.org X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Tue, 3 Feb 2009 16:47:47 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 02/03/2009 04:47:50 PM, Serialize complete at 02/03/2009 04:47:50 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 02/03/2009 04:48:10 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 02/03/2009 04:48:14 PM, Serialize complete at 02/03/2009 04:48:14 PM Content-Type: multipart/alternative; boundary="=_alternative 007D38ED86257552_=" Cc: roll@ietf.org, roll-bounces@ietf.org, i-d-announce@ietf.org Subject: Re: [Roll] I-D Action:draft-ietf-roll-building-routing-reqs-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 22:48:14 -0000 This is a multipart message in MIME format. --=_alternative 007D38ED86257552_= Content-Type: text/plain; charset="US-ASCII" All, The -04 version of the Building Requirements document has just been posted. The -04 document incorporates only three minor changes from -03 ... 1) The 'Parallel Download' requirement has been moved from the requirements section of the draft body to Appendix A. JP had requested this change. I agreed in that this requirement is not a routing requirement. 2) The 'Security' section of the draft was reworded to discuss network security requirements as they relate to routing. The prior draft was not clear which of the security requirements were related to routing. 3) I reread the entire draft and cleaned up a few remaining grammatical errors. I also reordered the requirements in Appendix A in what I believe is a priority order. they had been in chronological order in the -03 draft. Jerry Internet-Drafts@ietf.org Sent by: roll-bounces@ietf.org 02/03/2009 04:29 PM To i-d-announce@ietf.org cc roll@ietf.org Subject [Roll] I-D Action:draft-ietf-roll-building-routing-reqs-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Building Automation Routing Requirements in Low Power and Lossy Networks Author(s) : J. Martocci, et al. Filename : draft-ietf-roll-building-routing-reqs-04.txt Pages : 29 Date : 2009-02-03 The Routing Over Low power and Lossy network (ROLL) Working Group has been chartered to work on routing solutions for Low Power and Lossy networks (LLN) in various markets: Industrial, Commercial (Building), Home and Urban. Pursuant to this effort, this document defines the routing requirements for building automation. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-building-routing-reqs-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-roll-building-routing-reqs-04.txt _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 007D38ED86257552_= Content-Type: text/html; charset="US-ASCII"
All,

The -04 version of the Building Requirements document has just been posted.  The -04 document incorporates only three minor changes from -03 ...

1) The 'Parallel Download' requirement has been moved from the requirements section of the draft body to Appendix A.  JP had requested this change.  I agreed in that this requirement is not a routing requirement.

2) The 'Security' section of the draft was reworded to discuss network security requirements as they relate to routing.  The prior draft was not clear which of the security requirements were related to routing.

3) I reread the entire draft and cleaned up a few remaining grammatical errors.  I also reordered the requirements in Appendix A in what I believe is a priority order.  they had been in chronological order in the -03 draft.

Jerry






Internet-Drafts@ietf.org
Sent by: roll-bounces@ietf.org

02/03/2009 04:29 PM

To
i-d-announce@ietf.org
cc
roll@ietf.org
Subject
[Roll] I-D Action:draft-ietf-roll-building-routing-reqs-04.txt





A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF.


                Title           : Building Automation Routing Requirements in Low Power and Lossy Networks
                Author(s)       : J. Martocci, et al.
                Filename        : draft-ietf-roll-building-routing-reqs-04.txt
                Pages           : 29
                Date            : 2009-02-03

The Routing Over Low power and Lossy network (ROLL) Working Group has
been chartered to work on routing solutions for Low Power and Lossy
networks (LLN) in various markets: Industrial, Commercial (Building),
Home and Urban. Pursuant to this effort, this document defines the
routing requirements for building automation.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-building-routing-reqs-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-roll-building-routing-reqs-04.txt_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 007D38ED86257552_=-- From jhui@archrock.com Tue Feb 3 14:48:23 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ECC028C0DC for ; Tue, 3 Feb 2009 14:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_44=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAs1h0xlBx6H for ; Tue, 3 Feb 2009 14:48:22 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 06CDD28C0FC for ; Tue, 3 Feb 2009 14:48:22 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id DAE71AF8A6; Tue, 3 Feb 2009 14:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWXkxgS6tuwb; Tue, 3 Feb 2009 14:48:02 -0800 (PST) Received: from [192.168.7.78] (69-12-164-140.sfo.archrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id EAF9BAF89C; Tue, 3 Feb 2009 14:48:01 -0800 (PST) Message-Id: <7673A863-F3BF-4499-993E-1AEA59CA192B@archrock.com> From: Jonathan Hui To: Alexandru Petrescu In-Reply-To: <4988C703.6090805@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Feb 2009 14:48:00 -0800 References: <20090127000001.9F1F03A6819@core3.amsl.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> <49887E75.1090705@gmail.com> <44680fe70902030943q416b0908occe4dbc6b1a331e8@mail.gmail.com> <498883C1.4070703@gmail.com> <44680fe70902031147i3f0a30d8hc1b86c091dfb2792@mail.gmail.com> <4988AEF0.20803@gmail.com> <44680fe70902031258o54190cfdl6e5ce794e9b61e12@mail.gmail.com> <4988B4BF.8020000@gmail.com> <4988C110.4090902@eecs.berkeley.edu> <4988C703.6090805@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: ROLL WG Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 22:48:23 -0000 On Feb 3, 2009, at 2:36 PM, Alexandru Petrescu wrote: > Kris Pister a =E9crit : >> Alexandru Petrescu wrote: >>> Stephen Dawson-Haggerty a =E9crit : >>>> Kris also brought up another good point which is that if the links >>>> are aggressively duty cycled (we consider that likely) matters are >>>> likely to be even worse. Also, most discussion in this group has =20= >>>> not >>>> considered point to point links; I don't believe they are prevalent >>>> in this design space. >>> >>> I think the slower the link, and the higher latency, the more =20 >>> chances are it's a ptp link. I think some Bluetooth serial links =20= >>> are ptp. I think serial rs-232 is ptp. I think these are =20 >>> potentially used in this space. > > >> I've deployed countless networks with 76.8kbps and 250kbps raw bit =20= >> rate radios. In both cases, the typical duty cycle on the radio is =20= >> below 0.1%, for an effective link data rate of at most a few tens =20 >> to hundreds of bits per second, and latencies of very roughly 1 =20 >> second per hop. These networks contain hundreds of nodes, and are =20= >> tens of hops across. > > Is each hop-to-hop link a ptp link? I believe so: > > node<---ptplink---->node<----ptplink---->... > 76kbps 76kbps I don't believe so... the link is both unicast- and broadcast- capable =20= - the latter may reach > 1 node (possibly hundreds) with just a single =20= transmission. -- Jonathan Hui > I don't see any problem running ND on each ptplink, no risk of =20 > message storm. > > Alex > > > >> You are probably right that traditionally slower links were point-=20 >> to-point. >> Point-to-point links don't deliver the range and reliability =20 >> required in this space, whereas mesh networks do. >> Hence the need for routing. >> Hence the need for RoLL. >> Hence the need to recharter. :) >> ksjp >>> >>> Alex >>> >>>> >>>> Thanks, Steve >>>> >>>> On Tue, Feb 3, 2009 at 12:54 PM, Alexandru Petrescu = >>> > >>>> wrote: >>>> >>>> Stephen Dawson-Haggerty a =E9crit : [discussion about RA implosion =20= >>>> when >>>> RS sent to thousand neighbours, protocols-survey draft] >>>> >>>> >>>> Which link sorry? Which is the link at 900Mhz over which ND =20 >>>> would behave such badly? What's its bandwidth? Is it a ptp or =20 >>>> shared >>>> link? >>>> >>>> >>>> The ISM band has slots at, for instance 433 and 900Mhz; older =20 >>>> Chipcon >>>> cc1000 radios provided a link at around 75kbps. Now, we generally >>>> talk about 802.15.4 (that isn't) but we also don't want to rely on >>>> mechanisms that won't work for other links since it's pretty >>>> conceivable someone would want to run IP over a slower link (for >>>> instance to save power). A 50 byte packet at 75kbps is almost 7ms >>>> long, so it's not unreasonable to conclude that it won't support >>>> densities higher then 25-50 if everyone MUST reply within half a >>>> second. >>>> >>>> >>>> Stephen, I fully agree the links you mention at 75kbps are =20 >>>> pertinent >>>> and should be accommodated in ROLL environments. >>>> >>>> Indeed, 7ms latency is quite high and 1000 such messages wouldn't =20= >>>> fit >>>> in 500ms, even if randomly spaced: some times there would be 2 or =20= >>>> 3 simultaneous messages, maybe not very stormy. >>>> >>>> PtP? I wanted to ask, arent't these links with high latencies of =20= >>>> type >>>> point-to-point? I think it's very probably that a link with =20 >>>> 75kbps bandwidth be point-to-point. In this case the nodes are =20 >>>> neighbors 1-by-1, and thus no implosion (or message 'storm') =20 >>>> danger. >>>> >>>> >>>> In sensor nets reply implosion is pretty common; I'm sure there are >>>> other people here will attest to that and you have to be very =20 >>>> careful >>>> to manage it, for instance using a density-dependent scheme like >>>> Trickle. >>>> >>>> Let's not get sidetracked by ND though; >>>> >>>> >>>> I'm using ND and link types as an opportunity to try to describe =20= >>>> the addressing architecture and the subnet structure. These are =20= >>>> typical for MANET discussion and often helpful to identify what =20 >>>> can be done at IP level and what below. >>>> >>>> Alex >>>> >>>> >>> >>> _______________________________________________ >>> 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 From tim.winter@ekasystems.com Tue Feb 3 15:07:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CECBE3A6C49 for ; Tue, 3 Feb 2009 15:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.514 X-Spam-Level: X-Spam-Status: No, score=-3.514 tagged_above=-999 required=5 tests=[AWL=1.085, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcoN3gRhXvD5 for ; Tue, 3 Feb 2009 15:07:16 -0800 (PST) Received: from smtp102.biz.mail.re2.yahoo.com (smtp102.biz.mail.re2.yahoo.com [68.142.229.216]) by core3.amsl.com (Postfix) with SMTP id 93E543A6B9F for ; Tue, 3 Feb 2009 15:07:16 -0800 (PST) Received: (qmail 36217 invoked from network); 3 Feb 2009 23:06:57 -0000 Received: from unknown (HELO zeke.ekasystems.com) (tim.winter@209.48.242.66 with plain) by smtp102.biz.mail.re2.yahoo.com with SMTP; 3 Feb 2009 23:06:56 -0000 X-YMail-OSG: 5leC95wVM1l8VwChBpP.uWmX73ixqX0NUtj7CiJDyUDhNaifnxSh_.wokkIVeEfSoqXIbF6AtKD15cN.jWUKTRkcvwbygeWrLgYGaQckOOJb3.C_i_jgeIDiRI_pjP71IfbHzAa0BVrWNk1VhF_RI6xfIyXNl_0WsNMUWqI6diJDU2Cho_LikFGH X-Yahoo-Newman-Property: ymail-3 Message-ID: <4988CE0F.5020507@ekasystems.com> Date: Tue, 03 Feb 2009 18:06:55 -0500 From: Tim Winter User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: "M. B. Anand" References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498874A8.9030206@ekasystems.com> In-Reply-To: <498874A8.9030206@ekasystems.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review and comments draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 23:07:17 -0000 I also agree with and reiterate Anand's comments. -Tim M. B. Anand wrote: > JP Vasseur wrote: >> >> *-> Yes we need to rush out. Why ? Because proprietary or semi-closed >> non-IP solutions are being deployed at a fairly large scale. I do not >> think that I have to convince anybody on this list that this is the >> WRONG approach for a number of reasons. The industry is asking for an >> IP solution *now*.* > Indeed. And the bold letters are quite warranted. As we speak, actual > legislation is moving through Congress in the US that specifies > "Internet-enabled technologies" as a condition for grants in smart grid > applications. Who knows what such technologies are ? There is no routing > standard, there is no standard on any number of other things although > there are bits and pieces of standards here and there. Billions of > dollars are about to be handed out in the very near future and in the > absence of any standards, practically everything is going to get claimed > to be IP. The window is closing very, very fast. > > While all this is surely not an excuse to produce shoddy work, it is > certainly a tremendous driver to move. The sole reason for those of us > engaged in the application space to be involved and contribute actively > here is that there is a group of experts who having been doing > networking for decades and there is an unrivaled body of knowledge at > IETF on how to do networking correctly. That includes all the working > groups. It needs to be done here and it needs to be done soon. >> >>> This would make a large chunk of my concerns and issues vanish, and >>> allow correctly interpreting and evaluating the rest of the document. >> >> That said, question for the WG. Who think that such criteria should be >> added to move forward ? Please reply. > As has been said here many times, the purpose of this document is to > evaluate the suitability of existing IETF protocols for their > suitability for intersection of ROLL requirements. The document itself > is very clear and states: "this document simply seeks to answer the > question: do LLNs require a new protocol specification document at > all?" So, no, it is not superfluous, because this question needed to be > answered. It is expressly not the purpose of this document to decide > what is a useful approach or a starting point for any new protocol. It > seems to get interpreted that way in many of these discussions and that > is not its purpose. > > In a recent email, Emmanuel states: > "Basically, everybody agrees that something special must be done for > sensor ad hoc connectivity with IP, and everybody wants to reach the > next phase ASAP (i.e. work on solutions). " > > If everybody agrees on this, then this document should close without > needing any further discussion. The whole purpose of the document is to > document what everyone seems to agree on. Then, what is the disagreement ? > > I suggest we restrict the discussion to the following: > 1. Are there any disagreements on the analysis ? - Seems not at the > present time, or any such issues have already been addressed. > 2. Should any criteria be removed and if so why ? - Again, I haven't > seen anyone state this. > 3. Let's not add any criteria - because that is not going to magically > make the conclusion - i.e., the fact no existing protocol, unchanged, > suits the requirements (which, BTW, everyone agrees on) change. > > All the other discussions on ROLL, MANET, 6LoW etc. are perhaps valuable > and there is a time and place for those, but it has little to do with > this draft. > > Best regards, > Anand. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Tue Feb 3 15:47:48 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4404F3A6C3E for ; Tue, 3 Feb 2009 15:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_BACKHAIR_44=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-5KIK4Kd+GO for ; Tue, 3 Feb 2009 15:47:47 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 2BEAD3A6BF0 for ; Tue, 3 Feb 2009 15:47:02 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id D6031D480DE; Wed, 4 Feb 2009 00:46:39 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 47CD8D48091; Wed, 4 Feb 2009 00:46:36 +0100 (CET) Message-ID: <4988D73F.7040303@gmail.com> Date: Wed, 04 Feb 2009 00:46:07 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Jonathan Hui References: <20090127000001.9F1F03A6819@core3.amsl.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> <49887E75.1090705@gmail.com> <44680fe70902030943q416b0908occe4dbc6b1a331e8@mail.gmail.com> <498883C1.4070703@gmail.com> <44680fe70902031147i3f0a30d8hc1b86c091dfb2792@mail.gmail.com> <4988AEF0.20803@gmail.com> <44680fe70902031258o54190cfdl6e5ce794e9b61e12@mail.gmail.com> <4988B4BF.8020000@gmail.com> <4988C110.4090902@eecs.berkeley.edu> <4988C703.6090805@gmail.com> <7673A863-F3BF-4499-993E-1AEA59CA192B@archrock.com> In-Reply-To: <7673A863-F3BF-4499-993E-1AEA59CA192B@archrock.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090203-1, 03/02/2009), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 23:47:48 -0000 Jonathan Hui a écrit : > > On Feb 3, 2009, at 2:36 PM, Alexandru Petrescu wrote: >> Kris Pister a écrit : >>> Alexandru Petrescu wrote: >>>> Stephen Dawson-Haggerty a écrit : >>>>> Kris also brought up another good point which is that if the links >>>>> are aggressively duty cycled (we consider that likely) matters are >>>>> likely to be even worse. Also, most discussion in this group has not >>>>> considered point to point links; I don't believe they are prevalent >>>>> in this design space. >>>> >>>> I think the slower the link, and the higher latency, the more >>>> chances are it's a ptp link. I think some Bluetooth serial links >>>> are ptp. I think serial rs-232 is ptp. I think these are >>>> potentially used in this space. >> > >>> I've deployed countless networks with 76.8kbps and 250kbps raw bit >>> rate radios. In both cases, the typical duty cycle on the radio is >>> below 0.1%, for an effective link data rate of at most a few tens to >>> hundreds of bits per second, and latencies of very roughly 1 second >>> per hop. These networks contain hundreds of nodes, and are tens of >>> hops across. >> >> Is each hop-to-hop link a ptp link? I believe so: >> >> node<---ptplink---->node<----ptplink---->... >> 76kbps 76kbps > > I don't believe so... the link is both unicast- and broadcast- capable - > the latter may reach > 1 node (possibly hundreds) with just a single > transmission. Is the broadcast capability a link-layer capability or an IP-layer capability? Maybe IP sees it as a ptp link despite its physical broadcast nature? A difficult subnet structure may mean ND problems. A routing protocol could address them, but a better subnet structure is quicker to plan. Alex From John.E.Drake2@boeing.com Tue Feb 3 10:05:54 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 282B23A69C5 for ; Tue, 3 Feb 2009 10:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.267 X-Spam-Level: X-Spam-Status: No, score=-6.267 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 807KaX4liUGH for ; Tue, 3 Feb 2009 10:05:52 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 1088A3A6407 for ; Tue, 3 Feb 2009 10:05:52 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n13I5EYE022378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Feb 2009 12:05:14 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n13I5ERu021989; Tue, 3 Feb 2009 12:05:14 -0600 (CST) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n13I5BG9021894; Tue, 3 Feb 2009 12:05:14 -0600 (CST) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Feb 2009 10:05:11 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Feb 2009 10:05:09 -0800 Message-ID: <51661468CBD1354294533DA79E85955A016FDC93@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: <7F8459D1-3464-435A-AF8F-F9C437036FDF@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review andcomments draft-ietf-roll-protocols-survey-05.txt Thread-Index: AcmGJKrgf/CcwfaQR4yRHOMWEgNIMAABJ3Pg References: <20090127000001.9F1F03A6819@core3.amsl.com><7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <7F8459D1-3464-435A-AF8F-F9C437036FDF@cisco.com> From: "Drake, John E" To: "David Ward" , "ROLL WG" X-OriginalArrivalTime: 03 Feb 2009 18:05:11.0025 (UTC) FILETIME=[F47AF610:01C98629] X-Mailman-Approved-At: Tue, 03 Feb 2009 22:31:00 -0800 Cc: Arsalan Tavakoli , Geoff Mulligan , "David E. Culler" , stevedh@cs.berkeley.edu, mtownsley@cisco.com, Thomas Heide Clausen , Jari Arkko , Ross Callon Subject: Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review andcomments draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 18:05:54 -0000 Dave, This is a great e-mail. One of the things I especially like about it is that it touches on the cultural aspects of how the IETF does its work, viz, we have an iterative engineering approach in which things do not have to be perfect before proceeding. This discussion has been interminable. Thanks, John =20 >-----Original Message----- >From: David Ward [mailto:dward@cisco.com]=20 >Sent: Tuesday, February 03, 2009 8:52 AM >To: ROLL WG >Cc: Arsalan Tavakoli; Geoff Mulligan; David E. Culler;=20 >stevedh@cs.berkeley.edu; mtownsley@cisco.com; Thomas Heide=20 >Clausen; Jari Arkko; Ross Callon >Subject: Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ?=20 >Re: Review andcomments draft-ietf-roll-protocols-survey-05.txt > >All - > >We debated the delta between these three WGs when chartering=20 >ROLL for a considerable period of time. I do not want to=20 >revisit that debate but, I will quickly summarize here > >- 6LOWPAN is not working at the IP layer so, the overlap here=20 >is really not an issue. >- MANET is and has been working on routing protocols for=20 >mobile, ad hoc networks with specific requirements and use=20 >cases. Some of those use cases may or may not overlap with=20 >ROLL. There will be lessons to be learned but, the primary use=20 >cases being worked on appeared by all the chairs and ADs=20 >involved to be different enough to warrant a new WG in this area. >- ROLL was originally chartered to write the requirements and=20 >evaluate existing protocols for low power, lossy networks=20 >running over IP (some call these "sensor networks"). ROLL is=20 >only chartered to work on the routing protocol portion. Not=20 >the transport, encap or other topics at this time. Also note=20 >that mobility is not under consideration at this time. > >ROLL WG appears to have come to consensus on the requirement=20 >docs that state specific functions, attributes, power/memory=20 >envelope and algorithmic considerations that must be "in the=20 >routing protocol" for these networks. The survey ID (which is=20 >of course a snapshot at one point in time) puts some bounds on=20 >mapping the required functions, attributes and other=20 >considerations into protocols available *today.* > >Given the real work of designing a protocol hasn't begun by=20 >the ROLL WG participants; holding up the WG to begin taking=20 >what they currently defined as a very complex, multivariate=20 >problem and begin whittling it down to something solvable via=20 >theoretical and hypothetical exercises seems like an unwise=20 >use of time given the experience and energy of the WG in this=20 >problem space. The WG must move beyond the moderately=20 >high-level boundary setting exercise (which I believe there is=20 >consensus) and move onto the more challenging work of defining=20 >the objects, algorithms, semantics, state machines and=20 >functionality of the protocol. In the design phase (vs the=20 >survey phase) a better evaluation can be made of the ease or=20 >difficulty of "from scratch" or "modify what we have" can be=20 >made. I expect "wild swings" of the design pattern of the=20 >protocol during the first year of the design effort. I=20 >attempted to make this clear at the mic in Minneapolis that=20 >the current trajectory is very complex problem domain that=20 >hasn't born a lot of fruit but, that in the design phase=20 >reducing the complexity must occur. Members of the WG who have=20 >vast experience in these types of networks and have widely=20 >deployed products have stated that the routing protocol issues=20 >are solvable problems with some simplifying assumptions. I=20 >look forward to the WG making these design decisions and=20 >tradeoffs and debating the structure of the protocol. Any=20 >protocol reuse, experience, etc will be critical at this point=20 >to make the correct choices and I look to MANET, ROLL, MEXT,=20 >6LOWPAN and other IETF'ers with routing protocol experience to=20 >contribute. This is an industry important juncture and moving=20 >LPLN to IP is a critical change. > >I am looking to the WG chairs to declare loose consensus on=20 >the documents (when appropriate) so that the rechartering of=20 >the WG to enter the design phase can occur. WIthout a doubt,=20 >the requirements as-is have defined the boundary of the work=20 >effort and I believe it is clear what is the difference=20 >between the WGs. > > >HIH > >-DWard > > > > >On Feb 3, 2009, at 7:14 AM, Thomas Heide Clausen wrote: > > > Dear JP, dear ADs, dear WG, > > (I Cc the other INT chair, as he's following 6lowpan) > > For the record, I am not arguing that MANET protocols=20 >should be applied or be applicable -- as you seem to suggest=20 >in your email. I believe that I have stated so repeatedly. > > I submit, however, that as it is currently exposed,=20 >ROLL, MANET and 6LOW seem to be operating within the same=20 >space -- to the untrained eye, in exactly the same space. My=20 >position is that it would be very unfortunate having one WG=20 >creating confusion on the applicability of the work of itself=20 >and of other IETF wg's, by simple omission of suitable=20 >perimeter definitions.=20 > > In that sort of situation, the IETF needs to be extra=20 >prudent to make sure to clearly spell out suitable perimeter=20 >definitions prior to, or conjointly with, the first=20 >publication cycle. In this case, before or with the survey I-D. > > Sincerely, > > Thomas > > > On Feb 3, 2009, at 1:19 PM, JP Vasseur wrote: > > > Dear WG and ADs, > > Two issues are raised here for which we would=20 >appreciate ADs' point of view and feed-back from the WG.=20 >Please see in line. > > > Dear Thomas, > > At the risk of repeating myself, I'd like to=20 >make a few important statements before *hopefully* come to a=20 >closure ;-) > > -> As you know, many of the ROLL WG active=20 >participants have been working quite hard to produce a=20 >detailed set of requirements, discuss how to proceed on the=20 >protocol survey document, and other ID are in the works. > -> We managed to get highly experienced=20 >contributors in the field that have designed and deployed=20 >solutions so they not only have an excellent expertise of the=20 >requirements but also on solutions, > -> Yes we need to rush out. Why ? Because=20 >proprietary or semi-closed non-IP solutions are being deployed=20 >at a fairly large scale. I do not think that I have to=20 >convince anybody on this list that this is the WRONG approach=20 >for a number of reasons. The industry is asking for an IP=20 >solution *now*. > -> No we do not want to re-invent the wheel=20 >(see our presentation at the routing plenary in Chicago).=20 >Anything that already exists MUST (rfc2119 ;-)) be used=20 >provided that it meets our requirements. And if we can adapt=20 >an existing protocol, we are all for it ! > -> Yes these requirements are quite specifics=20 >and this is precisely why ROLL has been formed, 4=20 >application-specific routing requirements have been produced=20 >(to reduce the scope). Even if at a first sight, it looks very=20 >much similar to a MANET issue (and there ARE similarities but=20 >also very different requirements), having to deal with a=20 >highly static network of hundreds of thousands of battery=20 >operated sleeping nodes with 4K of RAM is quite specific. Note=20 >that this is not a random example, but an on-going non-IP=20 >deployed network. > > And to conclude on this introduction ... after=20 >an outstanding progress on the WG during the first 6-8 months,=20 >we have been slowed down dramatically for the last 2 months,=20 >thus it is time to close and move on to quickly re-charter and=20 >start the protocol work (hopefully as light as possible) to=20 >see IP-based solution deployed. I know that we are on the same=20 >page, we just need to find a good compromise on both "sides". > > Nothing new so far, let's move to a proposed=20 >resolution - See in line, > > On Feb 2, 2009, at 7:37 PM, Thomas Heide Clausen wrote: > > > All, > =09 > I promised a review, and I apologize=20 >that I wasn't able to do so before the weekend as originally projected. > =09 > Other than some typos that Chris and=20 >others have pointed out, I'll try to offer my understanding of=20 >the problem space and suggest some ways of addressing my main=20 >concerns.... > =09 > My first main concern remain that it is=20 >not clear, still, how ROLL positions itself with respect to=20 >MANET, 6LOW et. al, all of which appear to be within the same=20 >space and within the IETF. This I-D sees ROLL as presented=20 >with entirely new problems (the use of "novel" in the=20 >abstract, the statement that "existing protocols were not=20 >designed with these requirements in mind" seem to confirm this). > =09 > Looking at the requirements listed,=20 >including "low power, low bandwidth, low footprint", these=20 >appear similar to those which are also brought forward in e.g.=20 >MANET and 6LOW. Reading (quickly, I confess) the various=20 >requirements documents of the draft-ietf-roll series present=20 >scenarios which are similar to those where MANETs are=20 >deployed, and are thought deployed, as well. > =09 > I also note that many additional (and=20 >unstated) characteristics between ROLL and e.g. MANET are the=20 >same: mobile, wireless, fragility, auto-configuration, IP=20 >routing, interface/link issues... > =09 > Arguing that, as does this I-D, despite=20 >the above impression "ROLL is novel and different" invites=20 >asking "how, exactly?" I think that this question is valid,=20 >and merits being answered, before the evaluations in this I-D=20 >can be judged fairly. > =09 > Note that I come from a MANET=20 >background, and so I *could* interpret from the ROLL=20 >discussion that where MANETs may aim for "low power, low=20 >bandwidth, ....", ROLL may be able to quantify these as "below=20 >this firm threshold" -- i.e. as a sort of "extreme" or=20 >"constrained" MANET. > =09 > This is a personal observation, I note,=20 >which would allow me to comprehend how ROLL and MANET are=20 >positioned relative to one another -- but one which neither=20 >this I-D nor the requirements document spell out or quantify=20 >-- or, for that matter, debunk. > =09 > I think it's critical to understand=20 >this, in order to understand the need for a new protocol=20 >development. I think it is important to document this=20 >understanding in something with more persistency. > =09 > If what I suggest above makes sense as=20 >a way of positioning ROLL and MANET relative to one another,=20 >I'd suggest including something to this effect in the survey=20 >I-D, as this I-D is the one making a *direct* reference to the=20 >applicability of MANET protocols to ROLL. > =09 > If what I suggest doesn't make sense at=20 >all, then I'd be happy to have it debunked and, hopefully,=20 >through that debunking a positioning/description that does=20 >ring true with us all can be produced? > =09 > My second main concern is, that I still=20 >think that the choice of criteria is unfortunate (not the=20 >word, Phill has me convinced on that front, but the actual=20 >criteria). Control cost is, by all means, a rather meaningless=20 >criteria when taken in isolation. I've sketched a=20 >"zero-control-cost" routing protocol (flood all data - say use=20 >SMF, also a MANET protocol, and also a rather "mature" I-D and=20 >wg item) which would score well on the control cost criteria,=20 >but would likely be an extremely bad choice for delivering=20 >unicast data. > =09 > The metric which matters, and which=20 >should matter to ROLL in particular, is "the total cost of=20 >getting user data through the network, including control cost=20 >necessary to set up paths" -- as we know, every packet sent=20 >and received costs bandwidth, energy and cycles -- user data=20 >no different from contro. > =09 > According to the criterions as set up=20 >by this I-D, a protocol producing "longer than shortest paths"=20 >at the benefit of slightly lower control cost would score=20 >better than a protocol producing "shortest paths" with=20 >slightly higher control cost. This is not hypothetical, btw.,=20 >there are plenty of studies observing and reflecting upon this=20 >regarding the different MANET protocols, in academic=20 >literature -- and observed in real networks as well. > =09 > I note that this trade-off (slightly=20 >longer paths for lower control cost) may be perfectly fair,=20 >assuming that very low amounts of user data traffic transit=20 >through the network. However, I do not see this assumption=20 >mentioned as a justification for focusing on the control cost=20 >metric and discarding the "path length" or the "total cost of=20 >getting user data through the network". > =09 > I believe that either these assumptions=20 >should be made explicit ("there's so little user data traffic=20 >in a ROLL network that we do not care about shortest paths")=20 >or -- if these assumptions do not hold, that the evaluation=20 >criteria are incomplete. > =09 > I note that it's true that we can=20 >always add another criteria ad infinitum, and that's CLEARLY=20 >not what we want to do. However when I say "incomplete" in the=20 >above, I simply suggest that based on what is presented one=20 >cannot draw conclusions based on the evaluation=20 >criteria....or, worse, that one draws the wrong conclusions=20 >based on the information presented. > > > It is not easy to answer each of your point=20 >without running the risk to start a debate that will never=20 >end. You raised some excellent points that I agree with and=20 >others that I firmly disagree with ... So let me try to make a=20 >few observations: > 1) As pointed out earlier, yes there are=20 >similarities between MANET and ROLL. I do not see this as an issue. > 2) The aim of the protocol survey IS NOT to=20 >exclude MANET protocols. As mentioned many times on the list,=20 >we *only* wanted to show that existing protocols, with no=20 >change, could not be used in LLNs. This has been clarified in=20 >the document as your request and it HAD to be clarified. > 3) We could have used two different approaches=20 >for the survey: > - Look at all MUST from the requirements documents > =09 > - Try to derive a subset of necessary but not=20 >sufficient criteria, which the WG chose to do (consensus). Yes=20 >this list is not perfect, > =09 > criteria could be changed, removed or added but=20 >looked good enough with excellent consensus until LC. > =09 > 4) With regards to 6lowpan (I copy the chair),=20 >I do not see any overlap at all. Please refer to their charter=20 >and WG items. The only place that required clarification was=20 >the routing requirements and I was personally opposed to it=20 >but this was adopted as a 6lowpan WG item by consensus. We're=20 >are working together and managed to sort this out. This=20 >document will be 6lowpan specific. > > What I want to avoid is an endless discussion=20 >on the positioning of ROLL, MANET, 6lowpan and quite frankly=20 >we could add other WGs to the list. > > So what is the bottom line ? > > We just need to agree on the fact that there is=20 >no existing protocol that meets the ROLL requirements and move=20 >to the next step (re-chartering) to select one (hopefully not=20 >two) routing protocols in light of the routing requirement=20 >(NOT the protocol survey), which can either be an adapted=20 >MANET protocol or a new protocol. > > Now moving to your proposed resolution. > > > > > So, in a nutshell, I suggest that we=20 >address (i) the positioning issue and (ii) the criteria issue thus: > =09 > o Describe as I proposed above if ROLL=20 >and MANETs position themselves as I > have deducted. If my deduction is=20 >incorrect, then let's quickly iterate on the list > as to understand how to do produce an=20 >alternative description. If we can't do this, > then the conclusion can be that "we do=20 >not know how ROLL and MANET position > themselves wrt each other", and we=20 >could then state that clearly? > =09 > It *should* not be more than a couple=20 >of paragraphs worth of text to add, I gather? > =09 > =09 > > > If you find a way to word this, please feel=20 >free and I'd be happy to help but feel it as necessary ... Any=20 >opinion from our RTG and INT ADs ? > > > o To the criteria, either of: > =09 > - Add the assumption that "user data=20 >traffic is so low that path lengths do not > matter nor does the cost of carrying=20 >user data traffice" > =09 > =09 > > > The motivation for selecting a longer path is=20 >not tied to the amount of traffic here but the level of=20 >constraints. Note that this is also true for several other=20 >technologies such as MPLS-TE. You may have large amount of=20 >traffic and still require to follow a non-shortest path=20 >(constrained based routing). This is detailed in several=20 >requirements IDs. Criticality of data is of course different,=20 >thus the requirements for potentially different data paths=20 >according to packet marking using DSCP. > > > - Add a criteria & evaluation of "path length" > =09 > - Add a criteria & evaluation of "total=20 >cost for getting user data through the network" > =09 > =09 > > > And we can add many more but if the current=20 >protocol do not satisfy existing requirements, isn't it=20 >sufficient to answer the question on whether one can find an=20 >existing protocol? > > > This would make a large chunk of my=20 >concerns and issues vanish, and allow correctly interpreting=20 >and evaluating the rest of the document. > > > That said, question for the WG. Who think that=20 >such criteria should be added to move forward ? Please reply. > > > > > How does that sound as an approach forward? > =09 > =09 > > > Thanks for helping out. > > Cheers. > > JP. > > > Cheers, > =09 > Thomas > =09 > On Jan 27, 2009, at 1:00 AM,=20 >Internet-Drafts@ietf.org wrote: > =09 > =09 > > A New Internet-Draft is=20 >available from the on-line Internet-Drafts > =09 > > directories. > =09 > > This draft is a work item of=20 >the Routing Over Low power and Lossy networks Working Group of=20 >the IETF. > =09 > > > Title : Overview of Existing=20 >Routing Protocols for Low Power and Lossy Networks > =09 > > Author(s) : A. Tavakoli, S.=20 >Dawson-Haggerty, P. Levis > =09 > > Filename :=20 >draft-ietf-roll-protocols-survey-05.txt > =09 > > Pages : 26 > =09 > > Date : 2009-1-26 > =09 > > =09 > =09 > > Networks of low power wireless=20 >devices introduce novel IP routing > =09 > > issues. Low-power wireless=20 >devices, such as sensors, actuators and > =09 > > smart objects, have difficult=20 >constraints: very limited memory, > =09 > > little processing power, and=20 >long sleep periods. As most of these > =09 > > devices are battery-powered,=20 >energy efficiency is critically > =09 > > important. Wireless link=20 >qualities can vary significantly over time, > =09 > > requiring protocols to make=20 >agile decisions yet minimize topology > =09 > > change energy costs. Routing=20 >over such low power and lossy networks > =09 > > has novel requirements that=20 >existing protocols may not address. This > =09 > > document provides a brief=20 >survey of the strengths and weaknesses of > =09 > > existing protocols with=20 >respect to this class of networks. From this > =09 > > survey it examines whether=20 >existing and mature IETF protocols can be > =09 > > used without modification in=20 >these networks, or whether further work > =09 > > is necessary. > =09 > > is necessary. > =09 > > > A URL for this Internet-Draft is: > =09 > > =09 >http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-s >urvey-05.txt > =09 > > > Internet-Drafts are also=20 >available by anonymous FTP at: > =09 > > ftp://ftp.ietf.org/internet-drafts/ > =09 > > > Below is the data which will=20 >enable a MIME compliant mail reader > =09 > > implementation to automatically=20 >retrieve the ASCII version of the > =09 > > Internet-Draft. > =09 > > Content-Type: text/plain > =09 > > Content-ID:=20 ><2009-1-26155804.I-D@ietf.org> > =09 > > > =09 >_______________________________________________ > =09 > > Roll mailing list > =09 > > Roll@ietf.org > =09 > > =09 >https://www.ietf.org/mailman/listinfo/roll > =09 > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > =09 > > > > > From chris.dearlove@baesystems.com Wed Feb 4 01:59:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FD2C3A67AD for ; Wed, 4 Feb 2009 01:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2WpVBW64mwm for ; Wed, 4 Feb 2009 01:59:49 -0800 (PST) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 3DF523A6820 for ; Wed, 4 Feb 2009 01:59:48 -0800 (PST) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n149xP5v028864 for ; Wed, 4 Feb 2009 09:59:26 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n149xP7n021934 for ; Wed, 4 Feb 2009 09:59:25 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 04 Feb 2009 09:59:14 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 4 Feb 2009 09:59:24 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Feb 2009 09:59:22 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review andcomments draft-ietf-roll-protocols-survey-05.txt Thread-Index: AcmGJoQBBQZo/8VNQAOnWEnZoFEkRgAh4cqA References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498874A8.9030206@ekasystems.com> From: "Dearlove, Christopher (UK)" To: "JP Vasseur" X-OriginalArrivalTime: 04 Feb 2009 09:59:24.0812 (UTC) FILETIME=[42658CC0:01C986AF] Cc: ROLL WG Subject: Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review andcomments draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 09:59:53 -0000 >> That is a little simplistic. Let's suppose that the document said >> that protocol X is a bad protocol, totally unsuited for ROLL or any >> other work. > I hope that you do not interpret the conclusion on the suitability of a > protocol to a specific issue as "this protocol is BAD". No, that was a hypothetical. The argument I meant was that, whether or not you wqnt it to, the document has non-ROLL implications. That would be an example of where they were clearly unacceptable. But as I later say >> Now the ROLL document doesn't say protocol X is a bad protocol for >> any X. Any disagreement is not at that level. > It will not, the survey is quite clear on this. We can make sure to =20 > add 1-2 sentences very explicitly if you will. It's not to me to address that, but rather where the issues are coming from. (I haven't followed the details - and there are 30 unread posts after this one - on whether the DYMO comments are now to everyone's satisfaction.) > Informational RFC with limited scope (very explicitly pointed out in =20 > the I-D). Still an RFC, and a reason why if it comments in an area it needs to be basically right (some fine details may not be critical). But I'm not proposing any specific changes for such a reason, though others may be (or not, I've lost track). ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From jbu@zen-sys.com Wed Feb 4 02:14:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8978128C1A9 for ; Wed, 4 Feb 2009 02:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijutURbZuFTv for ; Wed, 4 Feb 2009 02:14:56 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id ECD6A3A6801 for ; Wed, 4 Feb 2009 02:14:55 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C986B1.6172BD84" Date: Wed, 4 Feb 2009 11:14:35 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3EFC8185@zensys17.zensys.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review andcomments draft-ietf-roll-protocols-survey-05.txt Thread-Index: AcmF+lktBMjYwsxZSSW5VDo/ZEk/cAAtpBiw References: <20090127000001.9F1F03A6819@core3.amsl.com><7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> From: "Jakob Buron" To: "JP Vasseur" , "ROLL WG" Subject: Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review andcomments draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 10:14:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C986B1.6172BD84 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I completely agree with JPs comments - ROLL needs to move on. The ongoing discussion of the protocol survey draft is counter-productive, and I support closing it so we can proceed. =20 /jakob ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: 3. februar 2009 13:20 To: ROLL WG; Thomas Heide Clausen; David Ward; Ross Callon; mtownsley@cisco.com; jari.arkko@piuha.net Cc: Arsalan Tavakoli; Geoff Mulligan; David E. Culler; stevedh@cs.berkeley.edu Subject: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review andcomments draft-ietf-roll-protocols-survey-05.txt =09 =09 Dear WG and ADs, =09 =09 Two issues are raised here for which we would appreciate ADs' point of view and feed-back from the WG. Please see in line. Dear Thomas,=20 At the risk of repeating myself, I'd like to make a few important statements before *hopefully* come to a closure ;-) -> As you know, many of the ROLL WG active participants have been working quite hard to produce a detailed set of requirements, discuss how to proceed on the protocol survey document, and other ID are in the works. -> We managed to get highly experienced contributors in the field that have designed and deployed solutions so they not only have an excellent expertise of the requirements but also on solutions, -> Yes we need to rush out. Why ? Because proprietary or semi-closed non-IP solutions are being deployed at a fairly large scale. I do not think that I have to convince anybody on this list that this is the WRONG approach for a number of reasons. The industry is asking for an IP solution *now*. -> No we do not want to re-invent the wheel (see our presentation at the routing plenary in Chicago). Anything that already exists MUST (rfc2119 ;-)) be used provided that it meets our requirements. And if we can adapt an existing protocol, we are all for it ! -> Yes these requirements are quite specifics and this is precisely why ROLL has been formed, 4 application-specific routing requirements have been produced (to reduce the scope). Even if at a first sight, it looks very much similar to a MANET issue (and there ARE similarities but also very different requirements), having to deal with a highly static network of hundreds of thousands of battery operated sleeping nodes with 4K of RAM is quite specific. Note that this is not a random example, but an on-going non-IP deployed network. =09 =09 And to conclude on this introduction ... after an outstanding progress on the WG during the first 6-8 months, we have been slowed down dramatically for the last 2 months, thus it is time to close and move on to quickly re-charter and start the protocol work (hopefully as light as possible) to see IP-based solution deployed. I know that we are on the same page, we just need to find a good compromise on both "sides". =09 =09 Nothing new so far, let's move to a proposed resolution - See in line,=20 =09 [...]=20 =20 ------_=_NextPart_001_01C986B1.6172BD84 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 completely agree with JPs comments - ROLL needs to move = on. The ongoing discussion of the protocol survey draft is=20 counter-productive, and I support closing it so we can=20 proceed.
 
/jakob
From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On Behalf Of JP = Vasseur
Sent:=20 3. februar 2009 13:20
To: ROLL WG; Thomas Heide Clausen; = David Ward;=20 Ross Callon; mtownsley@cisco.com; jari.arkko@piuha.net
Cc: = Arsalan=20 Tavakoli; Geoff Mulligan; David E. Culler;=20 stevedh@cs.berkeley.edu
Subject: [Roll] * ALL PLEASE READ ** = TIME=20 FOR CLOSURE ? Re: Review andcomments=20 draft-ietf-roll-protocols-survey-05.txt

Dear WG and ADs,

Two issues are raised here for which we would appreciate ADs' = point of=20 view and feed-back from the WG. Please see in line.


Dear Thomas,

At the risk of repeating myself, I'd like to make a few important = statements before *hopefully* come to a closure ;-)

-> As you know, many of the ROLL WG active participants have = been=20 working quite hard to produce a detailed set of requirements, discuss = how to=20 proceed on the protocol survey document, and other ID are in the = works.
-> We managed to get highly experienced contributors in the = field that=20 have designed and deployed solutions so they not only have = an=20 excellent expertise of the requirements but also on solutions,
-> Yes we need to rush out. Why ? Because proprietary or=20 semi-closed non-IP solutions are being deployed at a fairly large = scale. I do=20 not think that I have to convince anybody on this list that this is = the WRONG=20 approach for a number of reasons. The industry is asking for an IP = solution=20 *now*.
-> No we do not want to re-invent the wheel (see our = presentation at=20 the routing plenary in Chicago). Anything that already exists MUST = (rfc2119=20 ;-)) be used provided that it meets our requirements. And if we can = adapt an=20 existing protocol, we are all for it !
-> Yes these requirements are quite specifics and this is = precisely=20 why ROLL has been formed, 4 application-specific routing requirements = have=20 been produced (to reduce the scope). Even if at a first sight, it = looks very=20 much similar to a MANET issue (and there ARE similarities but also = very=20 different requirements), having to deal with a highly static network = of=20 hundreds of thousands of battery operated sleeping nodes with 4K of = RAM is=20 quite specific. Note that this is not a random example, but an = on-going non-IP=20 deployed network.

And to conclude on this introduction ... after an outstanding = progress on=20 the WG during the first 6-8 months, we have been slowed down = dramatically for=20 the last 2 months, thus it is time to close and move on to quickly = re-charter=20 and start the protocol work (hopefully as light as possible) to see = IP-based=20 solution deployed. I know that we are on the same page, we just need = to find a=20 good compromise on both "sides".

Nothing new so far, let's move to a proposed resolution - See in=20 line, 
[...] 
 
------_=_NextPart_001_01C986B1.6172BD84-- From m1gs4n@gmail.com Wed Feb 4 03:20:30 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F24728C1ED for ; Wed, 4 Feb 2009 03:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ly1MDDktRaEY for ; Wed, 4 Feb 2009 03:20:29 -0800 (PST) Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by core3.amsl.com (Postfix) with ESMTP id 23A1C28C1E4 for ; Wed, 4 Feb 2009 03:20:28 -0800 (PST) Received: by fxm13 with SMTP id 13so3009180fxm.13 for ; Wed, 04 Feb 2009 03:20:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=EbKe5PKW6Hluq1eySSwU1yeNktweVQpLN3BM0fC+qKg=; b=VIUdJ/lrwF/UrqldwdqaK75X9gowTvIKO/yU45XN4UbkCR65iMHtFEddho5TrP7mb/ 0RtMLrZWQH30X5ByBv7D/s8hIk+9XAdobQuVYHuzgRwNd+A4xUJDsqyEXVJMWY2EVNCf foClxQC0fzDTAnCqRO8pKeOiOr57iqFHzUL40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; b=Ce9tRmjmZ6IQojqHDb/oSv5JvMyNnPHV+P0wwS7g9pJcX+fsC3jnxUxo9Y+FMw7qpi 9y8wyseOAFVZGLVBAuvu2rpfByD0FE6N0ZF7N09ZgSAx3ETaMmlEkHs6Sk1jW+TsL8I/ MibKlecQN+WZpkWW9OFXHnMELYLxkc68jOR1o= MIME-Version: 1.0 Received: by 10.181.192.10 with SMTP id u10mr1131808bkp.185.1233746408543; Wed, 04 Feb 2009 03:20:08 -0800 (PST) In-Reply-To: References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <7F8459D1-3464-435A-AF8F-F9C437036FDF@cisco.com> Date: Wed, 4 Feb 2009 12:20:08 +0100 Message-ID: <86c3ed7b0902040320r171c36ffl5b04f6ae92222040@mail.gmail.com> From: =?ISO-8859-1?Q?Miguel_S=E1nchez?= To: JP Vasseur , ROLL WG Content-Type: multipart/alternative; boundary=00504502a30c6c9496046215f89b Subject: Re: [Roll] If possible ... X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: m1gs4n@gmail.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 11:20:30 -0000 --00504502a30c6c9496046215f89b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, The survey can be improved, but it's good enough for me. So my vote is to close it now. Cheers, Miguel S=E1nchez On Tue, Feb 3, 2009 at 11:20 PM, JP Vasseur wrote: > Dear all, > Great to see all these discussions, but in light of the discussions today= I > would like to *converge* - I did propose a plan (below). Until we have > concluded on the protocol survey (we're close) and re-chartering (coming > soon), can we focus the discussion, it goes in all directions. > > Many Thanks. > > JP. > > --00504502a30c6c9496046215f89b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

The survey can be improved, but it's good enough for me.= So my vote is to close it now.

Cheers,

Miguel S=E1nchez
<= br>
On Tue, Feb 3, 2009 at 11:20 PM, JP Vasse= ur <jvasseur@cis= co.com> wrote:
<= div style=3D"">Dear all,

Great to see all these discussi= ons, but in light of the discussions today I would like to *converge* - I d= id propose a plan (below). Until we have concluded on the protocol survey (= we're close) and re-chartering (coming soon), can we focus the discussi= on, it goes in all directions.

Many Thanks.

JP.

--00504502a30c6c9496046215f89b-- From root@core3.amsl.com Wed Feb 4 04:00:01 2009 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A13FE28C1ED; Wed, 4 Feb 2009 04:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090204120001.A13FE28C1ED@core3.amsl.com> Date: Wed, 4 Feb 2009 04:00:01 -0800 (PST) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-building-routing-reqs-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 12:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Building Automation Routing Requirements in Low Power and Lossy Networks Author(s) : J. Martocci, et al. Filename : draft-ietf-roll-building-routing-reqs-05.txt Pages : 29 Date : 2009-02-04 The Routing Over Low power and Lossy network (ROLL) Working Group has been chartered to work on routing solutions for Low Power and Lossy networks (LLN) in various markets: Industrial, Commercial (Building), Home and Urban. Pursuant to this effort, this document defines the routing requirements for building automation. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-building-routing-reqs-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-building-routing-reqs-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-04035836.I-D@ietf.org> --NextPart-- From jvasseur@cisco.com Wed Feb 4 04:03:08 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1236F28C1F6 for ; Wed, 4 Feb 2009 04:03:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.385 X-Spam-Level: X-Spam-Status: No, score=-10.385 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqoDukJgEqWX for ; Wed, 4 Feb 2009 04:03:06 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id BFECC28C24A for ; Wed, 4 Feb 2009 04:01:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,378,1231113600"; d="scan'208,217";a="32813489" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 04 Feb 2009 12:01:24 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n14C1OKB017062; Wed, 4 Feb 2009 13:01:24 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n14C1OJa027478; Wed, 4 Feb 2009 12:01:24 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Feb 2009 13:01:24 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Feb 2009 13:01:23 +0100 Message-Id: From: JP Vasseur To: Jerald.P.Martocci@jci.com In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-70--108871349 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 4 Feb 2009 13:01:22 +0100 References: X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 04 Feb 2009 12:01:23.0563 (UTC) FILETIME=[4CB653B0:01C986C0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9946; t=1233748884; x=1234612884; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20I-D=20Action=3Adraft-ietf-roll -building-routing-reqs-04.txt |Sender:=20; bh=oD8J6kF9Op9uBamjLDgGRB8Rh2seYUSQ89jCpp6MJZg=; b=r/9csAKnaGx9sFbAetuUBAdMIz7t1dxGmAdBD7QQyQv5nzWxYO33H5K4GD 6DjoMqcsXL+15ECKgA/QOx1ZkmgKLHgQ5euLUXDpcgiTKIN96eDvuJ5w8Hoh wBZHeKRAal; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-building-routing-reqs-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 12:03:08 -0000 --Apple-Mail-70--108871349 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Jerry et all, Thanks for having addressed all comments from various people during LC. I made a very final pass and fixed a few minor issues found during IDNits (used references, SHOULD not => SHOULD NOT ...), thus this revision 05 that I just posted, now ready for publication. This closes our series of ROLL routing requirements documents. Thanks. JP. On Feb 3, 2009, at 11:47 PM, Jerald.P.Martocci@jci.com wrote: > > All, > > The -04 version of the Building Requirements document has just been > posted. The -04 document incorporates only three minor changes from > -03 ... > > 1) The 'Parallel Download' requirement has been moved from the > requirements section of the draft body to Appendix A. JP had > requested this change. I agreed in that this requirement is not a > routing requirement. > > 2) The 'Security' section of the draft was reworded to discuss > network security requirements as they relate to routing. The prior > draft was not clear which of the security requirements were related > to routing. > > 3) I reread the entire draft and cleaned up a few remaining > grammatical errors. I also reordered the requirements in Appendix A > in what I believe is a priority order. they had been in > chronological order in the -03 draft. > > Jerry > > > > > > > Internet-Drafts@ietf.org > Sent by: roll-bounces@ietf.org > 02/03/2009 04:29 PM > > To > i-d-announce@ietf.org > cc > roll@ietf.org > Subject > [Roll] I-D Action:draft-ietf-roll-building-routing-reqs-04.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Routing Over Low power and Lossy > networks Working Group of the IETF. > > > Title : Building Automation Routing > Requirements in Low Power and Lossy Networks > Author(s) : J. Martocci, et al. > Filename : draft-ietf-roll-building-routing- > reqs-04.txt > Pages : 29 > Date : 2009-02-03 > > The Routing Over Low power and Lossy network (ROLL) Working Group has > been chartered to work on routing solutions for Low Power and Lossy > networks (LLN) in various markets: Industrial, Commercial (Building), > Home and Urban. Pursuant to this effort, this document defines the > routing requirements for building automation. > > Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC-2119. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-building-routing-reqs-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-roll-building-routing-reqs-04.txt_______________________________________________ > 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 --Apple-Mail-70--108871349 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Jerry et = all,

Thanks for having addressed all comments from = various people during LC. I made a very final pass and fixed a few minor = issues found during IDNits (used references, SHOULD not =3D> SHOULD NOT = ...), thus this revision 05 that I just posted, now ready for = publication. This closes our series of ROLL routing requirements = documents.

Thanks.

JP.

On Feb 3, 2009, at 11:47 PM, Jerald.P.Martocci@jci.com = wrote:


All,
=
The -04 version of the Building = Requirements document has just been posted.  The -04 document = incorporates only three minor changes from -03 ...

1) The 'Parallel Download' requirement = has been moved from the requirements section of the draft body to = Appendix A.  JP had requested this change.  I agreed in that = this requirement is not a routing requirement.

2) The 'Security' section of the draft = was reworded to discuss network security requirements as they relate to = routing.  The prior draft was not clear which of the security = requirements were related to routing.

3) I reread the entire draft and cleaned up a few = remaining grammatical errors.  I also reordered the requirements in = Appendix A in what I believe is a priority order.  they had been in = chronological order in the -03 draft.

Jerry






=
Internet-Drafts@ietf.org =
Sent by: roll-bounces@ietf.org

<= font size=3D"1" face=3D"sans-serif">02/03/2009 04:29 PM =

To
i-d-announce@ietf.org =
cc
roll@ietf.org
Subject
[Roll] I-D = Action:draft-ietf-roll-building-routing-reqs-04.txt

=


=

A New Internet-Draft is available from the = on-line Internet-Drafts directories.
This draft is a work item of = the Routing Over Low power and Lossy networks Working Group of the = IETF.


              =   Title           : Building Automation = Routing Requirements in Low Power and Lossy Networks
    =             Author(s)       = : J. Martocci, et al.
            =     Filename        : = draft-ietf-roll-building-routing-reqs-04.txt
      =           Pages         =   : 29
                = Date            : 2009-02-03

The = Routing Over Low power and Lossy network (ROLL) Working Group has
= been chartered to work on routing solutions for Low Power and Lossy
= networks (LLN) in various markets: Industrial, Commercial (Building), =
Home and Urban. Pursuant to this effort, this document defines the =
routing requirements for building automation.

= Requirements Language

The key words "MUST", "MUST NOT", = "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", = "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be = interpreted as described in RFC-2119.

A URL for this = Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-buildi= ng-routing-reqs-04.txt

Internet-Drafts are also available = by anonymous FTP at:
ftp://ftp.ietf.org/internet-d= rafts/

Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of the
Internet-Draft.
ftp://anonymous@ftp.ietf.org/internet-drafts/draf= t-ietf-roll-building-routing-reqs-04.txt_______________________________________________
Roll = mailing list
Roll@ietf.org
= https://www.ietf.org/m= ailman/listinfo/roll
 =
_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-70--108871349-- From pthubert@cisco.com Wed Feb 4 07:00:04 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87F673A6937 for ; Wed, 4 Feb 2009 07:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.952 X-Spam-Level: X-Spam-Status: No, score=-9.952 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_00=-2.599, J_BACKHAIR_44=1, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNLYqdJ5qDNv for ; Wed, 4 Feb 2009 07:00:03 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2F2CD3A6857 for ; Wed, 4 Feb 2009 07:00:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,379,1231113600"; d="scan'208";a="32839070" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 04 Feb 2009 14:59:42 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n14ExfxF028089; Wed, 4 Feb 2009 15:59:41 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n14ExfJx004763; Wed, 4 Feb 2009 14:59:41 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Feb 2009 15:59:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Feb 2009 15:59:36 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC06EC3823@xmb-ams-337.emea.cisco.com> In-Reply-To: <4988D73F.7040303@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Review and comments Re:I-D ACTION:draft-ietf-roll-protocols-survey-05.txt Thread-Index: AcmGWcwADMKSpyjrTwO6WUTnGmRrdAAfhswg References: <20090127000001.9F1F03A6819@core3.amsl.com><498852C5.1050503@gmail.com><69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com><498867F8.6000802@gmail.com><49887E75.1090705@gmail.com><44680fe70902030943q416b0908occe4dbc6b1a331e8@mail.gmail.com><498883C1.4070703@gmail.com><44680fe70902031147i3f0a30d8hc1b86c091dfb2792@mail.gmail.com><4988AEF0.20803@gmail.com><44680fe70902031258o54190cfdl6e5ce794e9b61e12@mail.gmail.com><4988B4BF.8020000@gmail.com> <4988C110.4090902@eecs.berkeley.edu><4988C703.6090805@gmail.com><7673A863-F3BF-4499-993E-1AEA59CA192B@archrock.com> <4988D73F.7040303@gmail.com> From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" , "Jonathan Hui" X-OriginalArrivalTime: 04 Feb 2009 14:59:41.0766 (UTC) FILETIME=[35568E60:01C986D9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2808; t=1233759581; x=1234623581; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20Review=20and=20comments=20Re=3 AI-D=09ACTION=3Adraft-ietf-roll-protocols-survey-05.txt |Sender:=20; bh=ntFCFozhh3+wQR1js5mC9iPAvSfTGebycVJ3kPnNlus=; b=bjwzLW59NFLOXxlsw5FaMgcQWnINuaK8Fp+o/6urDRiA+dgosA0fqQm4lc xWT6BPsv3mjsfzBSNzNdS1QRHhK8K6kfWhYIJUspb7RMXBbj/dMYaKKkKtf3 RPHSsv2ItC; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG Subject: Re: [Roll] Review and comments Re:I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 15:00:04 -0000 Hi Alex: I expect that peer discovery won't be very different from current ND or = hello. So there's no ruling ND out of the story.=20 What is new is a node density factor that we will have to address. For = instance, Trickle is discussed at 6LoWPAN for that exact reason. Power = Control / management is also critical for that matter. AFAIK, 6LoWPAN proposes a ND model that can be extended the way MANEMO = extended traditional ND so it can be considered in the solution space... = once we recharter.=20 Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Alexandru Petrescu >Sent: mercredi 4 f=E9vrier 2009 00:46 >To: Jonathan Hui >Cc: ROLL WG >Subject: Re: [Roll] Review and comments Re:I-D = ACTION:draft-ietf-roll-protocols-survey-05.txt > >Jonathan Hui a =E9crit : >> >> On Feb 3, 2009, at 2:36 PM, Alexandru Petrescu wrote: >>> Kris Pister a =E9crit : >>>> Alexandru Petrescu wrote: >>>>> Stephen Dawson-Haggerty a =E9crit : >>>>>> Kris also brought up another good point which is that if the = links >>>>>> are aggressively duty cycled (we consider that likely) matters = are >>>>>> likely to be even worse. Also, most discussion in this group has = not >>>>>> considered point to point links; I don't believe they are = prevalent >>>>>> in this design space. >>>>> >>>>> I think the slower the link, and the higher latency, the more >>>>> chances are it's a ptp link. I think some Bluetooth serial links >>>>> are ptp. I think serial rs-232 is ptp. I think these are >>>>> potentially used in this space. >>> > >>>> I've deployed countless networks with 76.8kbps and 250kbps raw bit >>>> rate radios. In both cases, the typical duty cycle on the radio is >>>> below 0.1%, for an effective link data rate of at most a few tens = to >>>> hundreds of bits per second, and latencies of very roughly 1 second >>>> per hop. These networks contain hundreds of nodes, and are tens of >>>> hops across. >>> >>> Is each hop-to-hop link a ptp link? I believe so: >>> >>> node<---ptplink---->node<----ptplink---->... >>> 76kbps 76kbps >> >> I don't believe so... the link is both unicast- and broadcast- = capable - >> the latter may reach > 1 node (possibly hundreds) with just a single >> transmission. > >Is the broadcast capability a link-layer capability or an IP-layer >capability? Maybe IP sees it as a ptp link despite its physical >broadcast nature? > >A difficult subnet structure may mean ND problems. A routing protocol >could address them, but a better subnet structure is quicker to plan. > >Alex > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Wed Feb 4 07:17:46 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36AB43A6C69 for ; Wed, 4 Feb 2009 07:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQCMHWgxQXts for ; Wed, 4 Feb 2009 07:17:45 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 2E0C73A6941 for ; Wed, 4 Feb 2009 07:17:45 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n14FH3sk028655; Wed, 4 Feb 2009 16:17:03 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n14FH38P006738; Wed, 4 Feb 2009 16:17:03 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n14FH36S000369; Wed, 4 Feb 2009 16:17:03 +0100 Message-ID: <4989B16F.5050709@gmail.com> Date: Wed, 04 Feb 2009 16:17:03 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <20090127000001.9F1F03A6819@core3.amsl.com><498852C5.1050503@gmail.com><69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com><498867F8.6000802@gmail.com><49887E75.1090705@gmail.com><44680fe70902030943q416b0908occe4dbc6b1a331e8@mail.gmail.com><498883C1.4070703@gmail.com><44680fe70902031147i3f0a30d8hc1b86c091dfb2792@mail.gmail.com><4988AEF0.20803@gmail.com><44680fe70902031258o54190cfdl6e5ce794e9b61e12@mail.gmail.com><4988B4BF.8020000@gmail.com> <4988C110.4090902@eecs.berkeley.edu><4988C703.6090805@gmail.com><7673A863-F3BF-4499-993E-1AEA59CA192B@archrock.com> <4988D73F.7040303@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC06EC3823@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC06EC3823@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Review and comments Re:I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 15:17:46 -0000 Hi Pascal, Pascal Thubert (pthubert) a écrit : > Hi Alex: > > I expect that peer discovery won't be very different from current ND > or hello. So there's no ruling ND out of the story. I'd be more reassured of explicitely stating ND is not ruled out from the ROLL space. Some text in protocols-survey draft seems to rule it out. In a constrained device the designer is tempted to strip out some protocols. If we list the protocols we asumme implemented I think we'll have many surprising disagreements. > What is new is a node density factor that we will have to address. > For instance, Trickle is discussed at 6LoWPAN for that exact reason. Sorry, Trickle being? A protocol? A product? Doesn't figure in 6LoWPAN documents... You mean the node density is very high as compared to something? (or very low?). > Power Control / management is also critical for that matter. > > AFAIK, 6LoWPAN proposes a ND model that can be extended the way > MANEMO extended traditional ND Thanks for pointing this out! Indeed I find indeed the 6LoWPAN Prefix Information Option in the RA (draft-ietf-6lowpan-nd-00.txt) to be akin to some of the MANEMO work (MANEMO was an earlier pre-BoF-never-BoF for MANET and NEMO). Do you think I should propose the MANEMO personal proposal for prefix in RA to 6LoWPAN? To ROLL? To AUTOCONF? Alex >> so it can be considered in the solution space... once we recharter. From zsmith@daintree.net Wed Feb 4 08:15:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EAA93A6C7D for ; Wed, 4 Feb 2009 08:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.441 X-Spam-Level: X-Spam-Status: No, score=-1.441 tagged_above=-999 required=5 tests=[AWL=1.158, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLV0sPPtPglo for ; Wed, 4 Feb 2009 08:15:08 -0800 (PST) Received: from auswood.securesites.net (auswood.securesites.net [128.121.62.173]) by core3.amsl.com (Postfix) with ESMTP id 2DFAD3A6936 for ; Wed, 4 Feb 2009 08:15:08 -0800 (PST) Received: from [10.0.1.5] (c-98-210-6-113.hsd1.ca.comcast.net [98.210.6.113]) (authenticated bits=0) by auswood.securesites.net (8.13.6.20060614/8.13.6) with ESMTP id n14GEkhY020810 for ; Wed, 4 Feb 2009 16:14:46 GMT Message-Id: <13203A1F-066B-4094-81A3-2F51ED2D9DE8@daintree.net> From: Zachary Smith To: ROLL WG In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 4 Feb 2009 08:14:45 -0800 References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <7F8459D1-3464-435A-AF8F-F9C437036FDF@cisco.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [Roll] If possible ... X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 16:15:09 -0000 Hey all, If one more voice will make a difference here, it seems clear that - as always happens with these things - as the race gets closer to the finish line the atmosphere gets more.... well... I guess "animated" would be an appropriately neutral word. This is fine, of course, and to be expected but it is also clear that all of this discussion can be continued in the context of a re-chartered ROLL with a mandate to actually make routing protocol choices. Now, my personal opinion, based on direct experience is that one all- singing-all-dancing routing protocol will not be sufficient to satisfy the requirements as currently constituted. The experience of the ZigBee WGs (I know, I know, ZigBee isn't IP and so on but the underlying problem is roughly the same) was that it really took a small suite of integrated protocols to satisfy, in particular, the low- latency requirements inherent in certain applications (e.g. building control) and the scaling requirements inherent in certain others (e.g. condition-based maintenance for large C&I facilities). Personal opinions aside, though, the only way to get to the point where we can actually have this discussion in a context where the results of the discussion are consequential, is to close the current phase and move on to the next. z On Feb 3, 2009, at 2:20 PM, JP Vasseur wrote: > Great to see all these discussions, but in light of the discussions > today I would like to *converge* - Zachary Smith - CTO http://www.daintree.net/ From jhui@archrock.com Wed Feb 4 08:20:33 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F5B73A6B80 for ; Wed, 4 Feb 2009 08:20:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixMS6NGV2NYU for ; Wed, 4 Feb 2009 08:20:31 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id B32373A6AA5 for ; Wed, 4 Feb 2009 08:20:31 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 75A00AF89A; Wed, 4 Feb 2009 08:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xy7rmFrFxFNo; Wed, 4 Feb 2009 08:20:11 -0800 (PST) Received: from [10.0.1.200] (adsl-71-142-101-72.dsl.pltn13.pacbell.net [71.142.101.72]) by mail.sf.archrock.com (Postfix) with ESMTP id 7CB0FAF865; Wed, 4 Feb 2009 08:20:11 -0800 (PST) Message-Id: <501A3D08-3B46-4C36-90CD-B95854C61A9B@archrock.com> From: Jonathan Hui To: Alexandru Petrescu In-Reply-To: <4989B16F.5050709@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 4 Feb 2009 08:20:10 -0800 References: <20090127000001.9F1F03A6819@core3.amsl.com><498852C5.1050503@gmail.com><69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com><498867F8.6000802@gmail.com><49887E75.1090705@gmail.com><44680fe70902030943q416b0908occe4dbc6b1a331e8@mail.gmail.com><498883C1.4070703@gmail.com><44680fe70902031147i3f0a30d8hc1b86c091dfb2792@mail.gmail.com><4988AEF0.20803@gmail.com><44680fe70902031258o54190cfdl6e5ce794e9b61e12@mail.gmail.com><4988B4BF.8020000@gmail.com> <4988C110.4090902@eecs.berkeley.edu><4988C703.6090805@gmail.com><7673A863-F3BF-4499-993E-1AEA59CA192B@archrock.com> <4988D73F.7040303@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC06EC3823@xmb-ams-337.emea.cisco.com> <4989B16F.5050709@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: ROLL WG Subject: Re: [Roll] Review and comments Re:I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 16:20:33 -0000 On Feb 4, 2009, at 7:17 AM, Alexandru Petrescu wrote: > Sorry, Trickle being? A protocol? A product? Doesn't figure in > 6LoWPAN documents... Try the 6LoWPAN WG ML: http://www.ietf.org/mail-archive/web/6lowpan/current/msg01266.html To those of us in the sensornet community, Trickle is widely used in many applications at all layers of the stack. It's a pretty fundamental primitive for building robust protocols. -- Jonathan Hui From alexandru.petrescu@gmail.com Wed Feb 4 08:35:44 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3CEC28C11E for ; Wed, 4 Feb 2009 08:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4Zx9RbHtOfA for ; Wed, 4 Feb 2009 08:35:44 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id D94993A6C80 for ; Wed, 4 Feb 2009 08:35:43 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n14GZJu3030989; Wed, 4 Feb 2009 17:35:19 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n14GZHPa021044; Wed, 4 Feb 2009 17:35:18 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n14GZHUI025759; Wed, 4 Feb 2009 17:35:17 +0100 Message-ID: <4989C3C5.5060109@gmail.com> Date: Wed, 04 Feb 2009 17:35:17 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Jonathan Hui References: <20090127000001.9F1F03A6819@core3.amsl.com><498852C5.1050503@gmail.com><69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com><498867F8.6000802@gmail.com><49887E75.1090705@gmail.com><44680fe70902030943q416b0908occe4dbc6b1a331e8@mail.gmail.com><498883C1.4070703@gmail.com><44680fe70902031147i3f0a30d8hc1b86c091dfb2792@mail.gmail.com><4988AEF0.20803@gmail.com><44680fe70902031258o54190cfdl6e5ce794e9b61e12@mail.gmail.com><4988B4BF.8020000@gmail.com> <4988C110.4090902@eecs.berkeley.edu><4988C703.6090805@gmail.com><7673A863-F3BF-4499-993E-1AEA59CA192B@archrock.com> <4988D73F.7040303@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC06EC3823@xmb-ams-337.emea.cisco.com> <4989B16F.5050709@gmail.com> <501A3D08-3B46-4C36-90CD-B95854C61A9B@archrock.com> In-Reply-To: <501A3D08-3B46-4C36-90CD-B95854C61A9B@archrock.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Review and comments Re:I-D ACTION:draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 16:35:44 -0000 Jonathan Hui a écrit : > > On Feb 4, 2009, at 7:17 AM, Alexandru Petrescu wrote: >> Sorry, Trickle being? A protocol? A product? Doesn't figure in >> 6LoWPAN documents... > > > Try the 6LoWPAN WG ML: > http://www.ietf.org/mail-archive/web/6lowpan/current/msg01266.html > > To those of us in the sensornet community, Trickle is widely used in > many applications at all layers of the stack. It's a pretty fundamental > primitive for building robust protocols. Funny - that single CACM issue is eternally unread on my desk, and I get drawn by the IETF documents instead... Alex > > -- > Jonathan Hui > > From pal@cs.stanford.edu Wed Feb 4 09:13:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17DAC28C269 for ; Wed, 4 Feb 2009 09:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygq6ldIveoKN for ; Wed, 4 Feb 2009 09:13:15 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id DB65628C108 for ; Wed, 4 Feb 2009 09:13:15 -0800 (PST) Received: from dnab422056.stanford.edu ([171.66.32.86]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1LUlJ2-00088N-0E; Wed, 04 Feb 2009 09:12:56 -0800 Message-Id: <12F32533-AD72-4356-BC36-3F6B87395BF9@cs.stanford.edu> From: Philip Levis To: Alexandru Petrescu In-Reply-To: <4988AA03.802@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 4 Feb 2009 09:00:02 -0800 References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> <49887E75.1090705@gmail.com> <7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com> <4988AA03.802@gmail.com> X-Mailer: Apple Mail (2.930.3) X-Scan-Signature: 702ae50298edc6602ea45f3868e8cc09 Cc: roll@ietf.org Subject: Re: [Roll] suggestion of NEMO text for protocols-survey draft (was: Review and comments Re: I-D ACTION:draft-ietf-roll-protocols-survey-05.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 17:13:17 -0000 Comments follow. On Feb 3, 2009, at 12:33 PM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> Please do ... please do it short and concise ;-) > > The existing NEMO text is in draft-ietf-roll-protocols-survey-05: > >> This document does not examine the Network Mobility Basic Support =20 >> Protocol (NEMO RFC 3963 [RFC3963]) because it is not a routing =20 >> protocol. It does not examine hierarchical NEMO [I-D.thubert-tree-=20= >> discovery] as a candidate because it only maintains >> a default route and so is insufficient for general routing. Although >> NEMO itself is not a suitable routing solution to LLNs, some of its >> mechanisms, such as loop-free tree formation, might be useful in an >> LLN routing protocol. > > I suggest replacing the above paragraph with the following longer > text, maybe in its own section. > > In this section we briefly overview the NEMO extensions to Mobile > IPv6, its accepted drawbacks, and its features with respect to > memory footprint (Table?), protocol reliability (Loss, Control?), > energy metrics (Link and Node Cost?) and security. > > The Network Mobility Basic Support Protocol ("NEMO" RFC 3963, > terminology RFC4885) is a set of extensions to the Mobile IPv6 > protocol (RFC3775). They extend Mobile IPv6 to accomodate a moving > network, i.e. a set of nodes moving together, and connecting to the > Internet: laptops in a bus, or a PDA and a camera of a PAN. > Arbitrarily "nested" combinations - e.g. a PAN getting into a bus - > can equally be accomodated. One noticeable problem is the > enforcing of artifically long paths - all traffic between a > Correspondent Node and a Local Fixed Node must travel through the > Home Agent(s) (RFC4888), despite the existence of shorter straight > IP paths. Solutions addressing this problem are in the space of > Route Optimization for NEMO (RFC4889), yet none is Standards Track > at this point. > > The Mobile IPv6 protocol has been implemented on a wide range of > platforms, of main OS vendors and freely available, from servers to > smaller devices. A footprint of a TCP/UDP/ND/IPv6 stack running > NEMO and Mobile IPv6 in a Mobile Router is for example 200kb. > > Although the Mobile IPv6 protocol is basically a two-way exchange, =20= > it=09 > has lifetimes, timers and retransmission logic such as to =20 > accommodate=09 > several types of failures of the critical messages; and rate =09 > limitation such as to avoid too much noise. =09 > =09 > The Mobile IPv6 NEMO extensions are used mainly between a Mobile=09 > Router and a Home Agent: the MR updates only the HA about its Mobile=09= > Network Prefix (MNP); it doesn't update several entities, just one.=09= > =09 > The Mobile IPv6 protocol and implicitely its NEMO extensions do not=09= > currently have any field in the messages, nor any logic in the =20 > nodes,=09 > relating to energy consumption. One would think that binding =09= > lifetimes would need to depend on remaining battery level; and maybe=09= > an Error Code from the HA meaning 'not enough battery'; or similar.=09= > Other possibilities do exist. > > An approximation of energy consumption of a particular small device > running such an IPv6 stack can be divided as follows: 40% energy to > enable the WiFi driver, 1% of energy to send IPv6 packets. > > The NEMO extensions and the Mobile IPv6 protocol are generally > believed to be secure. For through-the-HA communication they make > extensive use of IPsec transport and tunnels (RFC4877) whereas for > Route Optimization for Mobile Hosts a particular authentication > mechanism is used (Return Routability tests). > > Conclusion: this section surveyed the NEMO (RFC3963) extensions to > the Mobile IPv6 protocol, as necessary for a ROLL WG context. It > doesn't in any way pretend to be a complete (the protocol has many > other features necessary in mobility environments), and errors may > have slipped through, this is open to comments. Suddenly the NEMO section is longer than all of the other ones, even =20 though it's not being considered in the table! Why is a lengthy =20 restatement of NEMO's capabilities relevant to the purpose and intent =20= of the document? The document has a single and solitary purpose: to determine whether =20 an existing IETF routing protocol can meet the requirements of LLN =20 applications. It can't even answer "yes," as that would require a =20 detailed examination of application drafts. It can only answer "maybe" =20= or "no." Any content added to the document outside this purpose dilutes its =20 point and will make our job harder down the line. Adding words is =20 easy; removing them is hard. We don't want the draft to be like a =20 piece of U.S. legislation, where there are lots of ancillary "riders" =20= that append sometimes completely orthogonal content to the main =20 document. If NEMO suddenly receives a very long section, then future =20 readers may wonder whether the document was implicitly promoting =20 NEMO's mechanisms as a starting point. The statement that "NEMO is not a routing protocol" is, as I've said =20 before, based on the fact that you can't use NEMO alone. NEMO allows =20 nodes to route in a mobile setting by *tunneling over an existing =20 routing infrastructure.* The fact that it advertises prefixes and =20 modifies routing tables does not make it a routing protocol in the =20 context of ROLL and this draft. Otherwise, DHCP is one too. Debating =20 "what is a routing protocol" in the general sense isn't particularly =20 helpful. But in the context of this draft, based on the application =20 requirements, that seems pretty clear. It's something that, starting =20 with link layer connectivity to other IP nodes, lets you send a packet =20= over multiple hops to a destination based on an IP address. I think we've lost track of the real reason for NEMO's exclusion. =20 Would you agree with changing 3.1 to: "This document does not examine the Network Mobility Basic Support Protocol (NEMO RFC 3963) because it requires an underlying IP routing protocol over which to tunnel. It does not examine hierarchical NEMO as a candidate because it only maintains a default route and so is insufficient for general routing. Although NEMO itself is not a suitable routing solution to LLNs, some of its mechanisms, such as loop-free tree formation, might be useful in an LLN routing protocol." Then, in Section 9, Conclusion, change from "Figure 1 shows that no existing IETF protocol specification meets the criteria described in Section 4. Therefore, having a routing protocol for LLNs requires new protocol specification documents. Whether such documents describe modifications to existing protocols or new protocols it outside the scope of this document and warrants further discussion. However, the results in Figure 1 may provide some insight or guidance in such a discusssion, indicating what protocol mechanisms may be better suited to LLNs than others." to "Figure 1 shows that no existing IETF protocol specification meets the criteria described in Section 4. Therefore, having a routing protocol for LLNs requires new protocol specification documents. Whether such documents describe modifications to existing protocols or new protocols it outside the scope of this document and warrants further discussion. However, the results in Figure 1 may provide some insight or guidance in such a discusssion, indicating what protocol mechanisms may be better suited to LLNs than others." "Such a discussion should not, however, be limited to the protocols listed in Figure 1. As discussed in Section 3.1, there are several existing protocols, such as NEMO and hierarchical NEMO, which are unsuitable as a general routing protocol but describe mechanisms that could be very useful in the context of LLNs. Any such future discussion ought to consider how routing in LLNs may benefit from borrowing mechanisms from a broader suite of protocols than those listed in Figure 1." Thoughts? Phil From ian.chakeres@gmail.com Wed Feb 4 10:11:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4488A3A686C for ; Wed, 4 Feb 2009 10:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FS1G7bI5vpot for ; Wed, 4 Feb 2009 10:11:44 -0800 (PST) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.182]) by core3.amsl.com (Postfix) with ESMTP id 779003A6843 for ; Wed, 4 Feb 2009 10:11:44 -0800 (PST) Received: by el-out-1112.google.com with SMTP id r27so1687110ele.13 for ; Wed, 04 Feb 2009 10:11:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tA2RafM8e4yojHNjy0A6QLkw0xzdKS0pNslyiuaxCvo=; b=u1eQX0ndOJiBiHev2HzLw0qYIRlyNf/197euMAcLfI+RiYt9gTFsW5oTURNyxtlpQi 8PsoglvwP2UzZwkG834oXkMkQi+1rGYZZO/ENDbVbLguA0ldVkbg4weAfAto1ysJYo6I NIofPmOCDb+6/gLT/oLEFCPHgfDBbbHn5C7Dw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RyvgxKcFDr+mbLJlgEqtNQOLYWSC0lKklSCUBgrIaOE6IH01rhwmXk77K1e8QujAY1 LxibbRmvV3IVAiAkfPeT6nmvcFENyAYmVSWXqUa5Gj8goai7oZ+EDooWCuvSKMNmXdCi XTQ5InEvsRgQvACCTLvj9Zx5iWhBe4sTIQPbw= MIME-Version: 1.0 Received: by 10.90.84.17 with SMTP id h17mr4351310agb.40.1233771083954; Wed, 04 Feb 2009 10:11:23 -0800 (PST) In-Reply-To: <374005f30902041009o58a45428mf0e59204532bc8a4@mail.gmail.com> References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <7F8459D1-3464-435A-AF8F-F9C437036FDF@cisco.com> <374005f30902041009o58a45428mf0e59204532bc8a4@mail.gmail.com> Date: Wed, 4 Feb 2009 13:11:23 -0500 Message-ID: <374005f30902041011m4884e9c6p3344172168eb65d4@mail.gmail.com> From: Ian Chakeres To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review and comments draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 18:11:45 -0000 Please also include the comments that I have reiterated through the last few protocol-survey updates. Thanks & I look forward to seeing the next rev. Ian Chakeres From alexandru.petrescu@gmail.com Wed Feb 4 10:23:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 562AA28C228 for ; Wed, 4 Feb 2009 10:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4sLO49LX74u for ; Wed, 4 Feb 2009 10:23:44 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id EF8D63A6954 for ; Wed, 4 Feb 2009 10:23:43 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n14INKLm024822; Wed, 4 Feb 2009 19:23:20 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n14INKI6002035; Wed, 4 Feb 2009 19:23:20 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n14INKIT016774; Wed, 4 Feb 2009 19:23:20 +0100 Message-ID: <4989DD17.80907@gmail.com> Date: Wed, 04 Feb 2009 19:23:19 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Philip Levis References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> <49887E75.1090705@gmail.com> <7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com> <4988AA03.802@gmail.com> <12F32533-AD72-4356-BC36-3F6B87395BF9@cs.stanford.edu> In-Reply-To: <12F32533-AD72-4356-BC36-3F6B87395BF9@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] suggestion of NEMO text for protocols-survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 18:23:45 -0000 Philip, thanks for the reply. Philip Levis a écrit : > Comments follow. [...] > Suddenly the NEMO section is longer than all of the other ones, even > though it's not being considered in the table! How many lines would one suggest? Would 30 lines cut it? I can do, just let me know. The suggested NEMO text is 56 lines. The other similar sections are: OSPF/ISIS 22 lines, OLSR 34 lines, etc. If we don't converge, I'm also ok to put this as an Appendix section. [...] > The statement that "NEMO is not a routing protocol" is, as I've said > before, based on the fact that you can't use NEMO alone. NEMO allows > nodes to route in a mobile setting by *tunneling over an existing > routing infrastructure.* The fact that it advertises prefixes and > modifies routing tables does not make it a routing protocol in the > context of ROLL and this draft. I don't agree. I think commonly agreeing what a 'Routing Protocol in ROLL context' is would make a lot of sense, discussing it. > Otherwise, DHCP is one too. Thanks for mentioning it! I think DHCP should be mentioned too in protocols-survey. The DHCP Server and Relay often modify the routing tables and they go hand in hand with address autoconfiguration needs. I think ROLL nodes are supposed to auto-configure somehow, thus DHCP is very pertinent. > Debating "what is a routing protocol" in the general sense isn't > particularly helpful. I think we could very well debate what is a routing protocol, discussion. > But in the context of this draft, based on the application > requirements, that seems pretty clear. It's not clear at all. What are the applications? Are _all_ typical TCP/UDP/HTTP applications considered by ROLL? Or only some of them? In such a constrained environment one would strip some protocols from the stack - for example MLD - an otherwise integral part of an IPv6 stack (informational requirements for IPv6 nodes are in RFC4294). But if one strips MLD away then ND may work less efficiently. If ND is less efficient then OSPF may be less efficient. And so on. > It's something that, starting with link layer connectivity to other > IP nodes, lets you send a packet over multiple hops to a destination > based on an IP address. I think it's way too vague... how about static routes - they're induced by humans not protocols. Or routes induced by ICMP Redirect messages - is ICMP a routing protocol? > I think we've lost track of the real reason for NEMO's exclusion. > Would you agree with changing 3.1 to: > > "This document does not examine the Network Mobility Basic Support > Protocol (NEMO RFC 3963) because it > requires an underlying IP routing protocol over which to tunnel. It No I don't agree. NEMO MR and HA tunnel ok over networks that don't require an IP routing protocol, networks using static IP routes. It also works ok when MR and HA are neighbors, linked by a single link. > does not examine hierarchical NEMO target="I-D.thubert-tree-discovery"/> as a candidate because it only > maintains a default route and so is insufficient for general > routing. What is 'hierarchical' NEMO? More complete would be to cite an RFC overviewing several NEMO RO competing proposals rather than a personal proposal. I mean use RFC4889 "NEMO RO Space Analysis" instead of thubert-tree-discovery which is but one technique for NEMO RO. What is 'general' routing? > Although NEMO itself is not a suitable routing solution to LLNs, some > of its mechanisms, such as loop-free tree formation, might be useful > in an LLN routing protocol." > > Then, in Section 9, Conclusion, change from > > "Figure 1 shows that no existing IETF protocol specification meets > the criteria described in Section 4. Therefore, having a routing > protocol for LLNs requires new protocol specification documents. > Whether such documents describe modifications to existing protocols > or new protocols it outside the scope of this document and warrants > further discussion. However, the results in Figure 1 may provide > some insight or guidance in such a discusssion, indicating what > protocol mechanisms may be better suited to LLNs than others." > > to > > "Figure 1 shows that no existing IETF protocol specification meets > the criteria described in Section 4. Therefore, having a routing > protocol for LLNs requires new protocol specification documents. > Whether such documents describe modifications to existing protocols > or new protocols it outside the scope of this document and warrants > further discussion. However, the results in Figure 1 may provide > some insight or guidance in such a discusssion, indicating what > protocol mechanisms may be better suited to LLNs than others." > > "Such a discussion should not, however, be limited to the protocols > listed in Figure 1. As discussed in Section 3.1, there are several > existing protocols, such as NEMO and hierarchical NEMO, > which are unsuitable as a general routing protocol but describe > mechanisms that could be very useful in the context of LLNs. Any such > future discussion ought to consider how routing in LLNs may benefit > from borrowing mechanisms from a broader suite of protocols than > those listed in Figure 1." In principle this extended conclusion sounds better to me. But again, I don't understand "hierarchical NEMO". There's an RFC4885 "Network Mobility Support Terminology." if you wish to consider or me to describe. And also I don't understand 'general routing protocol'. Maybe citing DHCP in this paragraph as well. Alex > > Thoughts? > > Phil > > From jvasseur@cisco.com Wed Feb 4 10:53:46 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B26743A6A45 for ; Wed, 4 Feb 2009 10:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.5 X-Spam-Level: X-Spam-Status: No, score=-10.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4CC41-q33gl for ; Wed, 4 Feb 2009 10:53:45 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D29293A6954 for ; Wed, 4 Feb 2009 10:53:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,380,1231113600"; d="scan'208";a="32866302" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 04 Feb 2009 18:53:24 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n14IrOiJ019854; Wed, 4 Feb 2009 19:53:24 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n14IrOoE018653; Wed, 4 Feb 2009 18:53:24 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Feb 2009 19:53:24 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Feb 2009 19:53:23 +0100 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4989DD17.80907@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 4 Feb 2009 19:53:22 +0100 References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> <49887E75.1090705@gmail.com> <7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com> <4988AA03.802@gmail.com> <12F32533-AD72-4356-BC36-3F6B87395BF9@cs.stanford.edu> <4989DD17.80907@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 04 Feb 2009 18:53:23.0744 (UTC) FILETIME=[DB169A00:01C986F9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7103; t=1233773604; x=1234637604; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20suggestion=20of=20NEMO=20text= 20for=20protocols-survey=20draft |Sender:=20; bh=4PkuSoHm8bTAlR3zeKJXl6ArBJmrMtqfB7YjrM7UQ3s=; b=ZIx9S56Pg+9y9VzXt26XzDVTfXeavvcLlB8JVtMt24c2/QAj1TLth09ob1 uoaoaRCrlJ46gp+2LFOpLwnm9SB+xnd5TWXlG31hBny79vCAhKYBjg9vraNh h+nkvX/wxY; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG Subject: Re: [Roll] suggestion of NEMO text for protocols-survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 18:53:46 -0000 Alex, Please hold-on, we are trying to satisfy your request as much as =20 possible but this becomes a "bit" unreasonable. We tried to provide you a lot of information on ROLL and non-ROLL =20 issue, this is fine. Remember we are not writing a tutorial or a book =20= on LLNs here. Now you ask for adding DHCP in the survey. You also ask to look at applications: PLEASE read the 4 application-=20 specific requirement documents then. and transport protocols (out of our charter). On the discussion on what is a routing protocol, sorry but it does not =20= belong to this list. Let's say a bit focussed. Phil made a very reasonable suggestion. Please consider it carefully =20 and we will make a final attempt. Thanks. JP. On Feb 4, 2009, at 7:23 PM, Alexandru Petrescu wrote: > Philip, thanks for the reply. > > Philip Levis a =E9crit : >> Comments follow. > [...] >> Suddenly the NEMO section is longer than all of the other ones, even >> though it's not being considered in the table! > > How many lines would one suggest? Would 30 lines cut it? I can do, =20= > just let me know. > > The suggested NEMO text is 56 lines. The other similar sections are: > OSPF/ISIS 22 lines, OLSR 34 lines, etc. > > If we don't converge, I'm also ok to put this as an Appendix section. > > [...] >> The statement that "NEMO is not a routing protocol" is, as I've said >> before, based on the fact that you can't use NEMO alone. NEMO allows >> nodes to route in a mobile setting by *tunneling over an existing =20 >> routing infrastructure.* The fact that it advertises prefixes and =20 >> modifies routing tables does not make it a routing protocol in the =20= >> context of ROLL and this draft. > > I don't agree. I think commonly agreeing what a 'Routing Protocol =20 > in ROLL context' is would make a lot of sense, discussing it. > >> Otherwise, DHCP is one too. > > Thanks for mentioning it! > > I think DHCP should be mentioned too in protocols-survey. The DHCP > Server and Relay often modify the routing tables and they go hand in > hand with address autoconfiguration needs. I think ROLL nodes are =20 > supposed to auto-configure somehow, thus DHCP is very pertinent. > >> Debating "what is a routing protocol" in the general sense isn't =20 >> particularly helpful. > > I think we could very well debate what is a routing protocol, =20 > discussion. > >> But in the context of this draft, based on the application =20 >> requirements, that seems pretty clear. > > It's not clear at all. What are the applications? Are _all_ typical > TCP/UDP/HTTP applications considered by ROLL? Or only some of =20 > them? In > such a constrained environment one would strip some protocols from =20 > the stack - for example MLD - an otherwise integral part of an IPv6 =20= > stack (informational requirements for IPv6 nodes are in RFC4294). > > But if one strips MLD away then ND may work less efficiently. If ND =20= > is less efficient then OSPF may be less efficient. And so on. > >> It's something that, starting with link layer connectivity to other =20= >> IP nodes, lets you send a packet over multiple hops to a =20 >> destination based on an IP address. > > I think it's way too vague... how about static routes - they're =20 > induced by humans not protocols. Or routes induced by ICMP Redirect =20= > messages - is ICMP a routing protocol? > >> I think we've lost track of the real reason for NEMO's exclusion. =20 >> Would you agree with changing 3.1 to: >> "This document does not examine the Network Mobility Basic Support =20= >> Protocol (NEMO RFC 3963) because it =20= >> requires an underlying IP routing protocol over which to tunnel. It > > No I don't agree. NEMO MR and HA tunnel ok over networks that don't =20= > require an IP routing protocol, networks using static IP routes. It =20= > also works ok when MR and HA are neighbors, linked by a single link. > >> does not examine hierarchical NEMO > discovery"/> as a candidate because it only >> maintains a default route and so is insufficient for general >> routing. > > What is 'hierarchical' NEMO? > > More complete would be to cite an RFC overviewing several NEMO RO =20 > competing proposals rather than a personal proposal. I mean use =20 > RFC4889 "NEMO RO Space Analysis" instead of thubert-tree-discovery =20 > which is but one technique for NEMO RO. > > What is 'general' routing? > >> Although NEMO itself is not a suitable routing solution to LLNs, some >> of its mechanisms, such as loop-free tree formation, might be useful >> in an LLN routing protocol." >> Then, in Section 9, Conclusion, change from >> "Figure 1 shows that no existing IETF protocol specification meets =20= >> the criteria described in Section 4. Therefore, having a routing =20 >> protocol for LLNs requires new protocol specification documents. =20 >> Whether such documents describe modifications to existing protocols =20= >> or new protocols it outside the scope of this document and warrants =20= >> further discussion. However, the results in Figure 1 may provide =20 >> some insight or guidance in such a discusssion, indicating what =20 >> protocol mechanisms may be better suited to LLNs than others." >> to >> "Figure 1 shows that no existing IETF protocol specification meets =20= >> the criteria described in Section 4. Therefore, having a routing =20 >> protocol for LLNs requires new protocol specification documents. =20 >> Whether such documents describe modifications to existing protocols =20= >> or new protocols it outside the scope of this document and warrants =20= >> further discussion. However, the results in Figure 1 may provide =20 >> some insight or guidance in such a discusssion, indicating what =20 >> protocol mechanisms may be better suited to LLNs than others." >> "Such a discussion should not, however, be limited to the protocols =20= >> listed in Figure 1. As discussed in Section 3.1, there are several =20= >> existing protocols, such as NEMO and hierarchical NEMO, =20= >> which are unsuitable as a general routing protocol but describe =20 >> mechanisms that could be very useful in the context of LLNs. Any such >> future discussion ought to consider how routing in LLNs may benefit >> from borrowing mechanisms from a broader suite of protocols than =20 >> those listed in Figure 1." > > In principle this extended conclusion sounds better to me. But =20 > again, I > don't understand "hierarchical NEMO". There's an RFC4885 "Network > Mobility Support Terminology." if you wish to consider or me to =20 > describe. > > And also I don't understand 'general routing protocol'. > > Maybe citing DHCP in this paragraph as well. > > Alex > >> Thoughts? >> Phil > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Wed Feb 4 12:07:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 608113A6A72 for ; Wed, 4 Feb 2009 12:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.071 X-Spam-Level: X-Spam-Status: No, score=-2.071 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEJ8MH+-EvWG for ; Wed, 4 Feb 2009 12:07:46 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id D6B8E28C102 for ; Wed, 4 Feb 2009 12:07:44 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 0D29DE080E7; Wed, 4 Feb 2009 21:07:20 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp6-g21.free.fr (Postfix) with ESMTP id 24362E080D6; Wed, 4 Feb 2009 21:07:17 +0100 (CET) Message-ID: <4989F556.2010000@gmail.com> Date: Wed, 04 Feb 2009 21:06:46 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: JP Vasseur References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> <49887E75.1090705@gmail.com> <7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com> <4988AA03.802@gmail.com> <12F32533-AD72-4356-BC36-3F6B87395BF9@cs.stanford.edu> <4989DD17.80907@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090203-1, 03/02/2009), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] suggestion of NEMO text for protocols-survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 20:07:47 -0000 JP, I consider carefully my reply to Philip. I offered to maybe make the NEMO text an Appendix, or maybe write it in a limited number of lines, you decide the number. I strongly disagree to cite a personal proposal (RRH) when an RFC agreed by a WG is more appropriate (RFC4889). Do you think this is unreasonable? 'NEMO vs routing protocols': we seem to have strong disagreements - are they, aren't they. Two sections in 2 RFCs [x] detail interactions of NEMO protocol with dynamic routing protocols. These sections are there because WGs and IESG asked for them. They could be cited as well... so different than saying NEMO is not a routing protocol, or NEMO requires an existing routing protocol... Finally - DHCP is pertinent to mention for ROLL, and ICMP Redirect too, maybe in the Conclusions section, like "we don't rule out DHCP nor ICMP Redirect". I carefully consider the discussions. Alex [x]: section 8 of rfc3963 and section section 9 of rfc5177 JP Vasseur a écrit : > Alex, > > Please hold-on, we are trying to satisfy your request as much as > possible but this becomes a "bit" unreasonable. > We tried to provide you a lot of information on ROLL and non-ROLL issue, > this is fine. Remember we are not writing a tutorial or a book on LLNs > here. > > Now you ask for adding DHCP in the survey. > > You also ask to look at applications: PLEASE read the 4 > application-specific requirement documents then. > > and transport protocols (out of our charter). > > On the discussion on what is a routing protocol, sorry but it does not > belong to this list. Let's say a bit focussed. > > Phil made a very reasonable suggestion. Please consider it carefully and > we will make a final attempt. > > Thanks. > > JP. > > On Feb 4, 2009, at 7:23 PM, Alexandru Petrescu wrote: > >> Philip, thanks for the reply. >> >> Philip Levis a écrit : >>> Comments follow. >> [...] >>> Suddenly the NEMO section is longer than all of the other ones, even >>> though it's not being considered in the table! >> >> How many lines would one suggest? Would 30 lines cut it? I can do, >> just let me know. >> >> The suggested NEMO text is 56 lines. The other similar sections are: >> OSPF/ISIS 22 lines, OLSR 34 lines, etc. >> >> If we don't converge, I'm also ok to put this as an Appendix section. >> >> [...] >>> The statement that "NEMO is not a routing protocol" is, as I've said >>> before, based on the fact that you can't use NEMO alone. NEMO allows >>> nodes to route in a mobile setting by *tunneling over an existing >>> routing infrastructure.* The fact that it advertises prefixes and >>> modifies routing tables does not make it a routing protocol in the >>> context of ROLL and this draft. >> >> I don't agree. I think commonly agreeing what a 'Routing Protocol in >> ROLL context' is would make a lot of sense, discussing it. >> >>> Otherwise, DHCP is one too. >> >> Thanks for mentioning it! >> >> I think DHCP should be mentioned too in protocols-survey. The DHCP >> Server and Relay often modify the routing tables and they go hand in >> hand with address autoconfiguration needs. I think ROLL nodes are >> supposed to auto-configure somehow, thus DHCP is very pertinent. >> >>> Debating "what is a routing protocol" in the general sense isn't >>> particularly helpful. >> >> I think we could very well debate what is a routing protocol, discussion. >> >>> But in the context of this draft, based on the application >>> requirements, that seems pretty clear. >> >> It's not clear at all. What are the applications? Are _all_ typical >> TCP/UDP/HTTP applications considered by ROLL? Or only some of them? In >> such a constrained environment one would strip some protocols from the >> stack - for example MLD - an otherwise integral part of an IPv6 stack >> (informational requirements for IPv6 nodes are in RFC4294). >> >> But if one strips MLD away then ND may work less efficiently. If ND >> is less efficient then OSPF may be less efficient. And so on. >> >>> It's something that, starting with link layer connectivity to other >>> IP nodes, lets you send a packet over multiple hops to a destination >>> based on an IP address. >> >> I think it's way too vague... how about static routes - they're >> induced by humans not protocols. Or routes induced by ICMP Redirect >> messages - is ICMP a routing protocol? >> >>> I think we've lost track of the real reason for NEMO's exclusion. >>> Would you agree with changing 3.1 to: >>> "This document does not examine the Network Mobility Basic Support >>> Protocol (NEMO RFC 3963) because it >>> requires an underlying IP routing protocol over which to tunnel. It >> >> No I don't agree. NEMO MR and HA tunnel ok over networks that don't >> require an IP routing protocol, networks using static IP routes. It >> also works ok when MR and HA are neighbors, linked by a single link. >> >>> does not examine hierarchical NEMO >> target="I-D.thubert-tree-discovery"/> as a candidate because it only >>> maintains a default route and so is insufficient for general >>> routing. >> >> What is 'hierarchical' NEMO? >> >> More complete would be to cite an RFC overviewing several NEMO RO >> competing proposals rather than a personal proposal. I mean use >> RFC4889 "NEMO RO Space Analysis" instead of thubert-tree-discovery >> which is but one technique for NEMO RO. >> >> What is 'general' routing? >> >>> Although NEMO itself is not a suitable routing solution to LLNs, some >>> of its mechanisms, such as loop-free tree formation, might be useful >>> in an LLN routing protocol." >>> Then, in Section 9, Conclusion, change from >>> "Figure 1 shows that no existing IETF protocol specification meets >>> the criteria described in Section 4. Therefore, having a routing >>> protocol for LLNs requires new protocol specification documents. >>> Whether such documents describe modifications to existing protocols >>> or new protocols it outside the scope of this document and warrants >>> further discussion. However, the results in Figure 1 may provide >>> some insight or guidance in such a discusssion, indicating what >>> protocol mechanisms may be better suited to LLNs than others." >>> to >>> "Figure 1 shows that no existing IETF protocol specification meets >>> the criteria described in Section 4. Therefore, having a routing >>> protocol for LLNs requires new protocol specification documents. >>> Whether such documents describe modifications to existing protocols >>> or new protocols it outside the scope of this document and warrants >>> further discussion. However, the results in Figure 1 may provide >>> some insight or guidance in such a discusssion, indicating what >>> protocol mechanisms may be better suited to LLNs than others." >>> "Such a discussion should not, however, be limited to the protocols >>> listed in Figure 1. As discussed in Section 3.1, there are several >>> existing protocols, such as NEMO and hierarchical NEMO, >>> which are unsuitable as a general routing protocol but describe >>> mechanisms that could be very useful in the context of LLNs. Any such >>> future discussion ought to consider how routing in LLNs may benefit >>> from borrowing mechanisms from a broader suite of protocols than >>> those listed in Figure 1." >> >> In principle this extended conclusion sounds better to me. But again, I >> don't understand "hierarchical NEMO". There's an RFC4885 "Network >> Mobility Support Terminology." if you wish to consider or me to describe. >> >> And also I don't understand 'general routing protocol'. >> >> Maybe citing DHCP in this paragraph as well. >> >> Alex >> >>> Thoughts? >>> Phil >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > From culler@eecs.berkeley.edu Wed Feb 4 12:37:04 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A618E3A684E for ; Wed, 4 Feb 2009 12:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.052 X-Spam-Level: X-Spam-Status: No, score=-5.052 tagged_above=-999 required=5 tests=[AWL=1.547, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+XnG2z9IfJe for ; Wed, 4 Feb 2009 12:37:03 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 7B6003A69E5 for ; Wed, 4 Feb 2009 12:36:51 -0800 (PST) Received: from [128.32.39.229] (dhcp-39-229.EECS.Berkeley.EDU [128.32.39.229]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n14KaPvc025454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Feb 2009 12:36:26 -0800 (PST) Message-ID: <4989FC3E.5090807@eecs.berkeley.edu> Date: Wed, 04 Feb 2009 12:36:14 -0800 From: "David E. Culler" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Alexandru Petrescu References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> <49887E75.1090705@gmail.com> <7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com> <4988AA03.802@gmail.com> <12F32533-AD72-4356-BC36-3F6B87395BF9@cs.stanford.edu> <4989DD17.80907@gmail.com> <4989F556.2010000@gmail.com> In-Reply-To: <4989F556.2010000@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] suggestion of NEMO text for protocols-survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 20:37:04 -0000 Perhaps we could apply a simple rule like the following: Routing? layer 7: NO layer 3: YES layer 2: NO Alexandru Petrescu wrote: > JP, > > I consider carefully my reply to Philip. > > I offered to maybe make the NEMO text an Appendix, or maybe write it > in a limited number of lines, you decide the number. > > I strongly disagree to cite a personal proposal (RRH) when an RFC > agreed by a WG is more appropriate (RFC4889). Do you think this is > unreasonable? > > 'NEMO vs routing protocols': we seem to have strong disagreements - > are they, aren't they. Two sections in 2 RFCs [x] detail interactions > of NEMO protocol with dynamic routing protocols. These sections are > there because WGs and IESG asked for them. They could be cited as > well... so different than saying NEMO is not a routing protocol, or > NEMO requires an existing routing protocol... > > Finally - DHCP is pertinent to mention for ROLL, and ICMP Redirect > too, maybe in the Conclusions section, like "we don't rule out DHCP > nor ICMP Redirect". > > I carefully consider the discussions. > > Alex > [x]: section 8 of rfc3963 and section section 9 of rfc5177 > > JP Vasseur a écrit : >> Alex, >> >> Please hold-on, we are trying to satisfy your request as much as >> possible but this becomes a "bit" unreasonable. >> We tried to provide you a lot of information on ROLL and non-ROLL >> issue, this is fine. Remember we are not writing a tutorial or a book >> on LLNs here. >> >> Now you ask for adding DHCP in the survey. >> >> You also ask to look at applications: PLEASE read the 4 >> application-specific requirement documents then. >> >> and transport protocols (out of our charter). >> >> On the discussion on what is a routing protocol, sorry but it does >> not belong to this list. Let's say a bit focussed. >> >> Phil made a very reasonable suggestion. Please consider it carefully >> and we will make a final attempt. >> >> Thanks. >> >> JP. >> >> On Feb 4, 2009, at 7:23 PM, Alexandru Petrescu wrote: >> >>> Philip, thanks for the reply. >>> >>> Philip Levis a écrit : >>>> Comments follow. >>> [...] >>>> Suddenly the NEMO section is longer than all of the other ones, even >>>> though it's not being considered in the table! >>> >>> How many lines would one suggest? Would 30 lines cut it? I can do, >>> just let me know. >>> >>> The suggested NEMO text is 56 lines. The other similar sections are: >>> OSPF/ISIS 22 lines, OLSR 34 lines, etc. >>> >>> If we don't converge, I'm also ok to put this as an Appendix section. >>> >>> [...] >>>> The statement that "NEMO is not a routing protocol" is, as I've said >>>> before, based on the fact that you can't use NEMO alone. NEMO allows >>>> nodes to route in a mobile setting by *tunneling over an existing >>>> routing infrastructure.* The fact that it advertises prefixes and >>>> modifies routing tables does not make it a routing protocol in the >>>> context of ROLL and this draft. >>> >>> I don't agree. I think commonly agreeing what a 'Routing Protocol >>> in ROLL context' is would make a lot of sense, discussing it. >>> >>>> Otherwise, DHCP is one too. >>> >>> Thanks for mentioning it! >>> >>> I think DHCP should be mentioned too in protocols-survey. The DHCP >>> Server and Relay often modify the routing tables and they go hand in >>> hand with address autoconfiguration needs. I think ROLL nodes are >>> supposed to auto-configure somehow, thus DHCP is very pertinent. >>> >>>> Debating "what is a routing protocol" in the general sense isn't >>>> particularly helpful. >>> >>> I think we could very well debate what is a routing protocol, >>> discussion. >>> >>>> But in the context of this draft, based on the application >>>> requirements, that seems pretty clear. >>> >>> It's not clear at all. What are the applications? Are _all_ typical >>> TCP/UDP/HTTP applications considered by ROLL? Or only some of >>> them? In >>> such a constrained environment one would strip some protocols from >>> the stack - for example MLD - an otherwise integral part of an IPv6 >>> stack (informational requirements for IPv6 nodes are in RFC4294). >>> >>> But if one strips MLD away then ND may work less efficiently. If ND >>> is less efficient then OSPF may be less efficient. And so on. >>> >>>> It's something that, starting with link layer connectivity to other >>>> IP nodes, lets you send a packet over multiple hops to a >>>> destination based on an IP address. >>> >>> I think it's way too vague... how about static routes - they're >>> induced by humans not protocols. Or routes induced by ICMP Redirect >>> messages - is ICMP a routing protocol? >>> >>>> I think we've lost track of the real reason for NEMO's exclusion. >>>> Would you agree with changing 3.1 to: >>>> "This document does not examine the Network Mobility Basic Support >>>> Protocol (NEMO RFC 3963) because it >>>> requires an underlying IP routing protocol over which to tunnel. It >>> >>> No I don't agree. NEMO MR and HA tunnel ok over networks that don't >>> require an IP routing protocol, networks using static IP routes. It >>> also works ok when MR and HA are neighbors, linked by a single link. >>> >>>> does not examine hierarchical NEMO >>> target="I-D.thubert-tree-discovery"/> as a candidate because it only >>>> maintains a default route and so is insufficient for general >>>> routing. >>> >>> What is 'hierarchical' NEMO? >>> >>> More complete would be to cite an RFC overviewing several NEMO RO >>> competing proposals rather than a personal proposal. I mean use >>> RFC4889 "NEMO RO Space Analysis" instead of thubert-tree-discovery >>> which is but one technique for NEMO RO. >>> >>> What is 'general' routing? >>> >>>> Although NEMO itself is not a suitable routing solution to LLNs, some >>>> of its mechanisms, such as loop-free tree formation, might be useful >>>> in an LLN routing protocol." >>>> Then, in Section 9, Conclusion, change from >>>> "Figure 1 shows that no existing IETF protocol specification meets >>>> the criteria described in Section 4. Therefore, having a routing >>>> protocol for LLNs requires new protocol specification documents. >>>> Whether such documents describe modifications to existing protocols >>>> or new protocols it outside the scope of this document and warrants >>>> further discussion. However, the results in Figure 1 may provide >>>> some insight or guidance in such a discusssion, indicating what >>>> protocol mechanisms may be better suited to LLNs than others." >>>> to >>>> "Figure 1 shows that no existing IETF protocol specification meets >>>> the criteria described in Section 4. Therefore, having a routing >>>> protocol for LLNs requires new protocol specification documents. >>>> Whether such documents describe modifications to existing protocols >>>> or new protocols it outside the scope of this document and warrants >>>> further discussion. However, the results in Figure 1 may provide >>>> some insight or guidance in such a discusssion, indicating what >>>> protocol mechanisms may be better suited to LLNs than others." >>>> "Such a discussion should not, however, be limited to the protocols >>>> listed in Figure 1. As discussed in Section 3.1, there are several >>>> existing protocols, such as NEMO and hierarchical NEMO, >>>> which are unsuitable as a general routing protocol but describe >>>> mechanisms that could be very useful in the context of LLNs. Any such >>>> future discussion ought to consider how routing in LLNs may benefit >>>> from borrowing mechanisms from a broader suite of protocols than >>>> those listed in Figure 1." >>> >>> In principle this extended conclusion sounds better to me. But >>> again, I >>> don't understand "hierarchical NEMO". There's an RFC4885 "Network >>> Mobility Support Terminology." if you wish to consider or me to >>> describe. >>> >>> And also I don't understand 'general routing protocol'. >>> >>> Maybe citing DHCP in this paragraph as well. >>> >>> Alex >>> >>>> Thoughts? >>>> Phil >>> >>> >>> _______________________________________________ >>> 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 From pal@cs.stanford.edu Wed Feb 4 12:55:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 224363A69E5 for ; Wed, 4 Feb 2009 12:55:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3Ms7rOye3OG for ; Wed, 4 Feb 2009 12:55:47 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id C6D6B3A6921 for ; Wed, 4 Feb 2009 12:55:47 -0800 (PST) Received: from dnab422056.stanford.edu ([171.66.32.86]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1LUomL-0001ZG-68; Wed, 04 Feb 2009 12:55:28 -0800 Message-Id: From: Philip Levis To: Alexandru Petrescu In-Reply-To: <4989F556.2010000@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 4 Feb 2009 12:55:23 -0800 References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> <49887E75.1090705@gmail.com> <7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com> <4988AA03.802@gmail.com> <12F32533-AD72-4356-BC36-3F6B87395BF9@cs.stanford.edu> <4989DD17.80907@gmail.com> <4989F556.2010000@gmail.com> X-Mailer: Apple Mail (2.930.3) X-Scan-Signature: 8ab272620d4bdfee2f14268d9892c5ce Cc: ROLL WG Subject: Re: [Roll] suggestion of NEMO text for protocols-survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 20:55:49 -0000 On Feb 4, 2009, at 12:06 PM, Alexandru Petrescu wrote: > JP, > > I consider carefully my reply to Philip. > > I offered to maybe make the NEMO text an Appendix, or maybe write it > in a limited number of lines, you decide the number. Why should NEMO have an Appendix? Appendix A is for the analysis behind Table 1. That is why the mechanisms of these protocols are mentioned; they give the reader an understanding of where the analysis comes from. Appendix B is to explain the reason for a log factor. Why should the document have a restatement of factual information that is not relevant to its purpose and is in another document? That is exactly what a citation is for. This draft is *not* a place to advertise the features and capabilities of some IETF protocols but not others. Otherwise, it has started down the path of suggesting paths post re-chartering, something it is explicitly not supposed to do, and is playing favorites. It would then require a statement of many possible mechanisms ROLL might draw from, a task which should occur *after* rechartering, not before. The reason why NEMO *is* mentioned specially is because its examination is part of the current ROLL charter. We want to perform due diligence and cover it, even though in retrospect it is very far afield and not suitable for inclusion in Figure 1. > I strongly disagree to cite a personal proposal (RRH) when an RFC > agreed by a WG is more appropriate (RFC4889). Do you think this is > unreasonable? The reason is that the tree formation in the personal proposal has some similarities to what many LLN networks today do. Please refer to this very limited subset of documents: http://www.dustnetworks.com/technology/tsmp.shtml http://www.sensicast.com/mesh_nodes.php http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.1.5480 http://portal.acm.org/citation.cfm?id=1460415 http://sing.stanford.edu/pubs/hotnets07-4b.pdf http://dcg.ethz.ch/publications/ipsn2007.pdf http://www.tinyos.net/tinyos-2.x/doc/txt/tep123.txt http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4147030 http://www.cs.berkeley.edu/~jwhui/pubs/jhui-ic-6lowpan.pdf > 'NEMO vs routing protocols': we seem to have strong disagreements - > are they, aren't they. Two sections in 2 RFCs [x] detail > interactions of NEMO protocol with dynamic routing protocols. These > sections are there because WGs and IESG asked for them. They could > be cited as well... so different than saying NEMO is not a routing > protocol, or NEMO requires an existing routing protocol... I'll be honest here; we might disagree, but that disagreement seems to be based on a lack of understanding on your part on LLNs, wireless, and ROLL networks. I think folks in ROLL, including long-term IETFers, industry representatives, and protocol designers, are happy to help dispel this confusion, that doesn't mean all of this information should be pushed into the first draft that led to your confusion. Furthermore, your statement is misleading. It says that those RFCs detail interactions of NEMO with dynamic routing protocols. This is true. They do so in the context of *NEMO can work on top of dynamic protocols.* For example, RFC 5119, Section 9: "There are several benefits of running a dynamic routing protocol between the Mobile Router and the Home Agent. If the Mobile Network is relatively large, including several wireless subnets, then the topology changes within the moving network can be exposed from the Mobile Router to the Home Agent by using a dynamic routing protocol. The purpose of the NEMOv4 protocol extensions to Mobile IPv4, as defined in previous sections, is not to inform the Home Agent about these topology changes, but to manage the mobility of the Mobile Router." That is, this paragraph is clearly stating that a routing protocol sits underneath NEMO! RFC 3963, section 3: "When a Correspondent Node sends a data packet to a node in the Mobile Network, the packet is routed to the Home Agent that currently has the binding for the Mobile Router. " "When the Home Agent receives a data packet meant for a node in the Mobile Network, it tunnels the packet to the Mobile Router's current Care- of Address" "The Mobile Router decapsulates the packet and forwards it onto the interface where the Mobile Network is connected." The debate of "what is a routing protocol" is irrelevant. In the context of ROLL, the requirements are clear. Starting with wireless link-layer connectivity that is lossy, low power, and dynamic, LLNs need a protocol that enables them to deliver packets to nodes that are more than one hop away. From the above descriptions, NEMO does not fit this scenario, unless you assume that the correspondent node is a single hop from the Home Agent, the Home Agent is a single hop from the Care-of-Address, and the Care-of-Address is a single hop from the Mobile Router. Or am I mistaken? Phil From pal@cs.stanford.edu Wed Feb 4 12:56:52 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C1CA3A68F7 for ; Wed, 4 Feb 2009 12:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ra6xs-2J3psc for ; Wed, 4 Feb 2009 12:56:51 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 896A83A683D for ; Wed, 4 Feb 2009 12:56:51 -0800 (PST) Received: from dnab422056.stanford.edu ([171.66.32.86]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1LUonQ-0001bu-5N; Wed, 04 Feb 2009 12:56:32 -0800 Message-Id: From: Philip Levis To: Ian Chakeres In-Reply-To: <374005f30902041011m4884e9c6p3344172168eb65d4@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 4 Feb 2009 12:56:31 -0800 References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <7F8459D1-3464-435A-AF8F-F9C437036FDF@cisco.com> <374005f30902041009o58a45428mf0e59204532bc8a4@mail.gmail.com> <374005f30902041011m4884e9c6p3344172168eb65d4@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-Scan-Signature: 946122a1693bfdbb49d371411bb557d1 Cc: ROLL WG Subject: Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review and comments draft-ietf-roll-protocols-survey-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 20:56:52 -0000 On Feb 4, 2009, at 10:11 AM, Ian Chakeres wrote: > Please also include the comments that I have reiterated through the > last few protocol-survey updates. > Thanks & I look forward to seeing the next rev. Will do. Phil From culler@eecs.berkeley.edu Wed Feb 4 13:46:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 494873A6B6E for ; Wed, 4 Feb 2009 13:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.362 X-Spam-Level: X-Spam-Status: No, score=-5.362 tagged_above=-999 required=5 tests=[AWL=1.237, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+NgrZ3530n1 for ; Wed, 4 Feb 2009 13:46:55 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id C87833A6A3A for ; Wed, 4 Feb 2009 13:46:55 -0800 (PST) Received: from [128.32.39.229] (dhcp-39-229.EECS.Berkeley.EDU [128.32.39.229]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n14LkMMl027140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Feb 2009 13:46:27 -0800 (PST) Message-ID: <498A0CA3.40409@eecs.berkeley.edu> Date: Wed, 04 Feb 2009 13:46:11 -0800 From: "David E. Culler" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Philip Levis References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> <49887E75.1090705@gmail.com> <7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com> <4988AA03.802@gmail.com> <12F32533-AD72-4356-BC36-3F6B87395BF9@cs.stanford.edu> <4989DD17.80907@gmail.com> <4989F556.2010000@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] suggestion of NEMO text for protocols-survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 21:46:57 -0000 I agree. KISS. Plenty of time and venue to expand in later work. Philip Levis wrote: > > On Feb 4, 2009, at 12:06 PM, Alexandru Petrescu wrote: > >> JP, >> >> I consider carefully my reply to Philip. >> >> I offered to maybe make the NEMO text an Appendix, or maybe write it >> in a limited number of lines, you decide the number. > > Why should NEMO have an Appendix? Appendix A is for the analysis > behind Table 1. That is why the mechanisms of these protocols are > mentioned; they give the reader an understanding of where the analysis > comes from. Appendix B is to explain the reason for a log factor. Why > should the document have a restatement of factual information that is > not relevant to its purpose and is in another document? That is > exactly what a citation is for. > > This draft is *not* a place to advertise the features and capabilities > of some IETF protocols but not others. Otherwise, it has started down > the path of suggesting paths post re-chartering, something it is > explicitly not supposed to do, and is playing favorites. It would then > require a statement of many possible mechanisms ROLL might draw from, > a task which should occur *after* rechartering, not before. > > The reason why NEMO *is* mentioned specially is because its > examination is part of the current ROLL charter. We want to perform > due diligence and cover it, even though in retrospect it is very far > afield and not suitable for inclusion in Figure 1. > >> I strongly disagree to cite a personal proposal (RRH) when an RFC >> agreed by a WG is more appropriate (RFC4889). Do you think this is >> unreasonable? > > The reason is that the tree formation in the personal proposal has > some similarities to what many LLN networks today do. Please refer to > this very limited subset of documents: > > http://www.dustnetworks.com/technology/tsmp.shtml > http://www.sensicast.com/mesh_nodes.php > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.1.5480 > http://portal.acm.org/citation.cfm?id=1460415 > http://sing.stanford.edu/pubs/hotnets07-4b.pdf > http://dcg.ethz.ch/publications/ipsn2007.pdf > http://www.tinyos.net/tinyos-2.x/doc/txt/tep123.txt > http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4147030 > http://www.cs.berkeley.edu/~jwhui/pubs/jhui-ic-6lowpan.pdf > >> 'NEMO vs routing protocols': we seem to have strong disagreements - >> are they, aren't they. Two sections in 2 RFCs [x] detail >> interactions of NEMO protocol with dynamic routing protocols. These >> sections are there because WGs and IESG asked for them. They could >> be cited as well... so different than saying NEMO is not a routing >> protocol, or NEMO requires an existing routing protocol... > > I'll be honest here; we might disagree, but that disagreement seems to > be based on a lack of understanding on your part on LLNs, wireless, > and ROLL networks. I think folks in ROLL, including long-term IETFers, > industry representatives, and protocol designers, are happy to help > dispel this confusion, that doesn't mean all of this information > should be pushed into the first draft that led to your confusion. > > Furthermore, your statement is misleading. It says that those RFCs > detail interactions of NEMO with dynamic routing protocols. This is > true. They do so in the context of *NEMO can work on top of dynamic > protocols.* For example, RFC 5119, Section 9: > > "There are several benefits of running a dynamic routing protocol > between the Mobile Router and the Home Agent. If the Mobile Network > is relatively large, including several wireless subnets, then the > topology changes within the moving network can be exposed from the > Mobile Router to the Home Agent by using a dynamic routing protocol. > The purpose of the NEMOv4 protocol extensions to Mobile IPv4, as > defined in previous sections, is not to inform the Home Agent about > these topology changes, but to manage the mobility of the Mobile > Router." > > That is, this paragraph is clearly stating that a routing protocol > sits underneath NEMO! > > RFC 3963, section 3: > > "When a Correspondent Node sends a data packet to a node in the Mobile > Network, the packet is routed to the Home Agent that currently has > the binding for the Mobile Router. " > > "When the Home Agent receives a data packet meant for a node in the > Mobile > Network, it tunnels the packet to the Mobile Router's current Care-of > Address" > > "The Mobile Router decapsulates the packet and forwards it > onto the interface where the Mobile Network is connected." > > The debate of "what is a routing protocol" is irrelevant. In the > context of ROLL, the requirements are clear. Starting with wireless > link-layer connectivity that is lossy, low power, and dynamic, LLNs > need a protocol that enables them to deliver packets to nodes that are > more than one hop away. From the above descriptions, NEMO does not fit > this scenario, unless you assume that the correspondent node is a > single hop from the Home Agent, the Home Agent is a single hop from > the Care-of-Address, and the Care-of-Address is a single hop from the > Mobile Router. Or am I mistaken? > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Wed Feb 4 14:25:34 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62FDF3A6A51 for ; Wed, 4 Feb 2009 14:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEM8oxH51LQZ for ; Wed, 4 Feb 2009 14:25:33 -0800 (PST) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by core3.amsl.com (Postfix) with ESMTP id 911113A685A for ; Wed, 4 Feb 2009 14:25:30 -0800 (PST) Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id 10DCB4B011A; Wed, 4 Feb 2009 23:25:07 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp2-g21.free.fr (Postfix) with ESMTP id 391964B0067; Wed, 4 Feb 2009 23:25:03 +0100 (CET) Message-ID: <498A15A1.4040707@gmail.com> Date: Wed, 04 Feb 2009 23:24:33 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Philip Levis References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> <49887E75.1090705@gmail.com> <7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com> <4988AA03.802@gmail.com> <12F32533-AD72-4356-BC36-3F6B87395BF9@cs.stanford.edu> <4989DD17.80907@gmail.com> <4989F556.2010000@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090203-1, 03/02/2009), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] suggestion of NEMO text for protocols-survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 22:25:34 -0000 Philip Levis a écrit : > > On Feb 4, 2009, at 12:06 PM, Alexandru Petrescu wrote: > >> JP, >> >> I consider carefully my reply to Philip. >> >> I offered to maybe make the NEMO text an Appendix, or maybe write >> it in a limited number of lines, you decide the number. > > Why should NEMO have an Appendix? Appendix A is for the analysis > behind Table 1. That is why the mechanisms of these protocols are > mentioned; they give the reader an understanding of where the > analysis comes from. Appendix B is to explain the reason for a log > factor. Why should the document have a restatement of factual > information that is not relevant to its purpose and is in another > document? That is exactly what a citation is for. You seem to disagree making it an Appendix, but agree making good citations. Would one thus agree to: "with respect to NEMO and routing protocols please refer to sections 8 and 9 of rfc3963 and rfc5177 respectively" and remove the parts we disagree? (remove "NEMO is not a" and "NEMO requires a"). It would substantially reduce the line number too. > This draft is *not* a place to advertise the features and > capabilities of some IETF protocols but not others. > > Otherwise, it has started down the path of suggesting paths post > re-chartering, something it is explicitly not supposed to do, and is > playing favorites. It would then require a statement of many possible > mechanisms ROLL might draw from, a task which should occur *after* > rechartering, not before. Ok. > The reason why NEMO *is* mentioned specially is because its > examination is part of the current ROLL charter. We want to perform > due diligence and cover it, even though in retrospect it is very far > afield and not suitable for inclusion in Figure 1. > >> I strongly disagree to cite a personal proposal (RRH) when an RFC >> agreed by a WG is more appropriate (RFC4889). Do you think this is >> unreasonable? > > The reason is that the tree formation in the personal proposal has > some similarities to what many LLN networks today do. I still suggest two things: the RFC4889 is a good survey of NEMO RO techniques, all build on trees in their respective sense, worth citing. The lack of non-default routes of tree-discovery draft can be addressed by another personal proposal draft-petrescu-manemo-nano-00 (it runs on flat subnets, and employs specific routes) - both are ND extensions. (and Pascal sorry, yes, I wrongly took RRH draft for tree-discovery draft). > Please refer to this very limited subset of documents: > > http://www.dustnetworks.com/technology/tsmp.shtml > http://www.sensicast.com/mesh_nodes.php > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.1.5480 > http://portal.acm.org/citation.cfm?id=1460415 > http://sing.stanford.edu/pubs/hotnets07-4b.pdf > http://dcg.ethz.ch/publications/ipsn2007.pdf > http://www.tinyos.net/tinyos-2.x/doc/txt/tep123.txt > http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4147030 > http://www.cs.berkeley.edu/~jwhui/pubs/jhui-ic-6lowpan.pdf Ok, thanks, I set it aside for my biblio one day. >> 'NEMO vs routing protocols': we seem to have strong disagreements - >> are they, aren't they. Two sections in 2 RFCs [x] detail >> interactions of NEMO protocol with dynamic routing protocols. These >> sections are there because WGs and IESG asked for them. They >> could be cited as well... so different than saying NEMO is not a >> routing protocol, or NEMO requires an existing routing protocol... > > I'll be honest here; we might disagree, but that disagreement seems > to be based on a lack of understanding on your part on LLNs, > wireless, and ROLL networks. Ok. > I think folks in ROLL, including long-term IETFers, industry > representatives, and protocol designers, are happy to help dispel > this confusion, that doesn't mean all of this information should be > pushed into the first draft that led to your confusion. > > Furthermore, your statement is misleading. It says that those RFCs > detail interactions of NEMO with dynamic routing protocols. This is > true. They do so in the context of *NEMO can work on top of dynamic > protocols.* Well no. They work together, there's no top-bottom. NEMO affects the same routing table affected by say OSPF. Each could function without the other, less synch headaches. > "There are several benefits of running a dynamic routing protocol > between the Mobile Router and the Home Agent. If the Mobile Network > is relatively large, including several wireless subnets, then the > topology changes within the moving network can be exposed from the > Mobile Router to the Home Agent by using a dynamic routing protocol. > The purpose of the NEMOv4 protocol extensions to Mobile IPv4, as > defined in previous sections, is not to inform the Home Agent about > these topology changes, but to manage the mobility of the Mobile > Router." > > That is, this paragraph is clearly stating that a routing protocol > sits underneath NEMO! Sorry if that paragraph makes think so! It should have explicitely said that exposition happens as "OSPF messages are encapuslated in the tunnel established by Mobile IPv6, when MR not at home". WOuld this clarify it's not an underneath/above relationship? MAybe an errata is necessary to that RFC, thanks for pointing it out. > RFC 3963, section 3: > > "When a Correspondent Node sends a data packet to a node in the > Mobile Network, the packet is routed to the Home Agent that currently > has the binding for the Mobile Router. " YEs, routed, as in 'forwarded', or 'passed along'. Could be via static routes, not necessarily routes set by a dynamic rt protocol. > "When the Home Agent receives a data packet meant for a node in the > Mobile Network, it tunnels the packet to the Mobile Router's current > Care-of Address" Yes, I think this does not bring confusion about routing protocol. > "The Mobile Router decapsulates the packet and forwards it onto the > interface where the Mobile Network is connected." YEs same. > The debate of "what is a routing protocol" is irrelevant. In the > context of ROLL, the requirements are clear. Starting with wireless > link-layer connectivity that is lossy, low power, and dynamic, LLNs > need a protocol that enables them to deliver packets to nodes that > are more than one hop away. > > From the above descriptions, NEMO does not fit this scenario, unless > you assume that the correspondent node is a single hop from the Home > Agent, the Home Agent is a single hop from the Care-of-Address, and > the Care-of-Address is a single hop from the Mobile Router. Or am I > mistaken? I think the NEMO protocol extensions could qualify to an IP topology I think you think, especially if connected to the Internet. It depends if 'more than one hop away' means 'decrementing the hopcount' or means 'bridged'. This begs for illustration about what a ROLL topology looks like, where are the subnets and how is the subnet addresing architecture. Alex From alexandru.petrescu@gmail.com Wed Feb 4 14:36:04 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6825A3A69F4 for ; Wed, 4 Feb 2009 14:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmpMHRWtr6sT for ; Wed, 4 Feb 2009 14:36:03 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id BD5CD3A68F7 for ; Wed, 4 Feb 2009 14:36:00 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 5720ED4800D; Wed, 4 Feb 2009 23:35:37 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 273DED4805C; Wed, 4 Feb 2009 23:35:34 +0100 (CET) Message-ID: <498A1818.2090406@gmail.com> Date: Wed, 04 Feb 2009 23:35:04 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "David E. Culler" References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> <49887E75.1090705@gmail.com> <7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com> <4988AA03.802@gmail.com> <12F32533-AD72-4356-BC36-3F6B87395BF9@cs.stanford.edu> <4989DD17.80907@gmail.com> <4989F556.2010000@gmail.com> <4989FC3E.5090807@eecs.berkeley.edu> In-Reply-To: <4989FC3E.5090807@eecs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090203-1, 03/02/2009), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] suggestion of NEMO text for protocols-survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 22:36:04 -0000 David E. Culler a écrit : > Perhaps we could apply a simple rule like the following: > > Routing? > layer 7: NO > layer 3: YES > layer 2: NO David, I tend to agree. But how would it clarify NEMO vs routing protocols? NEMO is Mobility Headers, following the IP base header (maybe AH/ESP/DO headers in between), final header no further payload, 'below' the BSD Sockets. Layer 3 thus. RIPng is UDP, above BSD Socket interface, non final headers, plenty of payload. In this sense it looks at least Transport layer (6 maybe?). I'm not sure how you see this. Alex > > > Alexandru Petrescu wrote: >> JP, >> >> I consider carefully my reply to Philip. >> >> I offered to maybe make the NEMO text an Appendix, or maybe write it >> in a limited number of lines, you decide the number. >> >> I strongly disagree to cite a personal proposal (RRH) when an RFC >> agreed by a WG is more appropriate (RFC4889). Do you think this is >> unreasonable? >> >> 'NEMO vs routing protocols': we seem to have strong disagreements - >> are they, aren't they. Two sections in 2 RFCs [x] detail interactions >> of NEMO protocol with dynamic routing protocols. These sections are >> there because WGs and IESG asked for them. They could be cited as >> well... so different than saying NEMO is not a routing protocol, or >> NEMO requires an existing routing protocol... >> >> Finally - DHCP is pertinent to mention for ROLL, and ICMP Redirect >> too, maybe in the Conclusions section, like "we don't rule out DHCP >> nor ICMP Redirect". >> >> I carefully consider the discussions. >> >> Alex >> [x]: section 8 of rfc3963 and section section 9 of rfc5177 >> >> JP Vasseur a écrit : >>> Alex, >>> >>> Please hold-on, we are trying to satisfy your request as much as >>> possible but this becomes a "bit" unreasonable. >>> We tried to provide you a lot of information on ROLL and non-ROLL >>> issue, this is fine. Remember we are not writing a tutorial or a book >>> on LLNs here. >>> >>> Now you ask for adding DHCP in the survey. >>> >>> You also ask to look at applications: PLEASE read the 4 >>> application-specific requirement documents then. >>> >>> and transport protocols (out of our charter). >>> >>> On the discussion on what is a routing protocol, sorry but it does >>> not belong to this list. Let's say a bit focussed. >>> >>> Phil made a very reasonable suggestion. Please consider it carefully >>> and we will make a final attempt. >>> >>> Thanks. >>> >>> JP. >>> >>> On Feb 4, 2009, at 7:23 PM, Alexandru Petrescu wrote: >>> >>>> Philip, thanks for the reply. >>>> >>>> Philip Levis a écrit : >>>>> Comments follow. >>>> [...] >>>>> Suddenly the NEMO section is longer than all of the other ones, even >>>>> though it's not being considered in the table! >>>> >>>> How many lines would one suggest? Would 30 lines cut it? I can do, >>>> just let me know. >>>> >>>> The suggested NEMO text is 56 lines. The other similar sections are: >>>> OSPF/ISIS 22 lines, OLSR 34 lines, etc. >>>> >>>> If we don't converge, I'm also ok to put this as an Appendix section. >>>> >>>> [...] >>>>> The statement that "NEMO is not a routing protocol" is, as I've said >>>>> before, based on the fact that you can't use NEMO alone. NEMO allows >>>>> nodes to route in a mobile setting by *tunneling over an existing >>>>> routing infrastructure.* The fact that it advertises prefixes and >>>>> modifies routing tables does not make it a routing protocol in the >>>>> context of ROLL and this draft. >>>> >>>> I don't agree. I think commonly agreeing what a 'Routing Protocol >>>> in ROLL context' is would make a lot of sense, discussing it. >>>> >>>>> Otherwise, DHCP is one too. >>>> >>>> Thanks for mentioning it! >>>> >>>> I think DHCP should be mentioned too in protocols-survey. The DHCP >>>> Server and Relay often modify the routing tables and they go hand in >>>> hand with address autoconfiguration needs. I think ROLL nodes are >>>> supposed to auto-configure somehow, thus DHCP is very pertinent. >>>> >>>>> Debating "what is a routing protocol" in the general sense isn't >>>>> particularly helpful. >>>> >>>> I think we could very well debate what is a routing protocol, >>>> discussion. >>>> >>>>> But in the context of this draft, based on the application >>>>> requirements, that seems pretty clear. >>>> >>>> It's not clear at all. What are the applications? Are _all_ typical >>>> TCP/UDP/HTTP applications considered by ROLL? Or only some of >>>> them? In >>>> such a constrained environment one would strip some protocols from >>>> the stack - for example MLD - an otherwise integral part of an IPv6 >>>> stack (informational requirements for IPv6 nodes are in RFC4294). >>>> >>>> But if one strips MLD away then ND may work less efficiently. If ND >>>> is less efficient then OSPF may be less efficient. And so on. >>>> >>>>> It's something that, starting with link layer connectivity to other >>>>> IP nodes, lets you send a packet over multiple hops to a >>>>> destination based on an IP address. >>>> >>>> I think it's way too vague... how about static routes - they're >>>> induced by humans not protocols. Or routes induced by ICMP Redirect >>>> messages - is ICMP a routing protocol? >>>> >>>>> I think we've lost track of the real reason for NEMO's exclusion. >>>>> Would you agree with changing 3.1 to: >>>>> "This document does not examine the Network Mobility Basic Support >>>>> Protocol (NEMO RFC 3963) because it >>>>> requires an underlying IP routing protocol over which to tunnel. It >>>> >>>> No I don't agree. NEMO MR and HA tunnel ok over networks that don't >>>> require an IP routing protocol, networks using static IP routes. It >>>> also works ok when MR and HA are neighbors, linked by a single link. >>>> >>>>> does not examine hierarchical NEMO >>>> target="I-D.thubert-tree-discovery"/> as a candidate because it only >>>>> maintains a default route and so is insufficient for general >>>>> routing. >>>> >>>> What is 'hierarchical' NEMO? >>>> >>>> More complete would be to cite an RFC overviewing several NEMO RO >>>> competing proposals rather than a personal proposal. I mean use >>>> RFC4889 "NEMO RO Space Analysis" instead of thubert-tree-discovery >>>> which is but one technique for NEMO RO. >>>> >>>> What is 'general' routing? >>>> >>>>> Although NEMO itself is not a suitable routing solution to LLNs, some >>>>> of its mechanisms, such as loop-free tree formation, might be useful >>>>> in an LLN routing protocol." >>>>> Then, in Section 9, Conclusion, change from >>>>> "Figure 1 shows that no existing IETF protocol specification meets >>>>> the criteria described in Section 4. Therefore, having a routing >>>>> protocol for LLNs requires new protocol specification documents. >>>>> Whether such documents describe modifications to existing protocols >>>>> or new protocols it outside the scope of this document and warrants >>>>> further discussion. However, the results in Figure 1 may provide >>>>> some insight or guidance in such a discusssion, indicating what >>>>> protocol mechanisms may be better suited to LLNs than others." >>>>> to >>>>> "Figure 1 shows that no existing IETF protocol specification meets >>>>> the criteria described in Section 4. Therefore, having a routing >>>>> protocol for LLNs requires new protocol specification documents. >>>>> Whether such documents describe modifications to existing protocols >>>>> or new protocols it outside the scope of this document and warrants >>>>> further discussion. However, the results in Figure 1 may provide >>>>> some insight or guidance in such a discusssion, indicating what >>>>> protocol mechanisms may be better suited to LLNs than others." >>>>> "Such a discussion should not, however, be limited to the protocols >>>>> listed in Figure 1. As discussed in Section 3.1, there are several >>>>> existing protocols, such as NEMO and hierarchical NEMO, >>>>> which are unsuitable as a general routing protocol but describe >>>>> mechanisms that could be very useful in the context of LLNs. Any such >>>>> future discussion ought to consider how routing in LLNs may benefit >>>>> from borrowing mechanisms from a broader suite of protocols than >>>>> those listed in Figure 1." >>>> >>>> In principle this extended conclusion sounds better to me. But >>>> again, I >>>> don't understand "hierarchical NEMO". There's an RFC4885 "Network >>>> Mobility Support Terminology." if you wish to consider or me to >>>> describe. >>>> >>>> And also I don't understand 'general routing protocol'. >>>> >>>> Maybe citing DHCP in this paragraph as well. >>>> >>>> Alex >>>> >>>>> Thoughts? >>>>> Phil >>>> >>>> >>>> _______________________________________________ >>>> 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 > From alexandru.petrescu@gmail.com Fri Feb 6 06:05:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11C563A6BB2 for ; Fri, 6 Feb 2009 06:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sj6J9qlShHb1 for ; Fri, 6 Feb 2009 06:05:33 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 4D19528C1E2 for ; Fri, 6 Feb 2009 06:05:33 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n16E5NMp022536; Fri, 6 Feb 2009 15:05:24 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n16E5Nsg016190; Fri, 6 Feb 2009 15:05:23 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n16E5M76001250; Fri, 6 Feb 2009 15:05:23 +0100 Message-ID: <498C43A2.3090501@gmail.com> Date: Fri, 06 Feb 2009 15:05:22 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Philip Levis References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> <49887E75.1090705@gmail.com> <7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com> <4988AA03.802@gmail.com> <12F32533-AD72-4356-BC36-3F6B87395BF9@cs.stanford.edu> <4989DD17.80907@gmail.com> <4989F556.2010000@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] suggestion of NEMO text for protocols-survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 14:05:36 -0000 Philip, let me try to better address your comments. Substitute the following: > The Network Mobility Basic Support Protocol extensions of Mobile IPv6 > ("NEMOv6" RFC3963) allow a Mobile Router to manage mobile routing > information with its Home Agent, in order to securely connect a > moving network to the Internet. Section 8 of RFC3963 describes > support for dynamic routing protocols. Simple and nested topologies > of NEMO moving networks can be useful for topologies of low-power > devices communicating through wireless lossy links, either when > disconnected from - but most notably when connected to - the > Internet. For the following: > This document does not examine the Network Mobility Basic Support > Protocol (NEMO RFC 3963 [RFC3963]) because it is not a routing > protocol. It does not examine hierarchical NEMO > [I-D.thubert-tree-discovery] as a candidate because it only maintains > a default route and so is insufficient for general routing. Although > NEMO itself is not a suitable routing solution to LLNs, some of its > mechanisms, such as loop-free tree formation, might be useful in an > LLN routing protocol. What do you think? Alex PS: I have separated away the ND and DHCP suggestions. Philip Levis a écrit : > > On Feb 4, 2009, at 12:06 PM, Alexandru Petrescu wrote: > >> JP, >> >> I consider carefully my reply to Philip. >> >> I offered to maybe make the NEMO text an Appendix, or maybe write >> it in a limited number of lines, you decide the number. > > Why should NEMO have an Appendix? Appendix A is for the analysis > behind Table 1. That is why the mechanisms of these protocols are > mentioned; they give the reader an understanding of where the > analysis comes from. Appendix B is to explain the reason for a log > factor. Why should the document have a restatement of factual > information that is not relevant to its purpose and is in another > document? That is exactly what a citation is for. > > This draft is *not* a place to advertise the features and > capabilities of some IETF protocols but not others. Otherwise, it has > started down the path of suggesting paths post re-chartering, > something it is explicitly not supposed to do, and is playing > favorites. It would then require a statement of many possible > mechanisms ROLL might draw from, a task which should occur *after* > rechartering, not before. > > The reason why NEMO *is* mentioned specially is because its > examination is part of the current ROLL charter. We want to perform > due diligence and cover it, even though in retrospect it is very far > afield and not suitable for inclusion in Figure 1. > >> I strongly disagree to cite a personal proposal (RRH) when an RFC >> agreed by a WG is more appropriate (RFC4889). Do you think this is >> unreasonable? > > The reason is that the tree formation in the personal proposal has > some similarities to what many LLN networks today do. Please refer to > this very limited subset of documents: > > http://www.dustnetworks.com/technology/tsmp.shtml > http://www.sensicast.com/mesh_nodes.php > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.1.5480 > http://portal.acm.org/citation.cfm?id=1460415 > http://sing.stanford.edu/pubs/hotnets07-4b.pdf > http://dcg.ethz.ch/publications/ipsn2007.pdf > http://www.tinyos.net/tinyos-2.x/doc/txt/tep123.txt > http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4147030 > http://www.cs.berkeley.edu/~jwhui/pubs/jhui-ic-6lowpan.pdf > >> 'NEMO vs routing protocols': we seem to have strong disagreements - >> are they, aren't they. Two sections in 2 RFCs [x] detail >> interactions of NEMO protocol with dynamic routing protocols. These >> sections are there because WGs and IESG asked for them. They >> could be cited as well... so different than saying NEMO is not a >> routing protocol, or NEMO requires an existing routing protocol... > > I'll be honest here; we might disagree, but that disagreement seems > to be based on a lack of understanding on your part on LLNs, > wireless, and ROLL networks. I think folks in ROLL, including > long-term IETFers, industry representatives, and protocol designers, > are happy to help dispel this confusion, that doesn't mean all of > this information should be pushed into the first draft that led to > your confusion. > > Furthermore, your statement is misleading. It says that those RFCs > detail interactions of NEMO with dynamic routing protocols. This is > true. They do so in the context of *NEMO can work on top of dynamic > protocols.* For example, RFC 5119, Section 9: > > "There are several benefits of running a dynamic routing protocol > between the Mobile Router and the Home Agent. If the Mobile Network > is relatively large, including several wireless subnets, then the > topology changes within the moving network can be exposed from the > Mobile Router to the Home Agent by using a dynamic routing protocol. > The purpose of the NEMOv4 protocol extensions to Mobile IPv4, as > defined in previous sections, is not to inform the Home Agent about > these topology changes, but to manage the mobility of the Mobile > Router." > > That is, this paragraph is clearly stating that a routing protocol > sits underneath NEMO! > > RFC 3963, section 3: > > "When a Correspondent Node sends a data packet to a node in the > Mobile Network, the packet is routed to the Home Agent that currently > has the binding for the Mobile Router. " > > "When the Home Agent receives a data packet meant for a node in the > Mobile Network, it tunnels the packet to the Mobile Router's current > Care-of Address" > > "The Mobile Router decapsulates the packet and forwards it onto the > interface where the Mobile Network is connected." > > The debate of "what is a routing protocol" is irrelevant. In the > context of ROLL, the requirements are clear. Starting with wireless > link-layer connectivity that is lossy, low power, and dynamic, LLNs > need a protocol that enables them to deliver packets to nodes that > are more than one hop away. From the above descriptions, NEMO does > not fit this scenario, unless you assume that the correspondent node > is a single hop from the Home Agent, the Home Agent is a single hop > from the Care-of-Address, and the Care-of-Address is a single hop > from the Mobile Router. Or am I mistaken? > > Phil > From John.E.Drake2@boeing.com Fri Feb 6 06:16:19 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B448E28C0FB for ; Fri, 6 Feb 2009 06:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.563 X-Spam-Level: X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HENlmOyyBWjx for ; Fri, 6 Feb 2009 06:16:18 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id CFDCF28C120 for ; Fri, 6 Feb 2009 06:16:18 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n16EG88a021613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Feb 2009 06:16:09 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n16EG8jv024652; Fri, 6 Feb 2009 06:16:08 -0800 (PST) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n16EG8xx024631; Fri, 6 Feb 2009 06:16:08 -0800 (PST) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Feb 2009 06:16:08 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Feb 2009 06:16:06 -0800 Message-ID: <51661468CBD1354294533DA79E85955A016FE5A1@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: <498C43A2.3090501@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] suggestion of NEMO text for protocols-survey draft Thread-Index: AcmIY//KjtmVnTzoR0Gs6/yts72n2AAAJUuQ References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com><69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com><498867F8.6000802@gmail.com><49887E75.1090705@gmail.com><7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com><4988AA03.802@gmail.com><12F32533-AD72-4356-BC36-3F6B87395BF9@cs.stanford.edu><4989DD17.80907@gmail.com><4989F556.2010000@gmail.com> <498C43A2.3090501@gmail.com> From: "Drake, John E" To: "Alexandru Petrescu" , "Philip Levis" X-OriginalArrivalTime: 06 Feb 2009 14:16:08.0092 (UTC) FILETIME=[744B0DC0:01C98865] Cc: ROLL WG Subject: Re: [Roll] suggestion of NEMO text for protocols-survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 14:16:19 -0000 Snipped... > Although=20 > > NEMO itself is not a suitable routing solution to LLNs, some of its=20 > > mechanisms, such as loop-free tree formation, might be useful in an=20 > > LLN routing protocol. JD: Do we have consensus that this is true, or is it simply an assertion? Also, there are a multiplicity of protocols and algorithms that might be considered useful so why do we have to specifically call out this one? From alexandru.petrescu@gmail.com Fri Feb 6 06:42:10 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7DA53A68D8 for ; Fri, 6 Feb 2009 06:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JK6x7zmSvcGC for ; Fri, 6 Feb 2009 06:42:10 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id A87363A6A6A for ; Fri, 6 Feb 2009 06:42:09 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n16Eg9vX016123; Fri, 6 Feb 2009 15:42:09 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n16Eg8qa010672; Fri, 6 Feb 2009 15:42:08 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n16Eg7Gh016335; Fri, 6 Feb 2009 15:42:07 +0100 Message-ID: <498C4C3F.3070006@gmail.com> Date: Fri, 06 Feb 2009 15:42:07 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Drake, John E" References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com><69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com><498867F8.6000802@gmail.com><49887E75.1090705@gmail.com><7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com><4988AA03.802@gmail.com><12F32533-AD72-4356-BC36-3F6B87395BF9@cs.stanford.edu><4989DD17.80907@gmail.com><4989F556.2010000@gmail.com> <498C43A2.3090501@gmail.com> <51661468CBD1354294533DA79E85955A016FE5A1@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: <51661468CBD1354294533DA79E85955A016FE5A1@XCH-SW-5V2.sw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] suggestion of NEMO text for protocols-survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 14:42:10 -0000 Drake, John E a écrit : > Snipped... > >>> Although NEMO itself is not a suitable routing solution to LLNs, >>> some of its mechanisms, such as loop-free tree formation, might >>> be useful in an LLN routing protocol. > > JD: Do we have consensus that this is true, or is it simply an > assertion? Which do you question? The "NEMO is not suitable..." or the part "loop-free tree formation... useful..."? My oppinion: when protocols-survey co-Authors say "loop-free tree formation" I think it refers to an individual proposal for NEMO RO space (or maybe of MANEMO effort), which is a novel extension of a protocol. Contrary to that oppinion I think not only "loop-free tree formation" is an inner characteristic of simple moving networks, but protocol-wise could be addressed by any other individual proposals already posted previously. I disagree with the part "NEMO is not suitable..." because I think the NEMO extensions RFC3963 could very well apply to lossly linked low powered devices. > Also, there are a multiplicity of protocols and algorithms that might > be considered useful so why do we have to specifically call out this > one? I agree with this statement, but not sure which "one" do you question "specifically calling out"? I support mentioning NEMO RFC 3963 because it is agreed by a WG and has many implementations. I don't support citing singly draft-thubert-tree-discovery, because it is only one proposal among many others. Alex From John.E.Drake2@boeing.com Fri Feb 6 06:51:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD38628C21F for ; Fri, 6 Feb 2009 06:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRwHRoqZ5DJ5 for ; Fri, 6 Feb 2009 06:51:14 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id EFCB828C207 for ; Fri, 6 Feb 2009 06:51:13 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n16EpEN7007172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Feb 2009 06:51:15 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n16EpDGE006259; Fri, 6 Feb 2009 08:51:14 -0600 (CST) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n16Ep2pT005876; Fri, 6 Feb 2009 08:51:13 -0600 (CST) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Feb 2009 06:51:05 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Feb 2009 06:51:04 -0800 Message-ID: <51661468CBD1354294533DA79E85955A016FE5AF@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: <498C4C3F.3070006@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] suggestion of NEMO text for protocols-survey draft Thread-Index: AcmIaRsZ24wE89VMQR2YLTX2QjU3OgAAQX6g References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es><49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com><69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com><498867F8.6000802@gmail.com><49887E75.1090705@gmail.com><7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com><4988AA03.802@gmail.com><12F32533-AD72-4356-BC36-3F6B87395BF9@cs.stanford.edu><4989DD17.80907@gmail.com><4989F556.2010000@gmail.com><498C43A2.3090501@gmail.com><51661468CBD1354294533DA79E85955A016FE5A1@XCH-SW-5V2.sw.nos.boeing.com> <498C4C3F.3070006@gmail.com> From: "Drake, John E" To: "Alexandru Petrescu" X-OriginalArrivalTime: 06 Feb 2009 14:51:05.0045 (UTC) FILETIME=[562CB050:01C9886A] Cc: ROLL WG Subject: Re: [Roll] suggestion of NEMO text for protocols-survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 14:51:14 -0000 =20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Friday, February 06, 2009 6:42 AM > To: Drake, John E > Cc: ROLL WG > Subject: Re: [Roll] suggestion of NEMO text for protocols-survey draft >=20 > Drake, John E a =E9crit : > > Snipped... > >=20 > >>> Although NEMO itself is not a suitable routing solution to LLNs, =20 > >>> some of its mechanisms, such as loop-free tree formation,=20 > might be=20 > >>> useful in an LLN routing protocol. > >=20 > > JD: Do we have consensus that this is true, or is it simply an=20 > > assertion? >=20 > Which do you question? The "NEMO is not suitable..." or the=20 > part "loop-free tree formation... useful..."? JD: Oops, sorry. The latter. I thought the former was obvious. =20 >=20 > My oppinion: when protocols-survey co-Authors say "loop-free=20 > tree formation" I think it refers to an individual proposal=20 > for NEMO RO space (or maybe of MANEMO effort), which is a=20 > novel extension of a protocol. > Contrary to that oppinion I think not only "loop-free tree=20 > formation" is an inner characteristic of simple moving=20 > networks, but protocol-wise could be addressed by any other=20 > individual proposals already posted previously. >=20 > I disagree with the part "NEMO is not suitable..." because I=20 > think the NEMO extensions RFC3963 could very well apply to=20 > lossly linked low powered devices. >=20 > > Also, there are a multiplicity of protocols and algorithms=20 > that might =20 > > be considered useful so why do we have to specifically call=20 > out this =20 > > one? >=20 > I agree with this statement, but not sure which "one" do you=20 > question "specifically calling out"? I support mentioning=20 > NEMO RFC 3963 because it is agreed by a WG and has many=20 > implementations. I don't support citing singly=20 > draft-thubert-tree-discovery, because it is only one proposal=20 > among many others. >=20 > Alex >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From alexandru.petrescu@gmail.com Fri Feb 6 06:59:01 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72BEF3A63EB for ; Fri, 6 Feb 2009 06:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGXmXnhYO3D8 for ; Fri, 6 Feb 2009 06:59:00 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 6FFF428C0FF for ; Fri, 6 Feb 2009 06:59:00 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n16EwwPJ005054; Fri, 6 Feb 2009 15:58:58 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n16EwwAo002871; Fri, 6 Feb 2009 15:58:58 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n16Ewvmi022444; Fri, 6 Feb 2009 15:58:57 +0100 Message-ID: <498C5031.6020007@gmail.com> Date: Fri, 06 Feb 2009 15:58:57 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Drake, John E" References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es><49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com><69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com><498867F8.6000802@gmail.com><49887E75.1090705@gmail.com><7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com><4988AA03.802@gmail.com><12F32533-AD72-4356-BC36-3F6B87395BF9@cs.stanford.edu><4989DD17.80907@gmail.com><4989F556.2010000@gmail.com><498C43A2.3090501@gmail.com><51661468CBD1354294533DA79E85955A016FE5A1@XCH-SW-5V2.sw.nos.boeing.com> <498C4C3F.3070006@gmail.com> <51661468CBD1354294533DA79E85955A016FE5AF@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: <51661468CBD1354294533DA79E85955A016FE5AF@XCH-SW-5V2.sw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] suggestion of NEMO text for protocols-survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 14:59:01 -0000 Drake, John E a écrit : [...] >>>>> Although NEMO itself is not a suitable routing solution to >>>>> LLNs, some of its mechanisms, such as loop-free tree >>>>> formation, might be useful in an LLN routing protocol. >>> >>> JD: Do we have consensus that this is true, or is it simply an >>> assertion? >> >> Which do you question? The "NEMO is not suitable..." or the part >> "loop-free tree formation... useful..."? > > JD: Oops, sorry. The latter. I thought the former was obvious. I agree there's no consensus on "loop-free tree formation... useful...". For the former "NEMO [RFC3963] is not suitable... [to ROLL]" - I disagree. Alex > >> My oppinion: when protocols-survey co-Authors say "loop-free tree >> formation" I think it refers to an individual proposal for NEMO RO >> space (or maybe of MANEMO effort), which is a novel extension of a >> protocol. Contrary to that oppinion I think not only "loop-free >> tree formation" is an inner characteristic of simple moving >> networks, but protocol-wise could be addressed by any other >> individual proposals already posted previously. >> >> I disagree with the part "NEMO is not suitable..." because I think >> the NEMO extensions RFC3963 could very well apply to lossly linked >> low powered devices. >> >>> Also, there are a multiplicity of protocols and algorithms >> that might >>> be considered useful so why do we have to specifically call >> out this >>> one? >> I agree with this statement, but not sure which "one" do you >> question "specifically calling out"? I support mentioning NEMO RFC >> 3963 because it is agreed by a WG and has many implementations. I >> don't support citing singly draft-thubert-tree-discovery, because >> it is only one proposal among many others. >> >> Alex >> >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> > From pthubert@cisco.com Fri Feb 6 07:45:50 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F25028C20F for ; Fri, 6 Feb 2009 07:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.591 X-Spam-Level: X-Spam-Status: No, score=-9.591 tagged_above=-999 required=5 tests=[AWL=-0.689, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PZkVwVQLQqF for ; Fri, 6 Feb 2009 07:45:48 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 398753A699D for ; Fri, 6 Feb 2009 07:45:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,391,1231113600"; d="scan'208,217";a="33076377" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 06 Feb 2009 15:44:56 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n16FiuMZ015646; Fri, 6 Feb 2009 16:44:56 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n16FisLZ025403; Fri, 6 Feb 2009 15:44:56 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Feb 2009 16:44:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C98871.DB4179C3" Date: Fri, 6 Feb 2009 16:44:54 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0118250C@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] suggestion of NEMO text for protocols-survey draft Thread-Index: AcmIaRsZ24wE89VMQR2YLTX2QjU3OgAAQX6gAAD1XiM= References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es><49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com><69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com><498867F8.6000802@gmail.com><49887E75.1090705@gmail.com><7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com><4988AA03.802@gmail.com><12F32533-AD72-4356-BC36-3F6B87395BF9@cs.stanford.edu><4989DD17.80907@gmail.com><4989F556.2010000@gmail.com><498C43A2.3090501@gmail.com><51661468CBD1354294533DA79E85955A016FE5A1@XCH-SW-5V2.sw.nos.boeing.com> <498C4C3F.3070006@gmail.com> <51661468CBD1354294533DA79E85955A016FE5AF@XCH-SW-5V2.sw.nos.boeing.com> From: "Pascal Thubert (pthubert)" To: "Drake, John E" , "Alexandru Petrescu" X-OriginalArrivalTime: 06 Feb 2009 15:44:55.0816 (UTC) FILETIME=[DBDD3880:01C98871] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11580; t=1233935096; x=1234799096; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20=3D?iso-8859-1?Q?RE=3DA0=3D3A_=3D5BRoll=3D5D_su ggestion_of_NEMO_text_for_protocols-?=3D=0A=09=3D?iso-8859-1 ?Q?survey_draft?=3D |Sender:=20; bh=ECGnUZ86Y7owmehfRuLSC4107wPVxPhDijB1ze/uyhE=; b=uW3R9UOLrBdquebNxn3i9mtSkzJF7t94oYUXkGoVkl+jWv4cvOw/GJttlT jlUrFfV8RyxJz0HMOVC7CJXKAY6994C+tHWOsw/u5LrA3yRTz2QMA0iSmbOW JSHBg3R/x2; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG Subject: [Roll] =?iso-8859-1?q?RE=A0=3A__suggestion_of_NEMO_text_for_proto?= =?iso-8859-1?q?cols-survey_draft?= X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 15:45:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C98871.DB4179C3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi John and Alex =20 1) The NEMO explicit prefix is a route advertisement, NEMO injects = routes in the RIB, redistributes them etc... IOW NEMO includes a routing = protocol packaged with a tunnel setup protocol. =20 2) I do not see a thing that was done at the NEMO WG and that can be = remotely useful to ROLL. NEMO is out of the picture because it aims at = global mobility which is a very different problem, and not surprisingly, = is not suited for the job at hand. =20 3) MANEMO is a very different story. MANEMO had sensor networking in its = problem statement. I think that there is a risk on confusion between = NEMO and MANEMO because MANEMO was a spawned off NEMO, though a very = different problem. =20 4) The MANEMO approach was to split the problem in several subcomponents = that you could assemble at your guise. For instance build a tree and = source route, build a tree and route along the tree, build a tree, route = long the tree and build additional routes on-demand, build a tree and = use it to define subareas where other (MANET) protocol(s) would apply = and then use the tree to route between those subareas, build a graph and = route along it, etc... Taking one individual draft out of that effort to = point out that it is unsufficient as a full solution is missing the = point completely. =20 Maybe we should just remove all reference to NEMO because it's = irrelevant, like many of the 5K+ RFCs available at this time. =20 We need to make sure, in any case, that people do not read this prose as = ruling out MANEMO. MANEMO is not considered in the study because it was = stalled at the stage of a proposal, as opposed to an IETF experimental = or standard track work. I think it is acceptable to mention its = existence as previous and related IETF art. =20 On the side, I'm not aware of many protocols that aim at building those = mobile/radio trees/DAGs at the IETF, though I agree there are plenty in = the academia. If there are then I think they should all be mentioned on = equal ground. Either they exist as exp/std track and then they should be = studied, or they exist as individual submission and they can be = referenced together with the MANEMO work as background information. =20 Makes sense? =20 Pascal ________________________________ De: roll-bounces@ietf.org de la part de Drake, John E Date: ven. 06/02/2009 15:51 =C0: Alexandru Petrescu Cc: ROLL WG Objet : Re: [Roll] suggestion of NEMO text for protocols-survey draft > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Friday, February 06, 2009 6:42 AM > To: Drake, John E > Cc: ROLL WG > Subject: Re: [Roll] suggestion of NEMO text for protocols-survey draft > > Drake, John E a =E9crit : > > Snipped... > > > >>> Although NEMO itself is not a suitable routing solution to LLNs,=20 > >>> some of its mechanisms, such as loop-free tree formation, > might be > >>> useful in an LLN routing protocol. > > > > JD: Do we have consensus that this is true, or is it simply an > > assertion? > > Which do you question? The "NEMO is not suitable..." or the > part "loop-free tree formation... useful..."? JD: Oops, sorry. The latter. I thought the former was obvious. > > My oppinion: when protocols-survey co-Authors say "loop-free > tree formation" I think it refers to an individual proposal > for NEMO RO space (or maybe of MANEMO effort), which is a > novel extension of a protocol. > Contrary to that oppinion I think not only "loop-free tree > formation" is an inner characteristic of simple moving > networks, but protocol-wise could be addressed by any other > individual proposals already posted previously. > > I disagree with the part "NEMO is not suitable..." because I > think the NEMO extensions RFC3963 could very well apply to > lossly linked low powered devices. > > > Also, there are a multiplicity of protocols and algorithms > that might=20 > > be considered useful so why do we have to specifically call > out this=20 > > one? > > I agree with this statement, but not sure which "one" do you > question "specifically calling out"? I support mentioning > NEMO RFC 3963 because it is agreed by a WG and has many > implementations. I don't support citing singly > draft-thubert-tree-discovery, because it is only one proposal > among many others. > > Alex > > > _______________________________________________ > 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 ------_=_NextPart_001_01C98871.DB4179C3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Roll] suggestion of NEMO text for = protocols-survey draft=0A= =0A= =0A= =0A=
=0A=
Hi John and Alex
=0A=
 
=0A=
1) The NEMO explicit prefix is a route advertisement, = NEMO injects routes in the RIB, redistributes them etc... = IOW NEMO includes a routing protocol packaged with a = tunnel setup protocol.
=0A=
 
=0A=
2) I do not see a thing that was done at the NEMO WG = and that can be remotely useful to ROLL. NEMO is out of the picture = because it aims at global mobility which is a very different problem, = and not surprisingly, is not suited for the job at hand.
=0A=
 
=0A=
3) MANEMO is a very different story. MANEMO had sensor = networking in its problem statement. I think that there is a risk on = confusion between NEMO and MANEMO because MANEMO was a spawned = off NEMO, though a very different problem.
=0A=
 
=0A=
4) The MANEMO approach was to split the problem in = several subcomponents that you could assemble at your guise. For = instance build a tree and source route, build a tree and route along the = tree, build a tree, route long the tree and build additional routes = on-demand, build a tree and use it to define subareas where other = (MANET) protocol(s) would apply and then use the tree to route between = those subareas, build a graph and route along it, etc... Taking one = individual draft out of that effort to point out that it is unsufficient = as a full solution is missing the point completely.
=0A=
 
=0A=
Maybe we should just remove all reference to NEMO because = it's irrelevant, like many of the 5K+ RFCs available at this time.
=0A=
 
=0A=
We need to make sure, in any case, that people do = not read this prose as ruling out MANEMO. MANEMO is not = considered in the study because it was stalled at the stage of a = proposal, as opposed to an IETF experimental or standard track work. I = think it is acceptable to mention its existence as previous and related = IETF art.
=0A=
 
=0A=
On the side, I'm not aware of many protocols that aim at = building those mobile/radio trees/DAGs at the IETF, though I agree there = are plenty in the academia. If there are then I think they should all be = mentioned on equal ground. Either they exist as exp/std track and then = they should be studied, or they exist as individual submission and they = can be referenced together with the MANEMO work = as background information.
=0A=
 
=0A=
Makes sense?
=0A=
 
=0A=
Pascal
=0A=
=0A=
=0A=
=0A=
De: = roll-bounces@ietf.org de la part de Drake, John E
Date: ven. = 06/02/2009 15:51
=C0: Alexandru Petrescu
Cc: ROLL = WG
Objet : Re: [Roll] suggestion of NEMO text for = protocols-survey draft

=0A=
=0A=



> -----Original Message-----
> From: = Alexandru Petrescu [mailto:alexandru.petrescu@gm= ail.com]
> Sent: Friday, February 06, 2009 6:42 AM
> To: = Drake, John E
> Cc: ROLL WG
> Subject: Re: [Roll] suggestion = of NEMO text for protocols-survey draft
>
> Drake, John E a = =E9crit :
> > Snipped...
> >
> >>> = Although NEMO itself is not a suitable routing solution to = LLNs, 
> >>> some of its mechanisms, such as = loop-free tree formation,
> might  be
> >>> = useful in an LLN routing protocol.
> >
> > JD:  = Do we have consensus that this is true, or is it simply an
> > = assertion?
>
> Which do you question?  The "NEMO is not = suitable..." or the
> part "loop-free tree formation... = useful..."?

JD:  Oops, sorry.  The latter.  I = thought the former was obvious.

>
> My oppinion:  = when protocols-survey co-Authors say "loop-free
> tree formation" = I think it refers to an individual proposal
> for NEMO RO space = (or maybe of MANEMO effort), which is a
> novel extension of a = protocol.
> Contrary to that oppinion I think not only "loop-free = tree
> formation" is an inner characteristic of simple = moving
> networks, but protocol-wise could be addressed by any = other
> individual proposals already posted = previously.
>
> I disagree with the part "NEMO is not = suitable..." because I
> think the NEMO extensions RFC3963 could = very well apply to
> lossly linked low powered = devices.
>
> > Also, there are a multiplicity of = protocols and algorithms
> that might 
> > be = considered useful so why do we have to specifically call
> out = this 
> > one?
>
> I agree with this = statement, but not sure which "one" do you
> question = "specifically calling out"?  I support mentioning
> NEMO RFC = 3963 because it is agreed by a WG and has many
> = implementations.  I don't support citing singly
> = draft-thubert-tree-discovery, because it is only one proposal
> = among many others.
>
> Alex
>
>
> = _______________________________________________
> 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

------_=_NextPart_001_01C98871.DB4179C3-- From John.E.Drake2@boeing.com Fri Feb 6 07:58:21 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 420243A67DA for ; Fri, 6 Feb 2009 07:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.414 X-Spam-Level: X-Spam-Status: No, score=-6.414 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BH6EjFMwIBBz for ; Fri, 6 Feb 2009 07:58:20 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 8601B3A68B1 for ; Fri, 6 Feb 2009 07:57:23 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n16FusIo013031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Feb 2009 07:56:54 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n16Furbs017950; Fri, 6 Feb 2009 09:56:53 -0600 (CST) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n16Furo6017940; Fri, 6 Feb 2009 09:56:53 -0600 (CST) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Feb 2009 07:56:53 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Feb 2009 07:56:51 -0800 Message-ID: <51661468CBD1354294533DA79E85955A016FE5DF@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0118250C@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?iso-8859-1?Q?=5BRoll=5D_RE=A0=3A__suggestion_of_NEMO_text_for_protocols?= =?iso-8859-1?Q?-survey_draft?= Thread-Index: AcmIaRsZ24wE89VMQR2YLTX2QjU3OgAAQX6gAAD1XiMAAUiQMA== References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es><49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com><69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com><498867F8.6000802@gmail.com><49887E75.1090705@gmail.com><7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com><4988AA03.802@gmail.com><12F32533-AD72-4356-BC36-3F6B87395BF9@cs.stanford.edu><4989DD17.80907@gmail.com><4989F556.2010000@gmail.com><498C43A2.3090501@gmail.com><51661468CBD1354294533DA79E85955A016FE5A1@XCH-SW-5V2.sw.nos.boeing.com><498C4C3F.3070006@gmail.com><51661468CBD1354294533DA79E85955A016FE5AF@XCH-SW-5V2.sw.nos.boeing.com> <7892795E1A87F04CADFCCF41FADD00FC0118250C@xmb-ams-337.emea.cisco.com> From: "Drake, John E" To: "Pascal Thubert (pthubert)" , "Alexandru Petrescu" X-OriginalArrivalTime: 06 Feb 2009 15:56:53.0177 (UTC) FILETIME=[8771D290:01C98873] Cc: ROLL WG Subject: Re: [Roll] =?iso-8859-1?q?RE=A0=3A__suggestion_of_NEMO_text_for_proto?= =?iso-8859-1?q?cols-survey_draft?= X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 15:58:21 -0000 =20 > Maybe we should just remove all reference to NEMO because=20 > it's irrelevant, like many of the 5K+ RFCs available at this time. JD: Fine with me. Alternatively, we could provide an explantion and = applicability evaluation for all of the 5K+ RFCs. > On the side, I'm not aware of many protocols that aim at=20 > building those mobile/radio trees/DAGs at the IETF, though I=20 > agree there are plenty in the academia. If there are then I=20 > think they should all be mentioned on equal ground. Either=20 > they exist as exp/std track and then they should be studied,=20 > or they exist as individual submission and they can be=20 > referenced together with the MANEMO work as background information. JD: I think that was my point. I.e., don't mention any of them. From alexandru.petrescu@gmail.com Fri Feb 6 08:02:01 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D264228C221 for ; Fri, 6 Feb 2009 08:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZbVj-HY3ZEv for ; Fri, 6 Feb 2009 08:01:58 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id DCD3B28B56A for ; Fri, 6 Feb 2009 08:01:57 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n16G1p1R010682; Fri, 6 Feb 2009 17:01:51 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n16G1ppc019978; Fri, 6 Feb 2009 17:01:51 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n16G1oqb012227; Fri, 6 Feb 2009 17:01:51 +0100 Message-ID: <498C5EEE.7090603@gmail.com> Date: Fri, 06 Feb 2009 17:01:50 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es><49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com><69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com><498867F8.6000802@gmail.com><49887E75.1090705@gmail.com><7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com><4988AA03.802@gmail.com><12F32533-AD72-4356-BC36-3F6B87395BF9@cs.stanford.edu><4989DD17.80907@gmail.com><4989F556.2010000@gmail.com><498C43A2.3090501@gmail.com><51661468CBD1354294533DA79E85955A016FE5A1@XCH-SW-5V2.sw.nos.boeing.com> <498C4C3F.3070006@gmail.com> <51661468CBD1354294533DA79E85955A016FE5AF@XCH-SW-5V2.sw.nos.boeing.com> <7892795E1A87F04CADFCCF41FADD00FC0118250C@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0118250C@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG , "Drake, John E" Subject: Re: [Roll] RE : suggestion of NEMO text for protocols-survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 16:02:01 -0000 Pascal Thubert (pthubert) a écrit : > Hi John and Alex > > 1) The NEMO explicit prefix is a route advertisement, NEMO injects > routes in the RIB, redistributes them etc... IOW NEMO includes a > routing protocol packaged with a tunnel setup protocol. "RIB"? "IOW"? Sorry I can't agree or disagree with that without knowing what you mean. > 2) I do not see a thing that was done at the NEMO WG and that can be > remotely useful to ROLL. NEMO is out of the picture because it aims > at global mobility which is a very different problem, and not > surprisingly, is not suited for the job at hand. Well, I think NEMO RFC3963 is useful in general for moving networks, and may be the only possibility if one wants to securely connect a moving ROLL network to the Internet. > Maybe we should just remove all reference to NEMO because it's > irrelevant I think I can agree to remove all text saying "NEMO" from protocols-survey, neither useful nor not-useful, neither as "hierarchical NEMO", neither RFC3963. > We need to make sure, in any case, that people do not read this prose > as ruling out MANEMO. MANEMO is not considered in the study because > it was stalled at the stage of a proposal, as opposed to an IETF > experimental or standard track work. I think it is acceptable to > mention its existence as previous and related IETF art. I agree. > On the side, I'm not aware of many protocols that aim at building > those mobile/radio trees/DAGs at the IETF, though I agree there are > plenty in the academia. At least one other NEMO proposal builds a star of moving networks. A star is a tree and a DAG (Directed Acyclic Graph) at the same time. Alex From jvasseur@cisco.com Fri Feb 6 08:07:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F82528C234 for ; Fri, 6 Feb 2009 08:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.501 X-Spam-Level: X-Spam-Status: No, score=-10.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTyxeNucCT6D for ; Fri, 6 Feb 2009 08:07:42 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1CF3928C1A3 for ; Fri, 6 Feb 2009 08:07:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,391,1231113600"; d="scan'208";a="33079069" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 06 Feb 2009 16:07:43 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n16G7hnW022611; Fri, 6 Feb 2009 17:07:43 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n16G7h9p002665; Fri, 6 Feb 2009 16:07:43 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Feb 2009 17:07:43 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Feb 2009 17:07:42 +0100 Message-Id: <4A5F8B6E-BDD2-4C38-8870-908E184F1E78@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <498C5EEE.7090603@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Feb 2009 17:07:41 +0100 References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es><49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com><69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com><498867F8.6000802@gmail.com><49887E75.1090705@gmail.com><7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com><4988AA03.802@gmail.com><12F32533-AD72-4356-BC36-3F6B87395BF9@cs.stanford.edu><4989DD17.80907@gmail.com><4989F556.2010000@gmail.com><498C43A2.3090501@gmail.com><51661468CBD1354294533DA79E85955A016FE5A1@XCH-SW-5V2.sw.nos.boeing.com> <498C4C3F.3070006@gmail.com> <51661468CBD1354294533DA79E85955A016FE5AF@XCH-SW-5V2.sw.nos.boeing.com> <7892795E1A87F04CADFCCF41FADD00FC0118250C@xmb-ams-337.emea.cisco.com> <498C5EEE.7090603@gmail.com > X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 06 Feb 2009 16:07:42.0786 (UTC) FILETIME=[0AA44A20:01C98875] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1353; t=1233936463; x=1234800463; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20RE=20=3A=20suggestion=20of=20N EMO=20text=20for=20protocols-survey=20draft |Sender:=20; bh=OAi8KDhACU4xFZI7pVrwn8gTwf53/uSpkN1MjXXDl3Q=; b=W9wqA0FmmL3T1syaiMQOWR6bVwSWH6R1PGIubPLm7Vh35CtGHopCXbWHM4 I27c3lsN0I7ZEvU1C7VMZoeZrptF9M/g7i2s/br5rfhM2nWvsDNjkgudWe/y 5huZlBluWm; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "Drake, John E" , ROLL WG Subject: Re: [Roll] RE : suggestion of NEMO text for protocols-survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 16:07:43 -0000 Thanks for continuing the discussion - here is my take here: [SNIP] >> Maybe we should just remove all reference to NEMO because it's >> irrelevant > > I think I can agree to remove all text saying "NEMO" from > protocols-survey, neither useful nor not-useful, neither as > "hierarchical NEMO", neither RFC3963. > OK. Authors can you update accordingly ? >> We need to make sure, in any case, that people do not read this prose >> as ruling out MANEMO. MANEMO is not considered in the study because >> it was stalled at the stage of a proposal, as opposed to an IETF >> experimental or standard track work. I think it is acceptable to >> mention its existence as previous and related IETF art. > > I agree. > >> On the side, I'm not aware of many protocols that aim at building >> those mobile/radio trees/DAGs at the IETF, though I agree there are >> plenty in the academia. > > At least one other NEMO proposal builds a star of moving networks. A > star is a tree and a DAG (Directed Acyclic Graph) at the same time. > Let's continue this discussion when the protocol will start. I (myself) has to restrain from commenting ... Thanks. JP. > Alex > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Fri Feb 6 08:09:46 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4799F3A6BD6 for ; Fri, 6 Feb 2009 08:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.502 X-Spam-Level: X-Spam-Status: No, score=-10.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4qzJJEXLEwD for ; Fri, 6 Feb 2009 08:09:45 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D668B3A6B20 for ; Fri, 6 Feb 2009 08:09:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,391,1231113600"; d="scan'208";a="33079297" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 06 Feb 2009 16:09:39 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n16G9Z5O003303; Fri, 6 Feb 2009 17:09:35 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n16G9ZQq003244; Fri, 6 Feb 2009 16:09:35 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Feb 2009 17:09:35 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Feb 2009 17:09:34 +0100 Message-Id: <427D6718-6E23-4343-AD5C-4FF5906C9867@cisco.com> From: JP Vasseur To: JP Vasseur , ROLL WG , Philip Levis In-Reply-To: <4A5F8B6E-BDD2-4C38-8870-908E184F1E78@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Feb 2009 17:09:33 +0100 X-OriginalArrivalTime: 06 Feb 2009 16:09:35.0249 (UTC) FILETIME=[4DACC810:01C98875] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2941; t=1233936575; x=1234800575; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20GETTING=20THERE=20...=20Re=3A=20[Roll]=20RE=20= 3A=20suggestion=20of=20NEMO=20text=20for=20protocols-survey= 20draft |Sender:=20; bh=p9eZOb57j9q745HZBRr4sYW7s1s9lWCi7KWGj6M4HF8=; b=WEXfTqgWSEybFMP+mSmtuiRabY+CwfLw8Tx4ZGGZEPrLCiPoRNEFlYvTv7 pSPSWnmhM3UtxjaGNfu4Mft547EpCTsiNDM6B2kPkIDzYS4mTx5S1YpQgUdW n04EG3ps46; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: "Drake, John E" Subject: [Roll] GETTING THERE ... Re: RE : suggestion of NEMO text for protocols-survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 16:09:46 -0000 References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es><49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com><69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com><498867F8.6000802@gmail.com><49887E75.1090705@gmail.com><7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com><4988AA03.802@gmail.com><12F32533-AD72-4356-BC36-3F6B87395BF9@cs.stanford.edu><4989DD17.80907@gmail.com><4989F556.2010000@gmail.com><498C43A2.3090501@gmail.com><51661468CBD1354294533DA79E85955A016FE5A1@XCH-SW-5V2.sw.nos.boeing.com> <498C4C3F.3070006@gmail.com> <51661468CBD1354294533DA79E85955A016FE5AF@XCH-SW-5V2.sw.nos.boeing.com> <7892795E1A87F04CADFCCF41FADD00FC0118250C@xmb-ams-337.emea.cisco.com> <498C5EEE.7090603@gmail.com > <4A5F8B6E-BDD2-4C38-8870-908E184F1E78@cisco.com> X-Mailer: Apple Mail (2.930.3) Return-Path: jvasseur@cisco.com X-OriginalArrivalTime: 06 Feb 2009 16:09:34.0863 (UTC) FILETIME=[4D71E1F0:01C98875] So we are down to * Resolving Ian's comments * Resolving Thomas' comments: we are moving toward a nice resolution. Thanks. JP. On Feb 6, 2009, at 5:07 PM, JP Vasseur wrote: > Thanks for continuing the discussion - here is my take here: > > [SNIP] > >>> Maybe we should just remove all reference to NEMO because it's >>> irrelevant >> >> I think I can agree to remove all text saying "NEMO" from >> protocols-survey, neither useful nor not-useful, neither as >> "hierarchical NEMO", neither RFC3963. >> > > OK. > > Authors can you update accordingly ? > >>> We need to make sure, in any case, that people do not read this >>> prose >>> as ruling out MANEMO. MANEMO is not considered in the study >>> because it was stalled at the stage of a proposal, as opposed to >>> an IETF experimental or standard track work. I think it is >>> acceptable to mention its existence as previous and related IETF >>> art. >> >> I agree. >> >>> On the side, I'm not aware of many protocols that aim at building >>> those mobile/radio trees/DAGs at the IETF, though I agree there >>> are plenty in the academia. >> >> At least one other NEMO proposal builds a star of moving networks. A >> star is a tree and a DAG (Directed Acyclic Graph) at the same time. >> > > Let's continue this discussion when the protocol will start. I > (myself) has to restrain from commenting ... > > Thanks. > > JP. > >> Alex >> >> >> _______________________________________________ >> 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 From alexandru.petrescu@gmail.com Fri Feb 6 08:15:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE07728C27B for ; Fri, 6 Feb 2009 08:15:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtH39OPTWRud for ; Fri, 6 Feb 2009 08:15:26 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id E2C7928C25F for ; Fri, 6 Feb 2009 08:15:25 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n16GF9qf024037; Fri, 6 Feb 2009 17:15:09 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n16GF9Rk013893; Fri, 6 Feb 2009 17:15:09 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n16GF8hv016302; Fri, 6 Feb 2009 17:15:08 +0100 Message-ID: <498C620C.3040001@gmail.com> Date: Fri, 06 Feb 2009 17:15:08 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: JP Vasseur References: <20090127000001.9F1F03A6819@core3.amsl.com> <498774C1.6080603@cttc.es><49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com><69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com><498867F8.6000802@gmail.com><49887E75.1090705@gmail.com><7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com><4988AA03.802@gmail.com><12F32533-AD72-4356-BC36-3F6B87395BF9@cs.stanford.edu><4989DD17.80907@gmail.com><4989F556.2010000@gmail.com><498C43A2.3090501@gmail.com><51661468CBD1354294533DA79E85955A016FE5A1@XCH-SW-5V2.sw.nos.boeing.com> <498C4C3F.3070006@gmail.com> <51661468CBD1354294533DA79E85955A016FE5AF@XCH-SW-5V2.sw.nos.boeing.com> <7892795E1A87F04CADFCCF41FADD00FC0118250C@xmb-ams-337.emea.cisco.com> <498C5EEE.7090603@gmail.co! m> <4A5F8B6E-BDD2-4C38-8870-908E184F1E78@cisco.com> In-Reply-To: <4A5F8B6E-BDD2-4C38-8870-908E184F1E78@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "Drake, John E" , ROLL WG Subject: Re: [Roll] RE : suggestion of NEMO text for protocols-survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 16:15:26 -0000 JP Vasseur a écrit : > Thanks for continuing the discussion - here is my take here: > > [SNIP] > >>> Maybe we should just remove all reference to NEMO because it's >>> irrelevant >> >> I think I can agree to remove all text saying "NEMO" from >> protocols-survey, neither useful nor not-useful, neither as >> "hierarchical NEMO", neither RFC3963. >> > > OK. Sorry, I forgot, make sure to remove "NEMO" from the Charter too. Alex From pal@cs.stanford.edu Fri Feb 6 09:16:38 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15BFA3A6911 for ; Fri, 6 Feb 2009 09:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKreoj9bFiG1 for ; Fri, 6 Feb 2009 09:16:36 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id B0CB13A69EC for ; Fri, 6 Feb 2009 09:16:36 -0800 (PST) Received: from [32.157.70.160] (helo=[10.91.225.83]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1LVUJh-0000JF-9v; Fri, 06 Feb 2009 09:16:39 -0800 References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es><49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com><69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com><498867F8.6000802@gmail.com><49887E75.1090705@gmail.com><7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com><4988AA03.802@gmail.com><12F32533-AD72-4356-BC36-3F6B87395BF9@cs.stanford.edu><4989DD17.80907@gmail.com><4989F556.2010000@gmail.com><498C43A2.3090501@gmail.com><51661468CBD1354294533DA79E85955A016FE5A1@XCH-SW-5V2.sw.nos.boeing.com> <498C4C3F.3070006@gmail.com> <51661468CBD1354294533DA79E85955A016FE5AF@XCH-SW-5V2.sw.nos.boeing.com> <7892795E1A87F04CADFCCF41FADD00FC0118250C@xmb-ams-337.emea.cisco.com> <498C5EEE.7090603@gmail.com > Message-Id: <67BA58B7-0E75-4406-9FA5-9D3E2E324435@cs.stanford.edu> From: Philip Levis To: Alexandru Petrescu In-Reply-To: <498C5EEE.7090603@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (iPhone Mail 5F136) Date: Fri, 6 Feb 2009 08:41:29 -0800 X-Mailer: iPhone Mail (5F136) X-Scan-Signature: 5c460fe7d3aaafaf78d72307c0bc7e10 Cc: "Drake, John E" , ROLL WG Subject: Re: [Roll] RE : suggestion of NEMO text for protocols-survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 17:16:38 -0000 NEMO originally was not in the draft, then Emmanuel insisted it be =20 included because it is in the charter (December 15) So.... Tug of war =20= here. Phil On Feb 6, 2009, at 8:01 AM, Alexandru Petrescu = wrote: > Pascal Thubert (pthubert) a =C3=A9crit : >> Hi John and Alex >> 1) The NEMO explicit prefix is a route advertisement, NEMO injects =20= >> routes in the RIB, redistributes them etc... IOW NEMO includes a =20 >> routing protocol packaged with a tunnel setup protocol. > > "RIB"? "IOW"? Sorry I can't agree or disagree with that without > knowing what you mean. > >> 2) I do not see a thing that was done at the NEMO WG and that can =20 >> be remotely useful to ROLL. NEMO is out of the picture because it =20 >> aims at global mobility which is a very different problem, and not =20= >> surprisingly, is not suited for the job at hand. > > Well, I think NEMO RFC3963 is useful in general for moving networks, =20= > and > may be the only possibility if one wants to securely connect a moving > ROLL network to the Internet. > >> Maybe we should just remove all reference to NEMO because it's =20 >> irrelevant > > I think I can agree to remove all text saying "NEMO" from > protocols-survey, neither useful nor not-useful, neither as > "hierarchical NEMO", neither RFC3963. > >> We need to make sure, in any case, that people do not read this prose >> as ruling out MANEMO. MANEMO is not considered in the study because =20= >> it was stalled at the stage of a proposal, as opposed to an IETF =20 >> experimental or standard track work. I think it is acceptable to =20 >> mention its existence as previous and related IETF art. > > I agree. > >> On the side, I'm not aware of many protocols that aim at building =20 >> those mobile/radio trees/DAGs at the IETF, though I agree there are =20= >> plenty in the academia. > > At least one other NEMO proposal builds a star of moving networks. A > star is a tree and a DAG (Directed Acyclic Graph) at the same time. > > Alex > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Fri Feb 6 09:45:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0219C3A684E for ; Fri, 6 Feb 2009 09:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6qK7Ww9nivX for ; Fri, 6 Feb 2009 09:45:16 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id DBF073A67CC for ; Fri, 6 Feb 2009 09:45:14 -0800 (PST) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id E566E940147; Fri, 6 Feb 2009 18:45:11 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 253D0940176; Fri, 6 Feb 2009 18:44:53 +0100 (CET) Message-ID: <498C76E7.30909@gmail.com> Date: Fri, 06 Feb 2009 18:44:07 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Philip Levis References: <20090127000001.9F1F03A6819@core3.amsl.com> <498774C1.6080603@cttc.es><49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com><69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com><498867F8.6000802@gmail.com><49887E75.1090705@gmail.com><7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com><4988AA03.802@gmail.com><12F32533-AD72-4356-BC36-3F6B87395BF9@cs.stanford.edu><4989DD17.80907@gmail.com><4989F556.2010000@gmail.com><498C43A2.3090501@gmail.com><51661468CBD1354294533DA79E85955A016FE5A1@XCH-SW-5V2.sw.nos.boeing.com> <498C4C3F.3070006@gmail.com> <51661468CBD1354294533DA79E85955A016FE5AF@XCH-SW-5V2.sw.nos.boeing.com> <7892795E1A87F04CADFCCF41FADD00FC0118250C@xmb-ams-337.emea.cisco.com> <498C5EEE.7090603@gmail.com> <67BA58B7-0E75-4406-9FA5-9D3E2E324435@cs.stanford.edu> In-Reply-To: <67BA58B7-0E75-4406-9FA5-9D3E2E324435@cs.stanford.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090206-0, 06/02/2009), Outbound message X-Antivirus-Status: Clean Cc: "Drake, John E" , ROLL WG Subject: Re: [Roll] RE : suggestion of NEMO text for protocols-survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 17:45:17 -0000 Philip Levis a écrit : > NEMO originally was not in the draft, then Emmanuel insisted it be > included because it is in the charter (December 15) So.... Tug of war > here. Sorry, no rival rope pulling, no tug war. Emmanuel may have suggested so because it's in the Charter - perfectly reasonable. But from that to saying "NEMO is not a...", there's a long way. Emmanuel may have suggested "NEMO RO" too, which is also reasonable - an RFC overviews NEMO RO space. And that to boil down to "NEMO is not a..." and the improvement of that being an individual NEMO RO proposal... I completely disagree with both. There seems to be disagreement to what I say, so. Alex > > > Phil > > On Feb 6, 2009, at 8:01 AM, Alexandru Petrescu > wrote: > >> Pascal Thubert (pthubert) a écrit : >>> Hi John and Alex 1) The NEMO explicit prefix is a route >>> advertisement, NEMO injects routes in the RIB, redistributes them >>> etc... IOW NEMO includes a routing protocol packaged with a >>> tunnel setup protocol. >> >> "RIB"? "IOW"? Sorry I can't agree or disagree with that without >> knowing what you mean. >> >>> 2) I do not see a thing that was done at the NEMO WG and that can >>> be remotely useful to ROLL. NEMO is out of the picture because it >>> aims at global mobility which is a very different problem, and >>> not surprisingly, is not suited for the job at hand. >> >> Well, I think NEMO RFC3963 is useful in general for moving >> networks, and may be the only possibility if one wants to securely >> connect a moving ROLL network to the Internet. >> >>> Maybe we should just remove all reference to NEMO because it's >>> irrelevant >> >> I think I can agree to remove all text saying "NEMO" from >> protocols-survey, neither useful nor not-useful, neither as >> "hierarchical NEMO", neither RFC3963. >> >>> We need to make sure, in any case, that people do not read this >>> prose as ruling out MANEMO. MANEMO is not considered in the study >>> because it was stalled at the stage of a proposal, as opposed to >>> an IETF experimental or standard track work. I think it is >>> acceptable to mention its existence as previous and related IETF >>> art. >> >> I agree. >> >>> On the side, I'm not aware of many protocols that aim at building >>> those mobile/radio trees/DAGs at the IETF, though I agree there >>> are plenty in the academia. >> >> At least one other NEMO proposal builds a star of moving networks. >> A star is a tree and a DAG (Directed Acyclic Graph) at the same >> time. >> >> Alex >> >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From pthubert@cisco.com Fri Feb 6 10:25:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0524128C218 for ; Fri, 6 Feb 2009 10:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.418 X-Spam-Level: X-Spam-Status: No, score=-10.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HH+Ugo0YQpr for ; Fri, 6 Feb 2009 10:25:17 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 6804128C1E4 for ; Fri, 6 Feb 2009 10:25:15 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,392,1231113600"; d="scan'208";a="33092730" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 06 Feb 2009 18:25:16 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n16IPGUC007122; Fri, 6 Feb 2009 19:25:16 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n16IPGPZ010662; Fri, 6 Feb 2009 18:25:16 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Feb 2009 19:25:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Feb 2009 19:25:11 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC06EC442E@xmb-ams-337.emea.cisco.com> In-Reply-To: <498C5EEE.7090603@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE : [Roll] suggestion of NEMO text for protocols-survey draft Thread-Index: AcmIdFMCfKIfCwoaQSikDKKDbaCQjwAE6eDQ References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es><49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com><69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com><498867F8.6000802@gmail.com><49887E75.1090705@gmail.com><7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com><4988AA03.802@gmail.com><12F32533-AD72-4356-BC36-3F6B87395BF9@cs.stanford.edu><4989DD17.80907@gmail.com><4989F556.2010000@gmail.com><498C43A2.3090501@gmail.com><51661468CBD1354294533DA79E85955A016FE5A1@XCH-SW-5V2.sw.nos.boeing.com> <498C4C3F.3070006@gmail.com> <51661468CBD1354294533DA79E85955A016FE5AF@XCH-SW-5V2.sw.nos.boeing.com> <7892795E1A87F04CADFCCF41FADD00FC0118250C@xmb-ams-337.emea.cisco.com> <498C5EEE.7090603@gmail.com > From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 06 Feb 2009 18:25:16.0360 (UTC) FILETIME=[4227BC80:01C98888] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=398; t=1233944716; x=1234808716; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20RE=20=3A=20[Roll]=20suggestion=20of=20N EMO=20text=20for=20protocols-survey=20draft |Sender:=20; bh=OXm1vhQKtp+bWvev1A2cVL5++Sgfc7pikdlx+0/K/MQ=; b=L3Tsd2WEAYnguhfrVzqUcrQQSdUIRq+NhY+xkXxJomQqIduCJEbby13doq u1UqGRPKnbYei6oElXou2p7+wua9Sxx2opPODNhCwRZu3zyEEgCog9brak/v uEFBzDBEes; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG , "Drake, John E" Subject: Re: [Roll] RE : suggestion of NEMO text for protocols-survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 18:25:26 -0000 Hi Alex >> 1) The NEMO explicit prefix is a route advertisement, NEMO injects >> routes in the RIB, redistributes them etc... IOW NEMO includes a >> routing protocol packaged with a tunnel setup protocol. > >"RIB"? "IOW"? Sorry I can't agree or disagree with that without >knowing what you mean. RIB is the Routing Information Base. In Other Words (IOW) the routing table. Pascal From alexandru.petrescu@gmail.com Fri Feb 6 11:28:16 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA9DA3A6823 for ; Fri, 6 Feb 2009 11:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipjx5+-8OwQQ for ; Fri, 6 Feb 2009 11:28:16 -0800 (PST) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by core3.amsl.com (Postfix) with ESMTP id 6B83E3A6A7D for ; Fri, 6 Feb 2009 11:27:29 -0800 (PST) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id 71FB44C8085; Fri, 6 Feb 2009 20:27:26 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp4-g21.free.fr (Postfix) with ESMTP id 568D74C8099; Fri, 6 Feb 2009 20:27:18 +0100 (CET) Message-ID: <498C8EEE.4070108@gmail.com> Date: Fri, 06 Feb 2009 20:26:38 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <20090127000001.9F1F03A6819@core3.amsl.com> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com><69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com><498867F8.6000802@gmail.com><49887E75.1090705@gmail.com><7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com><4988AA03.802@gmail.com><12F32533-AD72-4356-BC36-3F6B87395BF9@cs.stanford.edu><4989DD17.80907@gmail.com><4989F556.2010000@gmail.com><498C43A2.3090501@gmail.com><51661468CBD1354294533DA79E85955A016FE5A1@XCH-SW-5V2.sw.nos.boeing.com> <498C4C3F.3070006@gmail.com> <51661468CBD1354294533DA79E85955A016FE5AF@XCH-SW-5V2.sw.nos.boeing.com> <7892795E1A87F04CADFCCF41FADD00FC0118250C@xmb-ams-337.emea.cisco.com> <498C5EEE.7090603@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC06EC442E@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC06EC442E@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090206-0, 06/02/2009), Outbound message X-Antivirus-Status: Clean Cc: "Drake, John E" , ROLL WG Subject: Re: [Roll] RE : suggestion of NEMO text for protocols-survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 19:28:16 -0000 Pascal Thubert (pthubert) a écrit : > Hi Alex > >>> 1) The NEMO explicit prefix is a route advertisement, NEMO >>> injects routes in the RIB, redistributes them etc... IOW NEMO >>> includes a routing protocol packaged with a tunnel setup >>> protocol. >> "RIB"? "IOW"? Sorry I can't agree or disagree with that without >> knowing what you mean. > > RIB is the Routing Information Base. In Other Words (IOW) the routing > table. Ok. For what is worth, I agree to qualify NEMO explicit mode as a routing protocol packaged with a tunnel setup protocol - following an explicit Binding Update/Ack exchange the routing table entries and the right tunnel parameters are set up at Mobile Router and at Home Agent. Alex From culler@eecs.berkeley.edu Sun Feb 8 05:42:58 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BEFF3A68ED for ; Sun, 8 Feb 2009 05:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.097 X-Spam-Level: X-Spam-Status: No, score=-5.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odUUhQnhuzIY for ; Sun, 8 Feb 2009 05:42:57 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id C146E3A6A07 for ; Sun, 8 Feb 2009 05:42:57 -0800 (PST) Received: from [192.168.90.21] (228-187.1-85.cust.bluewin.ch [85.1.187.228]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n18Dgr6g024840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 8 Feb 2009 05:42:56 -0800 (PST) Message-ID: <498EABB4.2000806@eecs.berkeley.edu> Date: Sun, 08 Feb 2009 01:53:56 -0800 From: "David E. Culler" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Drake, John E" References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> <49887E75.1090705@gmail.com> <7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com> <4988AA03.802@gmail.com> <12F32533-AD72-4356-BC36-3F6B87395BF9@cs.stanford.edu> <4989DD17.80907@gmail.com> <4989F556.2010000@gmail.com> <498C43A2.3090501@gmail.com> <51661468CBD1354294533DA79E85955A016FE5A1@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: <51661468CBD1354294533DA79E85955A016FE5A1@XCH-SW-5V2.sw.nos.boeing.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] suggestion of NEMO text for protocols-survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 13:42:58 -0000 There is no question that a number of ideas developed in NEMO are very valuable for ROLL.  Indeed, many of Jonathan Hui's proposals for RA options, the use of non-reflexive (i.e., overlapping) link local domains, and so on, have roots in NEMO drafts.  His drafts show that connection pretty well.  If we can ever get past the survey stage, we should have some really productive technical discussions.  There are definitely ideas in NEMO that have value outside the particular scope of that WG.  I'm not sure about this particular suggestion, as there is a great body of work on tree and dag formation, loop freedom, and loop detection.  And a lot of it is extremely well grounded in actual low power and lossy links.  But, if a few lines mean that we can wrap this up and get back to technical work focused on arriving at a solution, it is OK with me to toss it in.  I feel really comfortable letting the authors be the final judge on the details of the wording.  I do think we should avoid going hugely out of our way to stroke any particular subcommunity.  There are many that bring huge value and it will get incredibly unwieldy if everyone feel the need to have a nice word tossed in for them.  This, of course, was why in the original plan for the draft we placed hard limits on the universe of candidates to consider.  On the other hand, the charter dictates that we pay special attention to MANET and NEMO, so let's get to text that they are happy with, even if it has a few sentences that are general observations of goodness and potential opportunity and even if they don't contribute directly to the goal of answering: YES / NO.  We've already answered that, so at this stage we are just getting everyone into a comfort zone so we can wrap it up and move on.

Drake, John E wrote: 
Snipped...

  
Although 
    
NEMO itself is not a suitable routing solution to LLNs, some of its 
mechanisms, such as loop-free tree formation, might be useful in an 
LLN routing protocol.
      

JD:  Do we have consensus that this is true, or is it simply an
assertion?  Also, there are a multiplicity of protocols and algorithms
that might be considered useful so why do we have to specifically call
out this one?
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
From culler@eecs.berkeley.edu Sun Feb 8 05:43:16 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77F8A3A6A07 for ; Sun, 8 Feb 2009 05:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.097 X-Spam-Level: X-Spam-Status: No, score=-5.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0e589TMJk2B1 for ; Sun, 8 Feb 2009 05:43:15 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 6359D3A6906 for ; Sun, 8 Feb 2009 05:43:15 -0800 (PST) Received: from [192.168.90.21] (228-187.1-85.cust.bluewin.ch [85.1.187.228]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n18Dh5aH024848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 8 Feb 2009 05:43:11 -0800 (PST) Message-ID: <498EAD9E.40008@eecs.berkeley.edu> Date: Sun, 08 Feb 2009 02:02:06 -0800 From: "David E. Culler" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <20090127000001.9F1F03A6819@core3.amsl.com> <7D2A4649-CD28-470B-8B4E-2240D3E6513A@thomasclausen.org> <498774C1.6080603@cttc.es> <49878003.8050307@gmail.com> <4D5564FF-6780-4481-A415-7F8808C09DD7@cisco.com> <498852C5.1050503@gmail.com> <69306dde0902030742n254191e9y43cdf8728c79fffe@mail.gmail.com> <498867F8.6000802@gmail.com> <49887E75.1090705@gmail.com> <7BDF5F14-DE69-48E9-8EB6-6D54812B7770@cisco.com> <4988AA03.802@gmail.com> <12F32533-AD72-4356-BC36-3F6B87395BF9@cs.stanford.edu> <4989DD17.80907@gmail.com> <4989F556.2010000@gmail.com> <498C43A2.3090501@gmail.com> <51661468CBD1354294533DA79E85955A016FE5A1@XCH-SW-5V2.sw.nos.boeing.com> <498C4C3F.3070006@gmail.com> <51661468CBD1354294533DA79E85955A016FE5AF@XCH-SW-5V2.sw.nos.boeing.com> <7892795E1A87F04CADFCCF41FADD00FC0118250C@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0118250C@xmb-ams-337.emea.cisco.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Drake, John E" , ROLL WG Subject: Re: [Roll] RE : suggestion of NEMO text for protocols-survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 13:43:16 -0000 What makes most sense is that we not burden the ROLL routing survey draft with resolving the fine points of MANET/NEMO/MANEMO.  The survey has an extremely simple binary goal.  Is there an established routing protocol that exists today that can be used for Low Power and Lossy networks.  If the answer to that is yes, the ROLL WG is done.  If the answer to that is No, the ROLL WG recharters and begins the process of modifying an existing, building a new hybrid, or building from scratch.  If we simply take that simple statement of the responsibility of the survey document to heart, we have a trivial answer to all these subtle questions.  If the proposed text contributes directly to resolving that question, it goes in.  If it does not contribute directly to that goal, it says out. 

It is not to be a treatise on all things relevant to routing in the wireless networking domain.  It is not a beauty contest.  It is not a performance evaluation.  It is not prestigious to be included.  It is not pejorative to be left out.  The survey is merely an assessment relative to a particular question.

So here he have a simple guideline: "When in doubt, leave it out."

Pascal Thubert (pthubert) wrote:
Re: [Roll] suggestion of NEMO text for protocols-survey draft
Hi John and Alex
 
1) The NEMO explicit prefix is a route advertisement, NEMO injects routes in the RIB, redistributes them etc... IOW NEMO includes a routing protocol packaged with a tunnel setup protocol.
 
2) I do not see a thing that was done at the NEMO WG and that can be remotely useful to ROLL. NEMO is out of the picture because it aims at global mobility which is a very different problem, and not surprisingly, is not suited for the job at hand.
 
3) MANEMO is a very different story. MANEMO had sensor networking in its problem statement. I think that there is a risk on confusion between NEMO and MANEMO because MANEMO was a spawned off NEMO, though a very different problem.
 
4) The MANEMO approach was to split the problem in several subcomponents that you could assemble at your guise. For instance build a tree and source route, build a tree and route along the tree, build a tree, route long the tree and build additional routes on-demand, build a tree and use it to define subareas where other (MANET) protocol(s) would apply and then use the tree to route between those subareas, build a graph and route along it, etc... Taking one individual draft out of that effort to point out that it is unsufficient as a full solution is missing the point completely.
 
Maybe we should just remove all reference to NEMO because it's irrelevant, like many of the 5K+ RFCs available at this time.
 
We need to make sure, in any case, that people do not read this prose as ruling out MANEMO. MANEMO is not considered in the study because it was stalled at the stage of a proposal, as opposed to an IETF experimental or standard track work. I think it is acceptable to mention its existence as previous and related IETF art.
 
On the side, I'm not aware of many protocols that aim at building those mobile/radio trees/DAGs at the IETF, though I agree there are plenty in the academia. If there are then I think they should all be mentioned on equal ground. Either they exist as exp/std track and then they should be studied, or they exist as individual submission and they can be referenced together with the MANEMO work as background information.
 
Makes sense?
 
Pascal
De: roll-bounces@ietf.org de la part de Drake, John E
Date: ven. 06/02/2009 15:51
À: Alexandru Petrescu
Cc: ROLL WG
Objet : Re: [Roll] suggestion of NEMO text for protocols-survey draft



> -----Original Message-----
> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]
> Sent: Friday, February 06, 2009 6:42 AM
> To: Drake, John E
> Cc: ROLL WG
> Subject: Re: [Roll] suggestion of NEMO text for protocols-survey draft
>
> Drake, John E a écrit :
> > Snipped...
> >
> >>> Although NEMO itself is not a suitable routing solution to LLNs, 
> >>> some of its mechanisms, such as loop-free tree formation,
> might  be
> >>> useful in an LLN routing protocol.
> >
> > JD:  Do we have consensus that this is true, or is it simply an
> > assertion?
>
> Which do you question?  The "NEMO is not suitable..." or the
> part "loop-free tree formation... useful..."?

JD:  Oops, sorry.  The latter.  I thought the former was obvious.

>
> My oppinion:  when protocols-survey co-Authors say "loop-free
> tree formation" I think it refers to an individual proposal
> for NEMO RO space (or maybe of MANEMO effort), which is a
> novel extension of a protocol.
> Contrary to that oppinion I think not only "loop-free tree
> formation" is an inner characteristic of simple moving
> networks, but protocol-wise could be addressed by any other
> individual proposals already posted previously.
>
> I disagree with the part "NEMO is not suitable..." because I
> think the NEMO extensions RFC3963 could very well apply to
> lossly linked low powered devices.
>
> > Also, there are a multiplicity of protocols and algorithms
> that might 
> > be considered useful so why do we have to specifically call
> out this 
> > one?
>
> I agree with this statement, but not sure which "one" do you
> question "specifically calling out"?  I support mentioning
> NEMO RFC 3963 because it is agreed by a WG and has many
> implementations.  I don't support citing singly
> draft-thubert-tree-discovery, because it is only one proposal
> among many others.
>
> Alex
>
>
> _______________________________________________
> 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


_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
From jvasseur@cisco.com Tue Feb 10 04:49:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F9243A6B69 for ; Tue, 10 Feb 2009 04:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.503 X-Spam-Level: X-Spam-Status: No, score=-10.503 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBmsgcucI0Az for ; Tue, 10 Feb 2009 04:49:56 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 021463A67A7 for ; Tue, 10 Feb 2009 04:49:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,186,1233532800"; d="scan'208,217";a="33355537" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 10 Feb 2009 12:49:57 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1ACnv75005585 for ; Tue, 10 Feb 2009 13:49:57 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1ACnvwk000477 for ; Tue, 10 Feb 2009 12:49:57 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Feb 2009 13:49:57 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Feb 2009 13:49:56 +0100 Message-Id: From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-158-412442424 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 10 Feb 2009 13:49:56 +0100 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 10 Feb 2009 12:49:57.0036 (UTC) FILETIME=[13C186C0:01C98B7E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2584; t=1234270197; x=1235134197; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Quick=20Update=20on=20the=20protocol=20survey |Sender:=20; bh=gQ0BfHA5/maNy1kwgg6jSRFf6f0vNugjbQ4fbtfjTwI=; b=Q5glghgONe2HUsB8c1eGKHq1Y55GTQadGbFdNgSOnbmee4qo0NMh8vBd67 QRjLBsOzvP86H6ZQ9j7QBzrAWedosTZBp3mD5+ZgfSisWi3flulHZxXYN/Nd nSuBFuba4/; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Roll] Quick Update on the protocol survey X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 12:49:57 -0000 --Apple-Mail-158-412442424 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear WG, We owe you an update after so much discussion on the protocol survey document. We are progressing really well. It took quite a bit of energy (although we are working in a constrained environment ;-)) but we received many good comments leading to a consensus. Thomas sent several excellent comments that will help clarify the scope of this document and brings clarifications on several aspects (thanks!). Phil, Arsalan and Steve, could you please post a new revision taking into account these comments ? Then we'll wait for Thomas ACK on this. We tried to address most of Ian's concerns. Ian, based on our recent discussion, could you send them to this list for the record. Overall, we do have a very good consensus that should help us to move with the publication request once the new revision will have been posted. The next step is rechartering and we will send a proposal on this list very shortly. Thanks. JP and David. --Apple-Mail-158-412442424 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear WG,

We = owe you an update after so much discussion on the protocol survey = document.

We are progressing really well. It = took quite a bit of energy (although we are working in a constrained = environment ;-)) but we received many good comments leading to a = consensus.

Thomas sent several excellent = comments that will help clarify the scope of this document and brings = clarifications on several aspects (thanks!).
Phil, Arsalan = and Steve, could you please post a new revision taking into account = these comments ? Then we'll wait for Thomas ACK on = this.

We tried to address most of Ian's = concerns. Ian, based on our recent discussion, could you send them to = this list for the record.

Overall, we do have a = very good consensus that should help us to move with the publication = request once the new revision will have been = posted.

The next step is rechartering and we = will send a proposal on this list very = shortly.

Thanks.

JP = and David.
= --Apple-Mail-158-412442424-- From ian.chakeres@gmail.com Tue Feb 10 07:16:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B134A28C20C for ; Tue, 10 Feb 2009 07:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyXU5J6TTt7v for ; Tue, 10 Feb 2009 07:16:48 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id E466228C24A for ; Tue, 10 Feb 2009 07:16:36 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so1531963ywh.49 for ; Tue, 10 Feb 2009 07:16:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=0TXVgq722uTS2h/5VFKVC+MvFW/9OFjDIX88YvR5WZw=; b=laz8gCkctjqqdh/Okb6WC+Hp782yVVdbYaBs+3LGx7Ug6LjOEsNCS14utrOMhkXRmI A3ogCqamfga9pc1pvkBNEP1k6KKZcep+BLG18mjEmhsaaaUE+VQSJXPJk5uEPtl0Vu/W FH7LatQxUX4b0eKeiyFN2MYT9APsEwRWGiuQU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=xWrayUF7jOHcaRLuzqCcIjthpmcUzMWvM1AvqWww1txTSKT3CZv8y2vjHUFoA456HC 3SPybZjPGeDME2ifxJUncNfIma7RKVyBJj0a+i/Vzy1zKihcj8/8efLExzgsY0vT6ALD lWOm9uM46PFBEZQnDLZy+EbegkaAKX3srpcHk= MIME-Version: 1.0 Received: by 10.90.97.18 with SMTP id u18mr2621409agb.2.1234278999903; Tue, 10 Feb 2009 07:16:39 -0800 (PST) Date: Tue, 10 Feb 2009 10:16:39 -0500 Message-ID: <374005f30902100716l2a71513r22d763925aca782a@mail.gmail.com> From: Ian Chakeres To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Roll] Link & Node Cost Criteria in the protocol-survey Document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 15:16:49 -0000 I have been discussing the Link & Node Cost Criteria with the authors to understand whether DYMO passes, fails, or ?s. During this discussion I examined the protocol-survey document text, and it lead me to questions. To help clear up these question, I've brought the issue to the list. Here is the relevant text from the protocol-survey document. """ 4.5. Link and Node Cost These two criteria specify how a protocol chooses routes for data packets to take through the network. Classical routing algorithms typically acknowledge the differing costs of paths and may use a shortest path algorithm to find paths. This is a requirement for low power networks, as links must be evaluated as part of an objective function across various metric types, such as minimizing latency and maximizing reliability [I-D.ietf-roll-indus-routing-reqs]. However, in low power networks it is also desirable to account for the cost of forwarding through particular routers. Applications require node or parameter constrained routing, which takes into account node properties and attributes such as power, memory, and battery life that dictate a router's willingness or ability to route other packets. Home routing requirements note that devices will vary in their duty cycle, and that routing protocols should prefer nodes with permanent power [I-D.ietf-roll-home-routing-reqs]. The urban requirements note that routing protocols may wish to take advantage of differing data processing and management capabilities among network devices [I-D.ietf-roll-urban-routing-reqs]. Finally, industrial requirements cite differing lifetime requirements as an important factor to account for [I-D.ietf-roll-indus-routing-reqs]. Node cost refers to the ability for a protocol to incorporate router properties into routing metrics and use node attributes for constraint-based routing. A "pass" indicates that the protocol contains a mechanism allowing these considerations to be considered when choosing routes. """ My understanding of the above text indicates that a routing protocol will receive a "pass" if it can take link & node costs into perspective when making routing decisions. For example, the routing protocol should be capable of avoiding nodes with low battery power, or more highly utilizing nodes with more energy remaining, or choose paths with more memory (buffers), or take advantage of some special abilities to route others' packets. Given my understanding of this text I believe DYMO should receive a "pass", since DYMO is capable of performing route selection based on many criteria by manipulating the dimension-less distance metric. For example, myself and others have used spec complaint DYMO implementations and biased route selection to avoid nodes with low energy. If your thoughts on this topic agree with mine, please chime in. If your thoughts differ, please chime in - and I'd ask you to please suggest changes to the protocol-survey text to clarify the requirements more succinctly and help me understand why DYMO might not be able provide sufficient flexibility. Thanks. Ian Chakeres From jvasseur@cisco.com Wed Feb 11 00:08:02 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20D653A68B0 for ; Wed, 11 Feb 2009 00:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.504 X-Spam-Level: X-Spam-Status: No, score=-10.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdEHrM4XKEZB for ; Wed, 11 Feb 2009 00:08:00 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 28C3B3A67EE for ; Wed, 11 Feb 2009 00:08:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,191,1233532800"; d="scan'208";a="33433076" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 11 Feb 2009 08:08:02 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1B882s5019550; Wed, 11 Feb 2009 09:08:02 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1B882qT003120; Wed, 11 Feb 2009 08:08:02 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Feb 2009 09:08:02 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Feb 2009 09:08:02 +0100 Message-Id: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Feb 2009 09:08:00 +0100 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 11 Feb 2009 08:08:02.0118 (UTC) FILETIME=[DC179E60:01C98C1F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6134; t=1234339682; x=1235203682; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20ROLL=20re-chartering |Sender:=20; bh=FPDbgY8k/stNJuXsScS0Ky5kwY8CTkiUGGMeJp2HAnY=; b=Q7mNV2Sl6V1TDh49Dqu6lh5ksDca+rTWT8OXuA0aEc0/fHGZ75/hfoCnSj /73Trqn+Jnc00S/Og0blZxCO/0J08frpn6hzx1cAA1bVBAFprRy7oKlO2SJX epSG3l9Y/k; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: "David E. Culler" Subject: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 08:08:02 -0000 Dear WG, As indicated in a previous email, the protocol survey I-D will be send for publication this week (after posting of the last revision incorporating several useful comments). As promised please find below the new proposed charter to be submitted to the IESG for approval. In the hope of getting quickly re-chartered thanks to let us know if you have any comment by the ned of this week. The new charter is pretty straightforward. Thanks to Dave Ward for his comments and guidance. Description of Working Group: Low power and Lossy networks (LLNs) are typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi 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. LLNs have specific characteristics: - LLNs operate with a hard, very small bound on state, - In most cases, LLN need to be optimized for energy saving, - Typical traffic patterns are not simply unicast flows, - In most cases, LLNs need to be effective with very small packet sizes, - LLN routing protocols have to be very careful when trading off efficiency for generality; many LLN nodes do not have resources to waste. These unique properties lead to unique routing requirements that may not met by existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For example path selection must be designed to take into consideration the specific power capabilities, attributes and functional characteristics of the links and nodes in the network. 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 home, healthcare, environmental monitoring, urban sensor networks sensor networks, assets tracking, refrigeration. The Working Group will only focus on routing solutions for a subset of these. It will focus on industrial, connected home, building and urban sensor networks and specify the set of routing requirements for these scenarios. The Working Group focuses only on IPv6 only 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 explore aspects of mobility within a single LLN (if any) in the routing requirement creation. The Working Group will pay particular attention to routing security and manageability (e.g., self 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. 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 protocols 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: In light of the application specific routing requirements, the Working Group will either specify a new protocol and/ or will select an existing routing protocol (with the appropriate extensions in cooperation with the relevant Working Group). - Documentation of applicability statement of ROLL routing protocols. Goals and Milestones: Done Submit Routing requirements for Industrial applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Connected Home networks applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Building applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Urban networks applications to the IESG to be considered as an Informational RFC. July 2009 Submit Routing metrics for LLNs document to the IESG to be considered as a Proposed Standard. * Feb 2009 Submit Protocol Survey to the IESG to be considered as an Informational RFC. April 2009 Submit Security Framework to the IESG to be considered as an Informational RFC May 2009 Submit the Routing for LLNs Architecture document to the IESG as an Informational RFC. July 2009 Submit first draft of ROLL routing protocol specification as Proposed Standard. Nov 2009 Submit first draft of the MIB module of the ROLL routing protocol specification. Dec 2009 Submit the ROLL routing protocol specification to the IESG as Proposed Standard. Jan 2010 Submit the MIB module of the ROLL routing protocol specification to the IESG as Proposed Standard. Jan 2010 Evaluate WG progress, recharter or close. PS: I marked * the Milestones that will be "This Week" and before submitting to the IESG for re-chartering. Thanks. JP and David. From jvasseur@cisco.com Wed Feb 11 00:10:33 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A0563A6A6B for ; Wed, 11 Feb 2009 00:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.505 X-Spam-Level: X-Spam-Status: No, score=-10.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvg5GT2UdKiy for ; Wed, 11 Feb 2009 00:10:32 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 850503A67EE for ; Wed, 11 Feb 2009 00:10:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,191,1233532800"; d="scan'208";a="33433413" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 11 Feb 2009 08:10:34 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1B8AYsq020382; Wed, 11 Feb 2009 09:10:34 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1B8AYud004048; Wed, 11 Feb 2009 08:10:34 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Feb 2009 09:10:34 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Feb 2009 09:10:33 +0100 Message-Id: <348310E1-671D-4E71-B1DB-C4BDD5FDB79C@cisco.com> From: JP Vasseur To: JP Vasseur In-Reply-To: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Feb 2009 09:10:32 +0100 References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 11 Feb 2009 08:10:33.0628 (UTC) FILETIME=[366635C0:01C98C20] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6555; t=1234339834; x=1235203834; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20re-chartering |Sender:=20; bh=V20VVfiPqKFDfNly3fOL4d3V0PyF4dlBqCyAxOnB690=; b=NZLVikJBj/H2UVXMna8NakHBzmGfa5CC1jkAztzsxRWVy6VgDtVcG7v9qY csPQGmN+36eby2PUJw3UL32nEOXRmc3Gv1z/eTkzDEq7mvPMQvUvxzAnW1OP GwnWgk725f; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 08:10:33 -0000 On Feb 11, 2009, at 9:08 AM, JP Vasseur wrote: > Dear WG, > > As indicated in a previous email, the protocol survey I-D will be > send for publication this week (after posting of the last revision > incorporating several useful comments). > > As promised please find below the new proposed charter to be > submitted to the IESG for approval. In the hope of getting quickly > re-chartered thanks to let us know if you have any comment by the > ned of this week. The new charter is pretty straightforward. > > Thanks to Dave Ward for his comments and guidance. > > Description of Working Group: > > Low power and Lossy networks (LLNs) are typically composed of many > embedded devices with limited power, memory, and processing resources > interconnected by a variety of links, such as IEEE 802.15.4, > Bluetooth, > Low Power WiFi 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. LLNs > have specific characteristics: > - LLNs operate with a hard, very small bound on state, > - In most cases, LLN need to be optimized for energy saving, > - Typical traffic patterns are not simply unicast flows, > - In most cases, LLNs need to be effective with very small > packet sizes, > - LLN routing protocols have to be very careful when trading > off efficiency for generality; many LLN nodes do not have resources > to waste. > > These unique properties lead to unique routing requirements that may > not met by > existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For > example path selection must be designed to take into consideration the > specific power capabilities, attributes and functional characteristics > of the links and nodes in the network. > > > > 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 home, healthcare, environmental monitoring, > urban sensor networks sensor networks, assets tracking, refrigeration. > The Working Group will only focus on routing solutions for a subset of > these. It will focus on industrial, connected home, building and urban > sensor networks and specify the set of routing requirements for > these scenarios. > > The Working Group focuses only on IPv6 only 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 explore aspects of mobility within a single LLN > (if any) in the routing requirement creation. > > The Working Group will pay particular attention to routing security > and > manageability (e.g., self 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. > > > 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 protocols 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: In light of the application specific routing > requirements, the Working Group will either specify a new protocol > and/or will select an existing routing protocol (with the > appropriate extensions in cooperation with the relevant Working > Group). > > - Documentation of applicability statement of ROLL routing protocols. > > Goals and Milestones: > > Done Submit Routing requirements for Industrial applications to > the IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Connected Home networks > applications to the IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Building applications to the > IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Urban networks applications > to the IESG to be considered as an Informational RFC. > July 2009 Submit Routing metrics for LLNs document to the IESG to > be considered as a Proposed Standard. > * Feb 2009 Submit Protocol Survey to the IESG to be considered as > an Informational RFC. > April 2009 Submit Security Framework to the IESG to be considered > as an Informational RFC > May 2009 Submit the Routing for LLNs Architecture document to > the IESG as an Informational RFC. > July 2009 Submit first draft of ROLL routing protocol > specification as Proposed Standard. > Nov 2009 Submit first draft of the MIB module of the ROLL > routing protocol specification. > Dec 2009 Submit the ROLL routing protocol specification to the > IESG as Proposed Standard. > Jan 2010 Submit the MIB module of the ROLL routing protocol > specification to the IESG as Proposed Standard. > Jan 2010 Evaluate WG progress, recharter or close. > > PS: I marked * the Milestones that will be "This Week" and before > submitting to the IESG for re-chartering. > > > > Thanks. > > JP and David. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From Jerald.P.Martocci@jci.com Wed Feb 11 06:43:10 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21DB528C0CE; Wed, 11 Feb 2009 06:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXDATziD2cxo; Wed, 11 Feb 2009 06:43:03 -0800 (PST) Received: from exprod8og106.obsmtp.com (exprod8og106.obsmtp.com [64.18.3.92]) by core3.amsl.com (Postfix) with ESMTP id 2EC9E3A6928; Wed, 11 Feb 2009 06:43:03 -0800 (PST) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob106.postini.com ([64.18.7.12]) with SMTP ID DSNKSZLj7rk0Tj+I8OmkvNfKQ2JKSaJ/LXUi@postini.com; Wed, 11 Feb 2009 06:43:08 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009021108435599-4833646 ; Wed, 11 Feb 2009 08:43:55 -0600 In-Reply-To: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> MIME-Version: 1.0 To: JP Vasseur X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Wed, 11 Feb 2009 08:42:33 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 02/11/2009 08:42:42 AM, Serialize complete at 02/11/2009 08:42:42 AM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 02/11/2009 08:43:56 AM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 02/11/2009 08:44:21 AM, Serialize complete at 02/11/2009 08:44:21 AM Content-Type: multipart/alternative; boundary="=_alternative 0050CD708625755A_=" Cc: ROLL WG , roll-bounces@ietf.org, "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 14:43:10 -0000 This is a multipart message in MIME format. --=_alternative 0050CD708625755A_= Content-Type: text/plain; charset="US-ASCII" JP, David, Looks good. Comments interlaced below: JP Vasseur Sent by: roll-bounces@ietf.org 02/11/2009 02:08 AM To ROLL WG cc "David E. Culler" Subject [Roll] ROLL re-chartering Dear WG, As indicated in a previous email, the protocol survey I-D will be send for publication this week (after posting of the last revision incorporating several useful comments). As promised please find below the new proposed charter to be submitted to the IESG for approval. In the hope of getting quickly re-chartered thanks to let us know if you have any comment by the ned of this week. The new charter is pretty straightforward. Thanks to Dave Ward for his comments and guidance. Description of Working Group: Low power and Lossy networks (LLNs) are typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi or other low power PLC (Powerline Communication) links. I would like to more explicitly note 'wired' sensor networks. While PLC is a specific instance of a wired network, traditional wired sensors will predominate the building market for many years. Fire and Security applications may stay wired for decades. Our solutions must be viable to both wired and wireless solutions. 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. LLNs have specific characteristics: - LLNs operate with a hard, very small bound on state, - In most cases, LLN need to be optimized for energy saving, - Typical traffic patterns are not simply unicast flows, - In most cases, LLNs need to be effective with very small packet sizes, - LLN routing protocols have to be very careful when trading off efficiency for generality; many LLN nodes do not have resources to waste. If you're looking for other characteristics: LLNs must guarantee packet delivery within stringent timing requirements. These unique properties lead to unique routing requirements that may Should we be more emphatic about existing routing protocols not meeting the requirements? That is, 'may' s/b 'are' not met by existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For example path selection must be designed to take into consideration the specific power capabilities, attributes and functional characteristics of the links and nodes in the network. 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 home, healthcare, environmental monitoring, urban sensor networks sensor networks, assets tracking, refrigeration. The Working Group will only focus on routing solutions for a subset of these. It will focus on industrial, connected home, building and urban sensor networks and specify the set of routing requirements for these scenarios. The Working Group focuses only on IPv6 only routing architectural One too many 'only'. Delete the second 'only' 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 explore aspects of mobility within a single LLN (if any) in the routing requirement creation. The Working Group will pay particular attention to routing security and manageability (e.g., self 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. 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 protocols 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: In light of the application specific routing requirements, the Working Group will either specify a new protocol and/ or will select an existing routing protocol (with the appropriate extensions in cooperation with the relevant Working Group). - Documentation of applicability statement of ROLL routing protocols. Goals and Milestones: Done Submit Routing requirements for Industrial applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Connected Home networks applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Building applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Urban networks applications to the IESG to be considered as an Informational RFC. July 2009 Submit Routing metrics for LLNs document to the IESG to be considered as a Proposed Standard. * Feb 2009 Submit Protocol Survey to the IESG to be considered as an Informational RFC. April 2009 Submit Security Framework to the IESG to be considered as an Informational RFC May 2009 Submit the Routing for LLNs Architecture document to the IESG as an Informational RFC. July 2009 Submit first draft of ROLL routing protocol specification as Proposed Standard. Nov 2009 Submit first draft of the MIB module of the ROLL routing protocol specification. Dec 2009 Submit the ROLL routing protocol specification to the IESG as Proposed Standard. Jan 2010 Submit the MIB module of the ROLL routing protocol specification to the IESG as Proposed Standard. Jan 2010 Evaluate WG progress, recharter or close. Since a completely new routing protocol may need to be drafted, I think a submittal date of July 2009 for the new ROLL protocols is very aggressive. You may want to give the WG a few more months. PS: I marked * the Milestones that will be "This Week" and before submitting to the IESG for re-chartering. Thanks. JP and David. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 0050CD708625755A_= Content-Type: text/html; charset="US-ASCII"
JP, David,

Looks good.  Comments interlaced below:




JP Vasseur <jvasseur@cisco.com>
Sent by: roll-bounces@ietf.org

02/11/2009 02:08 AM

To
ROLL WG <roll@ietf.org>
cc
"David E. Culler" <culler@eecs.berkeley.edu>
Subject
[Roll] ROLL re-chartering





Dear WG,

As indicated in a previous email, the protocol survey I-D will be send  
for publication this week (after posting of the last revision  
incorporating several useful comments).

As promised please find below the new proposed charter to be submitted  
to the IESG for approval. In the hope of getting quickly re-chartered  
thanks to let us know if you have any comment by the ned of this week.  
The new charter is pretty straightforward.

Thanks to Dave Ward for his comments and guidance.

Description of Working Group:

Low power and Lossy networks (LLNs) are typically composed of many
embedded devices with limited power, memory, and processing resources
interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth,
Low Power WiFi or other low power PLC (Powerline Communication) links.
I would like to more explicitly note 'wired' sensor networks.  While PLC is a specific instance of a wired network, traditional wired sensors will predominate the building market for many years.  Fire and Security applications may stay wired for decades.  Our solutions must be viable to both wired and wireless solutions.

 
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. LLNs have  
specific characteristics:
-       LLNs operate with a hard, very small bound on state,
-       In most cases, LLN need to be optimized for energy saving,
-       Typical traffic patterns are not simply unicast flows,
-       In most cases, LLNs need to be effective with very small  
packet sizes,
-       LLN routing protocols have to be very careful when trading off  
efficiency for generality; many LLN nodes do not have resources to  
waste.
If you're looking for other characteristics: LLNs must guarantee packet delivery within stringent timing requirements.

These unique properties lead to unique routing requirements that may

Should we be more emphatic about existing routing protocols not meeting the requirements?  That is, 'may' s/b 'are'
 
not met by
 existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For
example path selection must be designed to take into consideration the
specific power capabilities, attributes and functional characteristics
of the links and nodes in the network.



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 home, healthcare, environmental monitoring,
urban sensor networks sensor networks, assets tracking, refrigeration.
The Working Group will only focus on routing solutions for a subset of
these. It will focus on industrial, connected home, building and urban
 sensor networks and specify the set of routing requirements for
 these scenarios.

The Working Group focuses only on IPv6 only routing architectural
One too many 'only'. Delete the second 'only'

 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 explore aspects of mobility within a single LLN
(if any) in the routing requirement creation.

The Working Group will pay particular attention to routing security and
manageability (e.g., self 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.


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 protocols 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: In light of the application specific routing  
requirements, the Working Group will either specify a new protocol and/
or will select an existing routing protocol (with the appropriate  
extensions in cooperation with the relevant Working Group).

- Documentation of applicability statement of ROLL routing protocols.

Goals and Milestones:

Done   Submit Routing requirements for Industrial applications to the  
IESG to be considered as an Informational RFC.
Done   Submit  Routing requirements for Connected Home networks  
applications to the IESG to be considered as an Informational RFC.
Done   Submit Routing requirements for Building applications to the  
IESG to be considered as an Informational RFC.
Done   Submit Routing requirements for Urban networks applications to  
the IESG to be considered as an Informational RFC.
July 2009    Submit Routing metrics for LLNs document to the IESG to  
be considered as a Proposed Standard.
* Feb 2009   Submit Protocol Survey to the IESG to be considered as an  
Informational RFC.
April 2009   Submit Security Framework to the IESG to be considered as  
an Informational RFC
May 2009     Submit the Routing for LLNs Architecture document to the  
IESG as an Informational RFC.
July 2009    Submit first draft of ROLL routing protocol specification  
as Proposed Standard.
Nov 2009     Submit first draft of the MIB module of the ROLL routing  
protocol specification.
Dec 2009     Submit the ROLL routing protocol specification to the  
IESG as Proposed Standard.
Jan 2010     Submit the MIB module of the ROLL routing protocol  
specification to the IESG as Proposed Standard.
Jan 2010     Evaluate WG progress, recharter or close.
Since a completely new routing protocol may need to be drafted, I think a submittal date of July 2009 for the new ROLL protocols is very aggressive.  You may want to give the WG a few more months.


PS: I marked * the Milestones that will be "This Week" and before  
submitting to the IESG for re-chartering.



Thanks.

JP and David.
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 0050CD708625755A_=-- From jvasseur@cisco.com Wed Feb 11 07:26:08 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C47328C1A0 for ; Wed, 11 Feb 2009 07:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.064 X-Spam-Level: X-Spam-Status: No, score=-10.064 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2WB4MB9aedO for ; Wed, 11 Feb 2009 07:26:06 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 22B0428C1B6 for ; Wed, 11 Feb 2009 07:26:04 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,192,1233532800"; d="scan'208,217";a="33497700" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Feb 2009 15:26:06 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1BFQ6AG001468; Wed, 11 Feb 2009 16:26:06 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1BFQ6VS024594; Wed, 11 Feb 2009 15:26:06 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Feb 2009 16:26:06 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Feb 2009 16:26:05 +0100 Message-Id: <83490662-93C0-4BF8-8F04-3F6C793C7E91@cisco.com> From: JP Vasseur To: Jerald.P.Martocci@jci.com In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-81-508211164 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Feb 2009 16:26:05 +0100 References: X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 11 Feb 2009 15:26:05.0925 (UTC) FILETIME=[0E764950:01C98C5D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=22162; t=1234365966; x=1235229966; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20re-chartering |Sender:=20; bh=JkCn0sgD86oRwJEwKcYY5XmQGwGvJC32G34b6fv7Cng=; b=UrizzM3kscfG/o+VCYHr1Ttr6Q4sMouso2prVJMIz+/77CKe0IJSzEP7Li F52Ds8TYVyV8XvpBsNL0FbNMcQg0QhhkaQMqieXebLUHMfnydNzSru+Qxkrv Jx8a5+Fx7g; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 15:26:08 -0000 --Apple-Mail-81-508211164 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Jerry, Thanks. See in line. On Feb 11, 2009, at 3:42 PM, Jerald.P.Martocci@jci.com wrote: > > JP, David, > > Looks good. Comments interlaced below: > > > > > JP Vasseur > Sent by: roll-bounces@ietf.org > 02/11/2009 02:08 AM > > To > ROLL WG > cc > "David E. Culler" > Subject > [Roll] ROLL re-chartering > > > > > > Dear WG, > > As indicated in a previous email, the protocol survey I-D will be send > for publication this week (after posting of the last revision > incorporating several useful comments). > > As promised please find below the new proposed charter to be submitted > to the IESG for approval. In the hope of getting quickly re-chartered > thanks to let us know if you have any comment by the ned of this week. > The new charter is pretty straightforward. > > Thanks to Dave Ward for his comments and guidance. > > Description of Working Group: > > Low power and Lossy networks (LLNs) are typically composed of many > embedded devices with limited power, memory, and processing resources > interconnected by a variety of links, such as IEEE 802.15.4, > Bluetooth, > Low Power WiFi or other low power PLC (Powerline Communication) links. > I would like to more explicitly note 'wired' sensor networks. While > PLC is a specific instance of a wired network, traditional wired > sensors will predominate the building market for many years. Fire > and Security applications may stay wired for decades. Our solutions > must be viable to both wired and wireless solutions. > JP> Yes. Let's keep the word "embedded devices" to stay as generic as possible. We explicitly added PLC, let's also add "wired" link as well. Agree. > > 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. LLNs have > specific characteristics: > - LLNs operate with a hard, very small bound on state, > - In most cases, LLN need to be optimized for energy saving, > - Typical traffic patterns are not simply unicast flows, > - In most cases, LLNs need to be effective with very small > packet sizes, > - LLN routing protocols have to be very careful when trading off > efficiency for generality; many LLN nodes do not have resources to > waste. > If you're looking for other characteristics: LLNs must guarantee > packet delivery within stringent timing requirements. JP> Well it is an application specific requirement (captured in some application-specific) routing requirement I-D. We just tried here to capture the most common denominators. > > > These unique properties lead to unique routing requirements that may > > Should we be more emphatic about existing routing protocols not > meeting the requirements? That is, 'may' s/b 'are' > > not met by > existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. JP> That part should have been tweaked. Thanks. These unique properties lead to unique routing requirements that are not met by existing routing protocols (in their current state), such as OSPF, IS- IS, AODV and OLSR, which does not preclude existing protocols from being extended to meet these specific requirements. > For > example path selection must be designed to take into consideration the > specific power capabilities, attributes and functional characteristics > of the links and nodes in the network. > > > > 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 home, healthcare, environmental monitoring, > urban sensor networks sensor networks, assets tracking, refrigeration. > The Working Group will only focus on routing solutions for a subset of > these. It will focus on industrial, connected home, building and urban > sensor networks and specify the set of routing requirements for > these scenarios. > > The Working Group focuses only on IPv6 only routing architectural > One too many 'only'. Delete the second 'only' JP> We wanted to insist a bit ;-) ... Thanks. > > > 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 explore aspects of mobility within a single LLN > (if any) in the routing requirement creation. > > The Working Group will pay particular attention to routing security > and > manageability (e.g., self 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. > > > 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 protocols 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: In light of the application specific routing > requirements, the Working Group will either specify a new protocol > and/ > or will select an existing routing protocol (with the appropriate > extensions in cooperation with the relevant Working Group). > > - Documentation of applicability statement of ROLL routing protocols. > > Goals and Milestones: > > Done Submit Routing requirements for Industrial applications to the > IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Connected Home networks > applications to the IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Building applications to the > IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Urban networks applications to > the IESG to be considered as an Informational RFC. > July 2009 Submit Routing metrics for LLNs document to the IESG to > be considered as a Proposed Standard. > * Feb 2009 Submit Protocol Survey to the IESG to be considered as an > Informational RFC. > April 2009 Submit Security Framework to the IESG to be considered as > an Informational RFC > May 2009 Submit the Routing for LLNs Architecture document to the > IESG as an Informational RFC. > July 2009 Submit first draft of ROLL routing protocol specification > as Proposed Standard. > Nov 2009 Submit first draft of the MIB module of the ROLL routing > protocol specification. > Dec 2009 Submit the ROLL routing protocol specification to the > IESG as Proposed Standard. > Jan 2010 Submit the MIB module of the ROLL routing protocol > specification to the IESG as Proposed Standard. > Jan 2010 Evaluate WG progress, recharter or close. > > Since a completely new routing protocol may need to be drafted, I > think a submittal date of July 2009 for the new ROLL protocols is > very aggressive. You may want to give the WG a few more months. It is hard to tell ... if extensions to an existing protocol is the way to go, we should be fine. If a new protocol is defined, this is aggressive but it has been done in the past. I prefer to stick with aggressive dates. Thanks Jerry for the comments. JP. > > > > PS: I marked * the Milestones that will be "This Week" and before > submitting to the IESG for re-chartering. > > > > Thanks. > > JP and David. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --Apple-Mail-81-508211164 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Jerry,

Thanks. See in = line.

On Feb 11, 2009, at 3:42 PM, Jerald.P.Martocci@jci.com = wrote:


JP, David,

Looks good.  Comments = interlaced below:




JP Vasseur <jvasseur@cisco.com> =
Sent by: roll-bounces@ietf.org

<= font size=3D"1" face=3D"sans-serif">02/11/2009 02:08 AM =

To
ROLL WG <roll@ietf.org>
cc
"David E. Culler" <culler@eecs.berkeley.edu>
Subject
[Roll] ROLL = re-chartering

=



Dear = WG,

As indicated in a previous email, the protocol survey I-D = will be send  
for publication this week (after posting of the = last revision  
incorporating several useful comments).
=
As promised please find below the new proposed charter to be = submitted  
to the IESG for approval. In the hope of getting = quickly re-chartered  
thanks to let us know if you have any = comment by the ned of this week.  
The new charter is pretty = straightforward.

Thanks to Dave Ward for his comments and = guidance.

Description of Working Group:

Low power and = Lossy networks (LLNs) are typically composed of many
embedded = devices with limited power, memory, and processing resources
= interconnected by a variety of links, such as IEEE 802.15.4, = Bluetooth,
Low Power WiFi or other low power PLC (Powerline = Communication) links.
I would like to more explicitly note 'wired' = sensor networks.  While PLC is a specific instance of a wired = network, traditional wired sensors will predominate the building market = for many years.  Fire and Security applications may stay wired for = decades.  Our solutions must be viable to both wired and wireless = solutions.


JP> Yes. = Let's keep the word "embedded devices" to stay as generic as = possible.
We explicitly added PLC, let's also add = "wired" link as well. Agree.

 
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. LLNs have  
specific characteristics:
-   =     LLNs operate with a hard, very small bound on state,
- =       In most cases, LLN need to be optimized for energy = saving,
-       Typical traffic patterns are not = simply unicast flows,
-       In most cases, LLNs = need to be effective with very small  
packet sizes,
- =       LLN routing protocols have to be very careful when = trading off  
efficiency for generality; many LLN nodes do not = have resources to  
waste.
If you're looking for other = characteristics: LLNs must guarantee packet delivery within stringent = timing requirements.

JP> Well = it is an application specific requirement (captured in some = application-specific) routing
requirement I-D. We just tried = here to capture the most common denominators.



These unique properties lead to unique routing = requirements that may

Should we be more emphatic about = existing routing protocols not meeting the requirements?  That is, = 'may' s/b 'are'
 
not met = by
 existing routing protocols, such as OSPF, IS-IS, AODV and = OLSR.

JP> That part should = have been tweaked. Thanks.

These unique properties lead to unique routing = requirements that are not met by
existing routing = protocols (in their current state), such as OSPF, IS-IS, = AODV 
and OLSR, which does not preclude existing = protocols from being extended to meet = these
specific = requirements.

For
example path selection must be designed to take = into consideration the
specific power capabilities, attributes and = functional characteristics
of the links and nodes in the = network.



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 home, healthcare, = environmental monitoring,
urban sensor networks sensor networks, = assets tracking, refrigeration.
The Working Group will only focus on = routing solutions for a subset of
these. It will focus on = industrial, connected home, building and urban
 sensor networks = and specify the set of routing requirements for
 these = scenarios.

The Working Group focuses only on IPv6 only routing = architectural
One too many 'only'. Delete the second = 'only'

JP> We wanted to = insist a bit ;-) ... Thanks.



 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 explore aspects = of mobility within a single LLN
(if any) in the routing requirement = creation.

The Working Group will pay particular attention to = routing security and
manageability (e.g., self 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.


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 protocols 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: In light of the application specific = routing  
requirements, the Working Group will either specify a = new protocol and/
or will select an existing routing protocol (with = the appropriate  
extensions in cooperation with the relevant = Working Group).

- Documentation of applicability statement of = ROLL routing protocols.

Goals and Milestones:

Done =   Submit Routing requirements for Industrial applications to the =  
IESG to be considered as an Informational RFC.
Done =   Submit  Routing requirements for Connected Home networks =  
applications to the IESG to be considered as an Informational = RFC.
Done   Submit Routing requirements for Building = applications to the  
IESG to be considered as an Informational = RFC.
Done   Submit Routing requirements for Urban networks = applications to  
the IESG to be considered as an Informational = RFC.
July 2009    Submit Routing metrics for LLNs document = to the IESG to  
be considered as a Proposed Standard.
* = Feb 2009   Submit Protocol Survey to the IESG to be considered as = an  
Informational RFC.
April 2009   Submit Security = Framework to the IESG to be considered as  
an Informational = RFC
May 2009     Submit the Routing for LLNs Architecture = document to the  
IESG as an Informational RFC.
July 2009 =    Submit first draft of ROLL routing protocol specification =  
as Proposed Standard.
Nov 2009     Submit first = draft of the MIB module of the ROLL routing  
protocol = specification.
Dec 2009     Submit the ROLL routing = protocol specification to the  
IESG as Proposed Standard.
= Jan 2010     Submit the MIB module of the ROLL routing = protocol  
specification to the IESG as Proposed Standard.
= Jan 2010     Evaluate WG progress, recharter or close.
=
Since a completely new routing protocol may need = to be drafted, I think a submittal date of July 2009 for the new ROLL = protocols is very aggressive.  You may want to give the WG a few = more months.

It is hard to = tell ... if extensions to an existing protocol is the way to go, we = should be fine. If a new protocol is defined, this is aggressive but it = has been done in the past. I prefer to stick = with aggressive dates.

Thanks Jerry = for the comments.

JP.




PS: I marked * the = Milestones that will be "This Week" and before  
submitting to = the IESG for re-chartering.



Thanks.

JP and = David.
_______________________________________________
Roll = mailing list
Roll@ietf.org
= https://www.ietf.org/m= ailman/listinfo/roll
 =

= --Apple-Mail-81-508211164-- From alexandru.petrescu@gmail.com Wed Feb 11 08:31:58 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64E903A6A9C; Wed, 11 Feb 2009 08:31:58 -0800 (PST) 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=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lU3jkEyONT6c; Wed, 11 Feb 2009 08:31:57 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id B07E13A69D2; Wed, 11 Feb 2009 08:31:56 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1BGUJlE012077; Wed, 11 Feb 2009 17:30:19 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1BGVxIl004411; Wed, 11 Feb 2009 17:31:59 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n1BGVxD1028530; Wed, 11 Feb 2009 17:31:59 +0100 Message-ID: <4992FD7F.8070408@gmail.com> Date: Wed, 11 Feb 2009 17:31:59 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: ROLL WG , 6lowpan@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] Comments on draft-ietf-6lowpan-routing-requirements-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 16:31:58 -0000 [Where should I post this message, to 6LoWPAN or to ROLL list? Both?] Dear WG members, draft-ietf-6lowpan-routing-requirements-00 lists a Problem Statement, some Scenarios and a set of Routing Requirements. Generally I find it a well written document, with many meaningful details. There are very many parts of this document to which I silently agree, even some parts I wholehartedly agree. I like the distinction route-above mesh-under, and many other parts too. Some high-level questions: -is there a requirement to connect a 6LoWPAN network to the Internet? -is the 6LoWPAN using addressing architecture and longest-prefix match based routing as in the Internet? -how many interfaces will a 15.4 device have potentially? Following are detail questions and comments. I believe they're not as important as the items mentioned above. > 1. Problem Statement Is this _the_ problem statement or should I better go read draft-ietf-6lowpan-problem-08? They differ largely... > The 6LoWPAN problem statement document ("6LoWPAN Problems and Goals" > [3]) briefly mentions four requirements on routing protocols; > > (a) low overhead on data packets > > (b) low routing overhead What is routing more generally? Is it the act a router performs when presenting with a packet, searching in a routing table, maybe exploring its ND structures, maybe sending ND messages and then emitting the packet? Or is it exchanging IP datagrams containing prefixes and metrics and reachability information, such that nodes have a common view of the network paths? I think this is worth discussing, in order to better target what the work should follow this problem statement and reqs. Are the low overhead requirements put on the database construction messages? Or on the individual act of forwarding a packet? > On the other hand, the route-over approach relies on IP routing and > therefore supports routing over possibly various types of > interconnected links (see also Figure 1). At several places in the draft, when link 'types', device 'types' are mentioned, I'm tempted to believe 6LoWPAN considers links other than 802.15.4 links? Is it so? Should 6LoWPAN routing protocol work also with aseptic point-to-point links? Or are the 'types' limited within the relatively large scope of 802.3 compatible MACs (I believe 802.15.4 and 802.16 to fit within). This is of paramount importance in setting the scope. > The most significant consequence of mesh-under routing is that > routing would be directly based on the IEEE 802.15.4 standard, Which 'routing' is directly based on 802.15.4 standard? The 'IP routing' is based on that standard? This brings back to defining what routing is. Maybe better call 'mesh-under routing' 'mesh-under switching'. IP routing and addressing may be fundamentally different than mesh-under addressing and switching - in the way hosts get and maintain their addresses and in the way routers/switches search their databases (exact match vs longest-prefix). > When a route-over protocol is built in the IPv6 layer, the Dispatch > value can be chosen as one of the Dispatch patterns for 6LoWPAN, > compressed or uncompressed IPv6, followed by the IPv6 header. Sorry, I can't parse this. A route-over protocol would act both at IP layer and application/transport layers. Depends what a routing protocol is. For example ICMP Redirect, or NEMOv6 or ND act at IP layer, whereas RIPng is over UDP. 'followed by'... when reading left to right or reverse? > For route-over, a default route to the ER could be inserted into the > routing system. In the routing system of the 6LoWPAN network? Or in the routing system of the fixed Internet network? > IP-based low-power WPAN technology is still in its early stage of 'WPAN'? > a. Network Properties: > > * Number of Devices, Density and Network Diameter: These parameters > usually affect the routing state directly (e.g. the number of > entries in a routing table or neighbor list). Especially in large > and dense networks, policies must What is 'large' and 'dense'? Is it about physical dimensions? Or IP dimensions? Density sounds as a physical characteristic (many devices in a small area) whereas Diameter sounds as a pure IP term (max number of IP hops). The number of entries in the routing table mostly depends on the planned addressing architecture. One can have a very high-diameter network with a very hierarchical addressing structures, many default routes, and very few entries in the routing tables (maybe only 1 per hop). Is the addressing architecture for 6LoWPAN networks planned? Is the addressing architecture following the Internet model? > b. Node Parameters: How many interfaces does a 6LoWPAN node typically have? This is of paramount importance deciding whether any type of repeating/bridging needs to happen. > * Throughput: The maximum user data throughput of a bulk data > transmission between a single sender and a single receiver through an > unslotted IEEE 802.15.4 2.4 GHz channel in ideal conditions is as > follows [19]: [...] > > In the case of 915 MHz band: Sorry, for my clarification: is 915MHz the width of band centered on the 2.4GHz mentioned above? Or is it the central frequency (thus replacing the "2.4GHz" mentioned above)? > [R02] 6LoWPAN routing protocols SHOULD cause minimal power > consumption by the efficient use of control packets (e.g., minimize > expensive multicast which cause broadcast to the entire LoWPAN) and > by the efficient routing of data packets. YEs, but multicast may be more efficient than broadcast - is it sufficient? I think it is sufficient to rely on multicast and avoid unnecessary duplication such as in broadcast. 'Efficient routing of data packets' - is it also efficient search in the routing table? That may be part of 'routing' too. > possibliy Nit: iy > [R03] 6LoWPAN routing protocol control messages SHOULD not create > fragmentation of physical layer (PHY) frames. Err... I think PHY frames aren't fragmented... not sure I understand this requirement? Sounds as if one wants an UDP control packets to not be sent in several pieces, because of overhead involved fragmenting/reassembling. Then make sure first IP doesn't fragment. > Therefore, 6LoWPAN routing should not cause packets to exceed the > IEEE 802.15.4 frame size [81bytes]. Is this a requirement on the mesh-under link-layer switching protocol? Or on the 'route-above' protocol? If the latter - I think this requirement is a violation of layer independence :-) It sounds very special to me to limit the size of the messages of an IP routing protocol. Knowing that IP can fragment too. > [R05] The design of routing protocols for 6LoWPANs must consider the > end-to-end latency requirements of applications and IEEE 802.15.4 > link latency characteristics. 'Routing'? Or 'Transport'? end-to-end is what Transport typically takes care of, not routing. If Routing: which routing? The forwarding ahppening at a node? Or the convergence time? The exchange of routing messages? > Some routing protocols are aware of the hop count of a path. I think all of them are, no? > In homes, buildings, or infrastructure, some nodes will be installed > with mains power. Such power-installed nodes MUST be If they have mains power - will they use Power-Line Communications? > Building monitoring applications, for instance, require that the > mobile devices SHOULD be capable of leaving (handing-off) from an old > network joining onto a new network within 15 seconds [17]. Should such a mobile device change its IP address or is it free to change it? > [R13] 6LoWPAN routing protocol SHOULD support various traffic > patterns; point-to-point, point-to-multipoint, and multipoint-to- > point, while avoid excessive multicast traffic (broadcast in link > layer) in 6LoWPAN. It's called multicast at link-layer too (802.3); thus it avoids unnecessary packet duplication, thus it avoids duplication of broadcasted packets and thus avoids excessive traffic. If we talk IPv6 and recent link layers then I mostly forget the term 'broadcast' and use multicast instead. > 6LoWPAN routing protocols should be designed with the consideration > of forwarding packets from/to multiple sources/destinations. Sorry, what do you mean? An IP packet with multiple src fields? > Current WG drafts in the ROLL working group explain that the workload > or traffic pattern of use cases for 6LoWPANs tend to be highly > structured, unlike the any- to-any data transfers that dominate > typical client and server workloads. Sorry, what do you mean by 'any-to-any' data transfers? Any relationship to 'IP anycast'? > [R14] 6LoWPAN protocols SHOULD support secure delivery of control > messages. A minimal security level can be achieved by utilizing AES- > based mechanism provided by IEEE 802.15.4. Isn't AES superstrong and thus computation intensive and thus energy intensive? Intuitively speaking, maybe SHA-1 is sufficient for reduced needs in constrained environments. > [R16] For neighbor discovery, 6LoWPAN devices SHOULD avoid sending > "Hello" messages. ND doesn't send Hello messages, but NS, NA, RS and RA. > [R18] If the routing protocol functionality includes enabling IP > multicast, then it may want to employ coordinator roles, if any, as > relay points of group-targeting messages instead of using link-layer > multicast (broadcast). link-layer multicast no broadcast. Nit: 'MAC sub-layer' appears only once and in the figure they're all 'layers'. Alex From prvs=28688a5f1=mukul@uwm.edu Wed Feb 11 13:21:25 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBD973A67F0 for ; Wed, 11 Feb 2009 13:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1Pa-0K5KXQe for ; Wed, 11 Feb 2009 13:21:24 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 4E24D3A6862 for ; Wed, 11 Feb 2009 13:21:21 -0800 (PST) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta.uwm.edu with ESMTP; 11 Feb 2009 15:21:25 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 96A33C085D5; Wed, 11 Feb 2009 15:21:25 -0600 (CST) X-Virus-Scanned: amavisd-new at Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4Zdz8rje2Rz; Wed, 11 Feb 2009 15:21:23 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 68C2EC085C2; Wed, 11 Feb 2009 15:21:23 -0600 (CST) Date: Wed, 11 Feb 2009 15:21:23 -0600 (CST) From: Mukul Goyal To: JP Vasseur Message-ID: <1777404815.9532371234387283323.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.10_GA_2638.RHEL4_64 (ZimbraWebClient - IE7 (Win)/5.0.10_GA_2638.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 21:21:57 -0000 The re-charter text gives the impression that ROLL plans to standardize _one_ routing protocol. Is it the intention? Thanks Mukul Goyal ----- Original Message ----- From: "JP Vasseur" To: "ROLL WG" Cc: "David E. Culler" Sent: Wednesday, February 11, 2009 2:08:00 AM GMT -06:00 US/Canada Central Subject: [Roll] ROLL re-chartering Dear WG, As indicated in a previous email, the protocol survey I-D will be send for publication this week (after posting of the last revision incorporating several useful comments). As promised please find below the new proposed charter to be submitted to the IESG for approval. In the hope of getting quickly re-chartered thanks to let us know if you have any comment by the ned of this week. The new charter is pretty straightforward. Thanks to Dave Ward for his comments and guidance. Description of Working Group: Low power and Lossy networks (LLNs) are typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi 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. LLNs have specific characteristics: - LLNs operate with a hard, very small bound on state, - In most cases, LLN need to be optimized for energy saving, - Typical traffic patterns are not simply unicast flows, - In most cases, LLNs need to be effective with very small packet sizes, - LLN routing protocols have to be very careful when trading off efficiency for generality; many LLN nodes do not have resources to waste. These unique properties lead to unique routing requirements that may not met by existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For example path selection must be designed to take into consideration the specific power capabilities, attributes and functional characteristics of the links and nodes in the network. 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 home, healthcare, environmental monitoring, urban sensor networks sensor networks, assets tracking, refrigeration. The Working Group will only focus on routing solutions for a subset of these. It will focus on industrial, connected home, building and urban sensor networks and specify the set of routing requirements for these scenarios. The Working Group focuses only on IPv6 only 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 explore aspects of mobility within a single LLN (if any) in the routing requirement creation. The Working Group will pay particular attention to routing security and manageability (e.g., self 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. 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 protocols 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: In light of the application specific routing requirements, the Working Group will either specify a new protocol and/ or will select an existing routing protocol (with the appropriate extensions in cooperation with the relevant Working Group). - Documentation of applicability statement of ROLL routing protocols. Goals and Milestones: Done Submit Routing requirements for Industrial applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Connected Home networks applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Building applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Urban networks applications to the IESG to be considered as an Informational RFC. July 2009 Submit Routing metrics for LLNs document to the IESG to be considered as a Proposed Standard. * Feb 2009 Submit Protocol Survey to the IESG to be considered as an Informational RFC. April 2009 Submit Security Framework to the IESG to be considered as an Informational RFC May 2009 Submit the Routing for LLNs Architecture document to the IESG as an Informational RFC. July 2009 Submit first draft of ROLL routing protocol specification as Proposed Standard. Nov 2009 Submit first draft of the MIB module of the ROLL routing protocol specification. Dec 2009 Submit the ROLL routing protocol specification to the IESG as Proposed Standard. Jan 2010 Submit the MIB module of the ROLL routing protocol specification to the IESG as Proposed Standard. Jan 2010 Evaluate WG progress, recharter or close. PS: I marked * the Milestones that will be "This Week" and before submitting to the IESG for re-chartering. Thanks. JP and David. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Wed Feb 11 13:31:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 537623A6812 for ; Wed, 11 Feb 2009 13:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGovwF7QalQP for ; Wed, 11 Feb 2009 13:31:08 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5ED253A680B for ; Wed, 11 Feb 2009 13:31:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,194,1233532800"; d="scan'208";a="33529996" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Feb 2009 21:31:10 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1BLVB5u026890; Wed, 11 Feb 2009 22:31:11 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1BLVBwd025654; Wed, 11 Feb 2009 21:31:11 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Feb 2009 22:31:10 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Feb 2009 22:31:09 +0100 Message-Id: From: JP Vasseur To: Mukul Goyal In-Reply-To: <1777404815.9532371234387283323.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Feb 2009 22:31:09 +0100 References: <1777404815.9532371234387283323.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 11 Feb 2009 21:31:09.0770 (UTC) FILETIME=[0E2BCAA0:01C98C90] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7452; t=1234387871; x=1235251871; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20re-chartering |Sender:=20; bh=f3aorq0usHrwsFJBD5D+bCYBRDagF8RmyaMxl2DFpw4=; b=s+RpyAyarH7YzQYNIpQ1KtxFhtwI61ywt+JuvwRcgtszzlhJm6jq870BVB zfPhnNWFyBgilrc0qn4Y3OMata1zf25BZW3gCoobV5ewja6lGLdd6qpHmi+j lYyptbQA35; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 21:31:09 -0000 Hi, On Feb 11, 2009, at 10:21 PM, Mukul Goyal wrote: > The re-charter text gives the impression that ROLL plans to > standardize _one_ routing protocol. Is it the intention? > Not yet determined. As we pointed before, the goal is always to have the minimum number of protocols (1 !). If not possible, then each solution would have to be accompanied with an applicability statement and be clearly justified. One solution per application (extreme case) is of course not acceptable. In short, our objective, is one protocol. If not possible, which we will know during protocol work phase, we will decide at that point. Thanks. JP. > Thanks > Mukul Goyal > > ----- Original Message ----- > From: "JP Vasseur" > To: "ROLL WG" > Cc: "David E. Culler" > Sent: Wednesday, February 11, 2009 2:08:00 AM GMT -06:00 US/Canada > Central > Subject: [Roll] ROLL re-chartering > > Dear WG, > > As indicated in a previous email, the protocol survey I-D will be send > for publication this week (after posting of the last revision > incorporating several useful comments). > > As promised please find below the new proposed charter to be submitted > to the IESG for approval. In the hope of getting quickly re-chartered > thanks to let us know if you have any comment by the ned of this week. > The new charter is pretty straightforward. > > Thanks to Dave Ward for his comments and guidance. > > Description of Working Group: > > Low power and Lossy networks (LLNs) are typically composed of many > embedded devices with limited power, memory, and processing resources > interconnected by a variety of links, such as IEEE 802.15.4, > Bluetooth, > Low Power WiFi 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. LLNs have > specific characteristics: > - LLNs operate with a hard, very small bound on state, > - In most cases, LLN need to be optimized for energy saving, > - Typical traffic patterns are not simply unicast flows, > - In most cases, LLNs need to be effective with very small > packet sizes, > - LLN routing protocols have to be very careful when trading off > efficiency for generality; many LLN nodes do not have resources to > waste. > > These unique properties lead to unique routing requirements that may > not met by > existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For > example path selection must be designed to take into consideration the > specific power capabilities, attributes and functional characteristics > of the links and nodes in the network. > > > > 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 home, healthcare, environmental monitoring, > urban sensor networks sensor networks, assets tracking, refrigeration. > The Working Group will only focus on routing solutions for a subset of > these. It will focus on industrial, connected home, building and urban > sensor networks and specify the set of routing requirements for > these scenarios. > > The Working Group focuses only on IPv6 only 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 explore aspects of mobility within a single LLN > (if any) in the routing requirement creation. > > The Working Group will pay particular attention to routing security > and > manageability (e.g., self 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. > > > 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 protocols 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: In light of the application specific routing > requirements, the Working Group will either specify a new protocol > and/ > or will select an existing routing protocol (with the appropriate > extensions in cooperation with the relevant Working Group). > > - Documentation of applicability statement of ROLL routing protocols. > > Goals and Milestones: > > Done Submit Routing requirements for Industrial applications to the > IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Connected Home networks > applications to the IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Building applications to the > IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Urban networks applications to > the IESG to be considered as an Informational RFC. > July 2009 Submit Routing metrics for LLNs document to the IESG to > be considered as a Proposed Standard. > * Feb 2009 Submit Protocol Survey to the IESG to be considered as an > Informational RFC. > April 2009 Submit Security Framework to the IESG to be considered as > an Informational RFC > May 2009 Submit the Routing for LLNs Architecture document to the > IESG as an Informational RFC. > July 2009 Submit first draft of ROLL routing protocol specification > as Proposed Standard. > Nov 2009 Submit first draft of the MIB module of the ROLL routing > protocol specification. > Dec 2009 Submit the ROLL routing protocol specification to the > IESG as Proposed Standard. > Jan 2010 Submit the MIB module of the ROLL routing protocol > specification to the IESG as Proposed Standard. > Jan 2010 Evaluate WG progress, recharter or close. > > PS: I marked * the Milestones that will be "This Week" and before > submitting to the IESG for re-chartering. > > > > Thanks. > > JP and David. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=28688a5f1=mukul@uwm.edu Wed Feb 11 13:43:33 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DDE63A6B4D for ; Wed, 11 Feb 2009 13:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.308 X-Spam-Level: X-Spam-Status: No, score=-2.308 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clq+SUJtFW1D for ; Wed, 11 Feb 2009 13:43:32 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 37AD23A6B1A for ; Wed, 11 Feb 2009 13:43:32 -0800 (PST) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta.uwm.edu with ESMTP; 11 Feb 2009 15:43:36 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id BA0A8C085C9; Wed, 11 Feb 2009 15:43:36 -0600 (CST) X-Virus-Scanned: amavisd-new at Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECUyb0EDK0q0; Wed, 11 Feb 2009 15:43:36 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 56FC2C085C7; Wed, 11 Feb 2009 15:43:36 -0600 (CST) Date: Wed, 11 Feb 2009 15:43:36 -0600 (CST) From: Mukul Goyal To: JP Vasseur Message-ID: <645350922.9550021234388616247.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.10_GA_2638.RHEL4_64 (ZimbraWebClient - IE7 (Win)/5.0.10_GA_2638.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 21:43:33 -0000 I am not sure if it is a good idea. I dont think you can have one protocol that works best (and even good enough) in all 4 scenarios (home, building, industrial, urban) for all applications and at all scales. Why would I use a protocol, designed for 10000 battery-powered node network, in a 100 mains-powered node network? Further, there may be multiple very different protocols that have similar performance. I dont think the recharter text should retrict the number of protocols. Thanks Mukul ----- Original Message ----- From: "JP Vasseur" To: "Mukul Goyal" Cc: "David E. Culler" , "ROLL WG" Sent: Wednesday, February 11, 2009 3:31:09 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] ROLL re-chartering Hi, On Feb 11, 2009, at 10:21 PM, Mukul Goyal wrote: > The re-charter text gives the impression that ROLL plans to > standardize _one_ routing protocol. Is it the intention? > Not yet determined. As we pointed before, the goal is always to have the minimum number of protocols (1 !). If not possible, then each solution would have to be accompanied with an applicability statement and be clearly justified. One solution per application (extreme case) is of course not acceptable. In short, our objective, is one protocol. If not possible, which we will know during protocol work phase, we will decide at that point. Thanks. JP. > Thanks > Mukul Goyal > > ----- Original Message ----- > From: "JP Vasseur" > To: "ROLL WG" > Cc: "David E. Culler" > Sent: Wednesday, February 11, 2009 2:08:00 AM GMT -06:00 US/Canada > Central > Subject: [Roll] ROLL re-chartering > > Dear WG, > > As indicated in a previous email, the protocol survey I-D will be send > for publication this week (after posting of the last revision > incorporating several useful comments). > > As promised please find below the new proposed charter to be submitted > to the IESG for approval. In the hope of getting quickly re-chartered > thanks to let us know if you have any comment by the ned of this week. > The new charter is pretty straightforward. > > Thanks to Dave Ward for his comments and guidance. > > Description of Working Group: > > Low power and Lossy networks (LLNs) are typically composed of many > embedded devices with limited power, memory, and processing resources > interconnected by a variety of links, such as IEEE 802.15.4, > Bluetooth, > Low Power WiFi 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. LLNs have > specific characteristics: > - LLNs operate with a hard, very small bound on state, > - In most cases, LLN need to be optimized for energy saving, > - Typical traffic patterns are not simply unicast flows, > - In most cases, LLNs need to be effective with very small > packet sizes, > - LLN routing protocols have to be very careful when trading off > efficiency for generality; many LLN nodes do not have resources to > waste. > > These unique properties lead to unique routing requirements that may > not met by > existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For > example path selection must be designed to take into consideration the > specific power capabilities, attributes and functional characteristics > of the links and nodes in the network. > > > > 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 home, healthcare, environmental monitoring, > urban sensor networks sensor networks, assets tracking, refrigeration. > The Working Group will only focus on routing solutions for a subset of > these. It will focus on industrial, connected home, building and urban > sensor networks and specify the set of routing requirements for > these scenarios. > > The Working Group focuses only on IPv6 only 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 explore aspects of mobility within a single LLN > (if any) in the routing requirement creation. > > The Working Group will pay particular attention to routing security > and > manageability (e.g., self 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. > > > 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 protocols 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: In light of the application specific routing > requirements, the Working Group will either specify a new protocol > and/ > or will select an existing routing protocol (with the appropriate > extensions in cooperation with the relevant Working Group). > > - Documentation of applicability statement of ROLL routing protocols. > > Goals and Milestones: > > Done Submit Routing requirements for Industrial applications to the > IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Connected Home networks > applications to the IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Building applications to the > IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Urban networks applications to > the IESG to be considered as an Informational RFC. > July 2009 Submit Routing metrics for LLNs document to the IESG to > be considered as a Proposed Standard. > * Feb 2009 Submit Protocol Survey to the IESG to be considered as an > Informational RFC. > April 2009 Submit Security Framework to the IESG to be considered as > an Informational RFC > May 2009 Submit the Routing for LLNs Architecture document to the > IESG as an Informational RFC. > July 2009 Submit first draft of ROLL routing protocol specification > as Proposed Standard. > Nov 2009 Submit first draft of the MIB module of the ROLL routing > protocol specification. > Dec 2009 Submit the ROLL routing protocol specification to the > IESG as Proposed Standard. > Jan 2010 Submit the MIB module of the ROLL routing protocol > specification to the IESG as Proposed Standard. > Jan 2010 Evaluate WG progress, recharter or close. > > PS: I marked * the Milestones that will be "This Week" and before > submitting to the IESG for re-chartering. > > > > Thanks. > > JP and David. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Wed Feb 11 13:50:52 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A8A928C19D for ; Wed, 11 Feb 2009 13:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DAV3Gh8kMbj for ; Wed, 11 Feb 2009 13:50:50 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 19F9F28C120 for ; Wed, 11 Feb 2009 13:50:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,194,1233532800"; d="scan'208";a="33530876" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 11 Feb 2009 21:50:53 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1BLorPA011115; Wed, 11 Feb 2009 22:50:53 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1BLorNX028625; Wed, 11 Feb 2009 21:50:53 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Feb 2009 22:50:53 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Feb 2009 22:50:52 +0100 Message-Id: <91CC88ED-0051-4BFA-878F-FD94CD0A1822@cisco.com> From: JP Vasseur To: Mukul Goyal In-Reply-To: <645350922.9550021234388616247.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Feb 2009 22:50:52 +0100 References: <645350922.9550021234388616247.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 11 Feb 2009 21:50:52.0931 (UTC) FILETIME=[CF63D530:01C98C92] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9309; t=1234389053; x=1235253053; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20re-chartering |Sender:=20; bh=9hLpLHBr0guEUj91TkD67isSPBzYN1IeN0NYvImYxWQ=; b=e28QHYceKY+SL/lbyCpR0z2Rlai+/XwzoIxUpelTEZ0qBA7tZMyV6n/Ea1 ysW4AmoiOHCUllgro5ceCaXz3wZkUCh1ieGu8tw3nheQD7tj2CL1DhZwWEb9 PlkvwkDk1O; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 21:50:52 -0000 Hi, On Feb 11, 2009, at 10:43 PM, Mukul Goyal wrote: > I am not sure if it is a good idea. I dont think you can have one > protocol that works best (and even good enough) in all 4 scenarios > (home, building, industrial, urban) for all applications and at all > scales. Why would I use a protocol, designed for 10000 battery- > powered node network, in a 100 mains-powered node network? Further, > there may be multiple very different protocols that have similar > performance. I dont think the recharter text should retrict the > number of protocols. It does not. But as a general IETF rule we *always* try to avoid specifying many protocols. Remember that IP is good enough for everything. We will not try to find the best optimal solution for every situation. The work of the WG will be to try to find (extend, define) one protocol that meets our requirements. We will have to make compromise. But again, this is a premature discussion. The charter does not "restrict" anything. The comments above are general IETF rule that do apply for ROLL. Thanks. JP. > > > Thanks > Mukul > > ----- Original Message ----- > From: "JP Vasseur" > To: "Mukul Goyal" > Cc: "David E. Culler" , "ROLL WG" > > Sent: Wednesday, February 11, 2009 3:31:09 PM GMT -06:00 US/Canada > Central > Subject: Re: [Roll] ROLL re-chartering > > Hi, > > On Feb 11, 2009, at 10:21 PM, Mukul Goyal wrote: > >> The re-charter text gives the impression that ROLL plans to >> standardize _one_ routing protocol. Is it the intention? >> > > Not yet determined. As we pointed before, the goal is always to have > the minimum number of protocols (1 !). > If not possible, then each solution would have to be accompanied with > an applicability statement and be > clearly justified. One solution per application (extreme case) is of > course not acceptable. In short, our objective, > is one protocol. If not possible, which we will know during protocol > work phase, we will decide at that point. > > Thanks. > > JP. > >> Thanks >> Mukul Goyal >> >> ----- Original Message ----- >> From: "JP Vasseur" >> To: "ROLL WG" >> Cc: "David E. Culler" >> Sent: Wednesday, February 11, 2009 2:08:00 AM GMT -06:00 US/Canada >> Central >> Subject: [Roll] ROLL re-chartering >> >> Dear WG, >> >> As indicated in a previous email, the protocol survey I-D will be >> send >> for publication this week (after posting of the last revision >> incorporating several useful comments). >> >> As promised please find below the new proposed charter to be >> submitted >> to the IESG for approval. In the hope of getting quickly re-chartered >> thanks to let us know if you have any comment by the ned of this >> week. >> The new charter is pretty straightforward. >> >> Thanks to Dave Ward for his comments and guidance. >> >> Description of Working Group: >> >> Low power and Lossy networks (LLNs) are typically composed of many >> embedded devices with limited power, memory, and processing resources >> interconnected by a variety of links, such as IEEE 802.15.4, >> Bluetooth, >> Low Power WiFi 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. LLNs >> have >> specific characteristics: >> - LLNs operate with a hard, very small bound on state, >> - In most cases, LLN need to be optimized for energy saving, >> - Typical traffic patterns are not simply unicast flows, >> - In most cases, LLNs need to be effective with very small >> packet sizes, >> - LLN routing protocols have to be very careful when trading >> off >> efficiency for generality; many LLN nodes do not have resources to >> waste. >> >> These unique properties lead to unique routing requirements that may >> not met by >> existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For >> example path selection must be designed to take into consideration >> the >> specific power capabilities, attributes and functional >> characteristics >> of the links and nodes in the network. >> >> >> >> 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 home, healthcare, environmental monitoring, >> urban sensor networks sensor networks, assets tracking, >> refrigeration. >> The Working Group will only focus on routing solutions for a subset >> of >> these. It will focus on industrial, connected home, building and >> urban >> sensor networks and specify the set of routing requirements for >> these scenarios. >> >> The Working Group focuses only on IPv6 only 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 explore aspects of mobility within a single >> LLN >> (if any) in the routing requirement creation. >> >> The Working Group will pay particular attention to routing security >> and >> manageability (e.g., self 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. >> >> >> 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 protocols 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: In light of the application specific routing >> requirements, the Working Group will either specify a new protocol >> and/ >> or will select an existing routing protocol (with the appropriate >> extensions in cooperation with the relevant Working Group). >> >> - Documentation of applicability statement of ROLL routing protocols. >> >> Goals and Milestones: >> >> Done Submit Routing requirements for Industrial applications to the >> IESG to be considered as an Informational RFC. >> Done Submit Routing requirements for Connected Home networks >> applications to the IESG to be considered as an Informational RFC. >> Done Submit Routing requirements for Building applications to the >> IESG to be considered as an Informational RFC. >> Done Submit Routing requirements for Urban networks applications to >> the IESG to be considered as an Informational RFC. >> July 2009 Submit Routing metrics for LLNs document to the IESG to >> be considered as a Proposed Standard. >> * Feb 2009 Submit Protocol Survey to the IESG to be considered as >> an >> Informational RFC. >> April 2009 Submit Security Framework to the IESG to be considered >> as >> an Informational RFC >> May 2009 Submit the Routing for LLNs Architecture document to the >> IESG as an Informational RFC. >> July 2009 Submit first draft of ROLL routing protocol >> specification >> as Proposed Standard. >> Nov 2009 Submit first draft of the MIB module of the ROLL routing >> protocol specification. >> Dec 2009 Submit the ROLL routing protocol specification to the >> IESG as Proposed Standard. >> Jan 2010 Submit the MIB module of the ROLL routing protocol >> specification to the IESG as Proposed Standard. >> Jan 2010 Evaluate WG progress, recharter or close. >> >> PS: I marked * the Milestones that will be "This Week" and before >> submitting to the IESG for re-chartering. >> >> >> >> Thanks. >> >> JP and David. >> _______________________________________________ >> 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 From culler@eecs.berkeley.edu Wed Feb 11 16:30:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C384728C0F9 for ; Wed, 11 Feb 2009 16:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.141 X-Spam-Level: X-Spam-Status: No, score=-5.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oJ+C4LoEEvu for ; Wed, 11 Feb 2009 16:30:25 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id DD20528C106 for ; Wed, 11 Feb 2009 16:30:24 -0800 (PST) Received: from [192.168.2.102] (64-142-4-199.dsl.static.sonic.net [64.142.4.199]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n1C0UL2w026011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Feb 2009 16:30:22 -0800 (PST) Message-ID: <49936D94.8070705@eecs.berkeley.edu> Date: Wed, 11 Feb 2009 16:30:12 -0800 From: "David E. Culler" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Mukul Goyal References: <645350922.9550021234388616247.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <645350922.9550021234388616247.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 00:30:26 -0000 I'm quite confident that working group can dig into the technical work of resolving these issues well.  It has already set a good precedent for thorough analysis as a basis for decision making.  There are numerous folks involved that have built such protocols outside the IETF, as well as folks who have built good protocols within the IETF.  Bringing the two together bodes well.  I think it is better that we move forward in that analytical manner than put stakes in the ground prematurely.


Mukul Goyal wrote: 
I am not sure if it is a good idea. I dont think you can have one protocol that works best (and even good enough) in all 4 scenarios (home, building, industrial, urban) for all applications and at all scales. Why would I use a protocol, designed for 10000 battery-powered node network, in a 100 mains-powered node network? Further, there may be multiple very different protocols that have similar performance. I dont think the recharter text should retrict the number of protocols.

Thanks
Mukul

----- Original Message -----
From: "JP Vasseur" <jvasseur@cisco.com>
To: "Mukul Goyal" <mukul@UWM.EDU>
Cc: "David E. Culler" <culler@eecs.berkeley.edu>, "ROLL WG" <roll@ietf.org>
Sent: Wednesday, February 11, 2009 3:31:09 PM GMT -06:00 US/Canada Central
Subject: Re: [Roll] ROLL re-chartering

Hi,

On Feb 11, 2009, at 10:21 PM, Mukul Goyal wrote:

  
The re-charter text gives the impression that ROLL plans to  
standardize _one_ routing protocol. Is it the intention?

    

Not yet determined. As we pointed before, the goal is always to have  
the minimum number of protocols (1 !).
If not possible, then each solution would have to be accompanied with  
an applicability statement and be
clearly justified. One solution per application (extreme case) is of  
course not acceptable. In short, our objective,
is one protocol. If not possible, which we will know during protocol  
work phase, we will decide at that point.

Thanks.

JP.

  
Thanks
Mukul Goyal

----- Original Message -----
From: "JP Vasseur" <jvasseur@cisco.com>
To: "ROLL WG" <roll@ietf.org>
Cc: "David E. Culler" <culler@eecs.berkeley.edu>
Sent: Wednesday, February 11, 2009 2:08:00 AM GMT -06:00 US/Canada  
Central
Subject: [Roll] ROLL re-chartering

Dear WG,

As indicated in a previous email, the protocol survey I-D will be send
for publication this week (after posting of the last revision
incorporating several useful comments).

As promised please find below the new proposed charter to be submitted
to the IESG for approval. In the hope of getting quickly re-chartered
thanks to let us know if you have any comment by the ned of this week.
The new charter is pretty straightforward.

Thanks to Dave Ward for his comments and guidance.

Description of Working Group:

Low power and Lossy networks (LLNs) are typically composed of many
embedded devices with limited power, memory, and processing resources
interconnected by a variety of links, such as IEEE 802.15.4,  
Bluetooth,
Low Power WiFi 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. LLNs have
specific characteristics:
-       LLNs operate with a hard, very small bound on state,
-       In most cases, LLN need to be optimized for energy saving,
-       Typical traffic patterns are not simply unicast flows,
-       In most cases, LLNs need to be effective with very small
packet sizes,
-       LLN routing protocols have to be very careful when trading off
efficiency for generality; many LLN nodes do not have resources to
waste.

These unique properties lead to unique routing requirements that may
not met by
 existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For
example path selection must be designed to take into consideration the
specific power capabilities, attributes and functional characteristics
of the links and nodes in the network.



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 home, healthcare, environmental monitoring,
urban sensor networks sensor networks, assets tracking, refrigeration.
The Working Group will only focus on routing solutions for a subset of
these. It will focus on industrial, connected home, building and urban
 sensor networks and specify the set of routing requirements for
 these scenarios.

The Working Group focuses only on IPv6 only 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 explore aspects of mobility within a single LLN
(if any) in the routing requirement creation.

The Working Group will pay particular attention to routing security  
and
manageability (e.g., self 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.


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 protocols 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: In light of the application specific routing
requirements, the Working Group will either specify a new protocol  
and/
or will select an existing routing protocol (with the appropriate
extensions in cooperation with the relevant Working Group).

- Documentation of applicability statement of ROLL routing protocols.

Goals and Milestones:

Done   Submit Routing requirements for Industrial applications to the
IESG to be considered as an Informational RFC.
Done   Submit  Routing requirements for Connected Home networks
applications to the IESG to be considered as an Informational RFC.
Done   Submit Routing requirements for Building applications to the
IESG to be considered as an Informational RFC.
Done   Submit Routing requirements for Urban networks applications to
the IESG to be considered as an Informational RFC.
July 2009    Submit Routing metrics for LLNs document to the IESG to
be considered as a Proposed Standard.
* Feb 2009   Submit Protocol Survey to the IESG to be considered as an
Informational RFC.
April 2009   Submit Security Framework to the IESG to be considered as
an Informational RFC
May 2009     Submit the Routing for LLNs Architecture document to the
IESG as an Informational RFC.
July 2009    Submit first draft of ROLL routing protocol specification
as Proposed Standard.
Nov 2009     Submit first draft of the MIB module of the ROLL routing
protocol specification.
Dec 2009     Submit the ROLL routing protocol specification to the
IESG as Proposed Standard.
Jan 2010     Submit the MIB module of the ROLL routing protocol
specification to the IESG as Proposed Standard.
Jan 2010     Evaluate WG progress, recharter or close.

PS: I marked * the Milestones that will be "This Week" and before
submitting to the IESG for re-chartering.



Thanks.

JP and David.
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
From eunah.ietf@gmail.com Wed Feb 11 18:38:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 092483A6916; Wed, 11 Feb 2009 18:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvxSkYSzGn9y; Wed, 11 Feb 2009 18:38:01 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.155]) by core3.amsl.com (Postfix) with ESMTP id 87E713A67CF; Wed, 11 Feb 2009 18:38:01 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so1258766poe.4 for ; Wed, 11 Feb 2009 18:38:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uDuLq+0WTjvrGlpefjSKUuMVAb6+WpVPI6Mr6jiUafc=; b=s12LUKiXk5KWSQ8obCldImSNZRiwRHK4b9DOqWFHZL1Y+V65DxJ/LWq5SWa8LoAdSY p1GxuS1AlSZerduqWxFl9l2jRAcwMvCSbpltpvDHRPJ+on+GkF06cPWLO64adO4/TbZU 4ZlpXoGHZpR/pOqLEgU36FyqtgeDNJiPsgmWM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Zup8YJuJSbIq+rvSUJGiVcji8tC7WmKRwZtDjL7VahTqQUQPw4kVoVR+V7CCiHoj+Y HrCe5tKjPPkcjf975+FdxSikJXCwZ9wavZZeMkKP35zeCeY9miczJD1y5KVa+/8GkFhF d5fjniDGUUWnzvR6fnVvg1g2D+qvAmVqdhGQI= MIME-Version: 1.0 Received: by 10.141.209.6 with SMTP id l6mr208041rvq.192.1234406285844; Wed, 11 Feb 2009 18:38:05 -0800 (PST) In-Reply-To: <4992FD7F.8070408@gmail.com> References: <4992FD7F.8070408@gmail.com> Date: Thu, 12 Feb 2009 11:38:05 +0900 Message-ID: <77f1dba80902111838g44541a6ubc347b0ce03abfa0@mail.gmail.com> From: "Eunsook \"Eunah\" Kim" To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ROLL WG , 6lowpan@ietf.org Subject: Re: [Roll] Comments on draft-ietf-6lowpan-routing-requirements-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 02:38:03 -0000 Dear Alex, Thank you very much for your detail comments. I think your comments help us clarify many points on the draft. I'm just about to leave to other town for a domestic biz trip. I will get back to you asap. Thanks, -eunah On Thu, Feb 12, 2009 at 1:31 AM, Alexandru Petrescu wrote: > [Where should I post this message, to 6LoWPAN or to ROLL list? Both?] > > Dear WG members, > > draft-ietf-6lowpan-routing-requirements-00 lists a Problem Statement, > some Scenarios and a set of Routing Requirements. Generally I find it a > well written document, with many meaningful details. > > There are very many parts of this document to which I silently agree, > even some parts I wholehartedly agree. I like the distinction > route-above mesh-under, and many other parts too. > > Some high-level questions: > -is there a requirement to connect a 6LoWPAN network to the Internet? > -is the 6LoWPAN using addressing architecture and longest-prefix match > based routing as in the Internet? > -how many interfaces will a 15.4 device have potentially? > > Following are detail questions and comments. I believe they're not as > important as the items mentioned above. > >> 1. Problem Statement > > Is this _the_ problem statement or should I better go read > draft-ietf-6lowpan-problem-08? They differ largely... > >> The 6LoWPAN problem statement document ("6LoWPAN Problems and Goals" [3]) >> briefly mentions four requirements on routing protocols; >> >> (a) low overhead on data packets >> >> (b) low routing overhead > > > What is routing more generally? Is it the act a router performs when > presenting with a packet, searching in a routing table, maybe exploring > its ND structures, maybe sending ND messages and then emitting the packet? > > Or is it exchanging IP datagrams containing prefixes and metrics and > reachability information, such that nodes have a common view of the > network paths? > > I think this is worth discussing, in order to better target what the > work should follow this problem statement and reqs. > > Are the low overhead requirements put on the database construction > messages? Or on the individual act of forwarding a packet? > >> On the other hand, the route-over approach relies on IP routing and >> therefore supports routing over possibly various types of interconnected >> links (see also Figure 1). > > At several places in the draft, when link 'types', device 'types' are > mentioned, I'm tempted to believe 6LoWPAN considers links other than > 802.15.4 links? Is it so? Should 6LoWPAN routing protocol work also > with aseptic point-to-point links? > > Or are the 'types' limited within the relatively large scope of 802.3 > compatible MACs (I believe 802.15.4 and 802.16 to fit within). > > This is of paramount importance in setting the scope. > >> The most significant consequence of mesh-under routing is that routing >> would be directly based on the IEEE 802.15.4 standard, > > Which 'routing' is directly based on 802.15.4 standard? The 'IP > routing' is based on that standard? This brings back to defining what > routing is. > > Maybe better call 'mesh-under routing' 'mesh-under switching'. > > IP routing and addressing may be fundamentally different than mesh-under > addressing and switching - in the way hosts get and maintain their > addresses and in the way routers/switches search their databases (exact > match vs longest-prefix). > >> When a route-over protocol is built in the IPv6 layer, the Dispatch value >> can be chosen as one of the Dispatch patterns for 6LoWPAN, compressed or >> uncompressed IPv6, followed by the IPv6 header. > > > Sorry, I can't parse this. > > A route-over protocol would act both at IP layer and > application/transport layers. Depends what a routing protocol is. For > example ICMP Redirect, or NEMOv6 or ND act at IP layer, whereas RIPng is > over UDP. > > 'followed by'... when reading left to right or reverse? > >> For route-over, a default route to the ER could be inserted into the >> routing system. > > In the routing system of the 6LoWPAN network? Or in the routing system > of the fixed Internet network? > >> IP-based low-power WPAN technology is still in its early stage of > > 'WPAN'? > >> a. Network Properties: >> >> * Number of Devices, Density and Network Diameter: These parameters >> usually affect the routing state directly (e.g. the number of >> entries in a routing table or neighbor list). Especially in large >> and dense networks, policies must > > What is 'large' and 'dense'? Is it about physical dimensions? Or IP > dimensions? > > Density sounds as a physical characteristic (many devices in a small > area) whereas Diameter sounds as a pure IP term (max number of IP hops). > > The number of entries in the routing table mostly depends on the planned > addressing architecture. One can have a very high-diameter network with > a very hierarchical addressing structures, many default routes, and very > few entries in the routing tables (maybe only 1 per hop). > > Is the addressing architecture for 6LoWPAN networks planned? > > Is the addressing architecture following the Internet model? > >> b. Node Parameters: > > How many interfaces does a 6LoWPAN node typically have? This is of > paramount importance deciding whether any type of repeating/bridging > needs to happen. > >> * Throughput: The maximum user data throughput of a bulk data >> transmission between a single sender and a single receiver through an >> unslotted IEEE 802.15.4 2.4 GHz channel in ideal conditions is as follows >> [19]: [...] >> >> In the case of 915 MHz band: > > Sorry, for my clarification: is 915MHz the width of band centered on > the 2.4GHz mentioned above? Or is it the central frequency (thus > replacing the "2.4GHz" mentioned above)? > >> [R02] 6LoWPAN routing protocols SHOULD cause minimal power consumption by >> the efficient use of control packets (e.g., minimize expensive multicast >> which cause broadcast to the entire LoWPAN) and by the efficient routing of >> data packets. > > YEs, but multicast may be more efficient than broadcast - is it > sufficient? I think it is sufficient to rely on multicast and avoid > unnecessary duplication such as in broadcast. > > 'Efficient routing of data packets' - is it also efficient search in the > routing table? That may be part of 'routing' too. > >> possibliy > > Nit: iy > >> [R03] 6LoWPAN routing protocol control messages SHOULD not create >> fragmentation of physical layer (PHY) frames. > > Err... I think PHY frames aren't fragmented... not sure I understand > this requirement? > > Sounds as if one wants an UDP control packets to not be sent in several > pieces, because of overhead involved fragmenting/reassembling. > > Then make sure first IP doesn't fragment. > >> Therefore, 6LoWPAN routing should not cause packets to exceed the IEEE >> 802.15.4 frame size [81bytes]. > > Is this a requirement on the mesh-under link-layer switching protocol? > Or on the 'route-above' protocol? If the latter - I think this > requirement is a violation of layer independence :-) > > It sounds very special to me to limit the size of the messages of an IP > routing protocol. > > Knowing that IP can fragment too. > >> [R05] The design of routing protocols for 6LoWPANs must consider the >> end-to-end latency requirements of applications and IEEE 802.15.4 link >> latency characteristics. > > 'Routing'? Or 'Transport'? end-to-end is what Transport typically > takes care of, not routing. > > If Routing: which routing? The forwarding ahppening at a node? Or the > convergence time? The exchange of routing messages? > >> Some routing protocols are aware of the hop count of a path. > > I think all of them are, no? > >> In homes, buildings, or infrastructure, some nodes will be installed >> with mains power. Such power-installed nodes MUST be > > If they have mains power - will they use Power-Line Communications? > >> Building monitoring applications, for instance, require that the mobile >> devices SHOULD be capable of leaving (handing-off) from an old >> network joining onto a new network within 15 seconds [17]. > > Should such a mobile device change its IP address or is it free to > change it? > >> [R13] 6LoWPAN routing protocol SHOULD support various traffic patterns; >> point-to-point, point-to-multipoint, and multipoint-to- point, while avoid >> excessive multicast traffic (broadcast in link layer) in 6LoWPAN. > > It's called multicast at link-layer too (802.3); thus it avoids > unnecessary packet duplication, thus it avoids duplication of > broadcasted packets and thus avoids excessive traffic. > > If we talk IPv6 and recent link layers then I mostly forget the term > 'broadcast' and use multicast instead. > >> 6LoWPAN routing protocols should be designed with the consideration of >> forwarding packets from/to multiple sources/destinations. > > Sorry, what do you mean? An IP packet with multiple src fields? > >> Current WG drafts in the ROLL working group explain that the workload >> or traffic pattern of use cases for 6LoWPANs tend to be highly >> structured, unlike the any- to-any data transfers that dominate typical >> client and server workloads. > > Sorry, what do you mean by 'any-to-any' data transfers? Any > relationship to 'IP anycast'? > >> [R14] 6LoWPAN protocols SHOULD support secure delivery of control >> messages. A minimal security level can be achieved by utilizing AES- >> based mechanism provided by IEEE 802.15.4. > > Isn't AES superstrong and thus computation intensive and thus > energy intensive? > > Intuitively speaking, maybe SHA-1 is sufficient for reduced needs in > constrained environments. > >> [R16] For neighbor discovery, 6LoWPAN devices SHOULD avoid sending "Hello" >> messages. > > ND doesn't send Hello messages, but NS, NA, RS and RA. > >> [R18] If the routing protocol functionality includes enabling IP >> multicast, then it may want to employ coordinator roles, if any, as relay >> points of group-targeting messages instead of using link-layer >> multicast (broadcast). > > link-layer multicast no broadcast. > > Nit: 'MAC sub-layer' appears only once and in the figure they're > all 'layers'. > > Alex > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From zach@sensinode.com Thu Feb 12 00:40:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B4103A6930 for ; Thu, 12 Feb 2009 00:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwCIOaiYvTNe for ; Thu, 12 Feb 2009 00:40:25 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id F0E063A680A for ; Thu, 12 Feb 2009 00:40:23 -0800 (PST) Received: from snl-zach.local (addr-213-139-165-97.dnanetti.suomi.net [213.139.165.97]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n1C8dxJI005357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2009 10:39:59 +0200 Message-ID: <4993D255.5080703@sensinode.com> Date: Thu, 12 Feb 2009 09:40:05 +0200 From: Zach Shelby User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: JP Vasseur References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> In-Reply-To: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 08:40:26 -0000 Hi, I support this charter. Although the time-line looks tight, this WG is motivated, and the industry demand for a solution high - so still reasonable. - Zach JP Vasseur wrote: > Dear WG, > > As indicated in a previous email, the protocol survey I-D will be send > for publication this week (after posting of the last revision > incorporating several useful comments). > > As promised please find below the new proposed charter to be submitted > to the IESG for approval. In the hope of getting quickly re-chartered > thanks to let us know if you have any comment by the ned of this week. > The new charter is pretty straightforward. > > Thanks to Dave Ward for his comments and guidance. > > Description of Working Group: > > Low power and Lossy networks (LLNs) are typically composed of many > embedded devices with limited power, memory, and processing resources > interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, > Low Power WiFi 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. LLNs have > specific characteristics: > - LLNs operate with a hard, very small bound on state, > - In most cases, LLN need to be optimized for energy saving, > - Typical traffic patterns are not simply unicast flows, > - In most cases, LLNs need to be effective with very small packet > sizes, > - LLN routing protocols have to be very careful when trading off > efficiency for generality; many LLN nodes do not have resources to waste. > > These unique properties lead to unique routing requirements that may not > met by > existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For > example path selection must be designed to take into consideration the > specific power capabilities, attributes and functional characteristics > of the links and nodes in the network. > > > > 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 home, healthcare, environmental monitoring, > urban sensor networks sensor networks, assets tracking, refrigeration. > The Working Group will only focus on routing solutions for a subset of > these. It will focus on industrial, connected home, building and urban > sensor networks and specify the set of routing requirements for > these scenarios. > > The Working Group focuses only on IPv6 only 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 explore aspects of mobility within a single LLN > (if any) in the routing requirement creation. > > The Working Group will pay particular attention to routing security and > manageability (e.g., self 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. > > > 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 protocols 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: In light of the application specific routing > requirements, the Working Group will either specify a new protocol > and/or will select an existing routing protocol (with the appropriate > extensions in cooperation with the relevant Working Group). > > - Documentation of applicability statement of ROLL routing protocols. > > Goals and Milestones: > > Done Submit Routing requirements for Industrial applications to the > IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Connected Home networks > applications to the IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Building applications to the IESG > to be considered as an Informational RFC. > Done Submit Routing requirements for Urban networks applications to > the IESG to be considered as an Informational RFC. > July 2009 Submit Routing metrics for LLNs document to the IESG to be > considered as a Proposed Standard. > * Feb 2009 Submit Protocol Survey to the IESG to be considered as an > Informational RFC. > April 2009 Submit Security Framework to the IESG to be considered as > an Informational RFC > May 2009 Submit the Routing for LLNs Architecture document to the > IESG as an Informational RFC. > July 2009 Submit first draft of ROLL routing protocol specification > as Proposed Standard. > Nov 2009 Submit first draft of the MIB module of the ROLL routing > protocol specification. > Dec 2009 Submit the ROLL routing protocol specification to the IESG > as Proposed Standard. > Jan 2010 Submit the MIB module of the ROLL routing protocol > specification to the IESG as Proposed Standard. > Jan 2010 Evaluate WG progress, recharter or close. > > PS: I marked * the Milestones that will be "This Week" and before > submitting to the IESG for re-chartering. > > > > Thanks. > > JP and David. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti FINLAND mobile: +358 40 7796297 This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. From alexandru.petrescu@gmail.com Fri Feb 13 05:07:29 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6BBE3A6CE7 for ; Fri, 13 Feb 2009 05:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.725 X-Spam-Level: X-Spam-Status: No, score=-1.725 tagged_above=-999 required=5 tests=[AWL=0.524, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQorlaQgbMWq for ; Fri, 13 Feb 2009 05:07:28 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 76B5C3A67F7 for ; Fri, 13 Feb 2009 05:07:28 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1DD5neK009946; Fri, 13 Feb 2009 14:05:49 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1DD7TVv009358; Fri, 13 Feb 2009 14:07:30 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n1DD7TPK021680; Fri, 13 Feb 2009 14:07:29 +0100 Message-ID: <49957091.5090101@gmail.com> Date: Fri, 13 Feb 2009 14:07:29 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: JP Vasseur References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> In-Reply-To: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 13:07:30 -0000 JP Vasseur a écrit : > Dear WG, > > As indicated in a previous email, the protocol survey I-D will be send > for publication this week (after posting of the last revision > incorporating several useful comments). > > As promised please find below the new proposed charter to be submitted > to the IESG for approval. In the hope of getting quickly re-chartered > thanks to let us know if you have any comment by the ned of this week. > The new charter is pretty straightforward. > > Thanks to Dave Ward for his comments and guidance. > > Description of Working Group: > > Low power and Lossy networks (LLNs) are typically composed of many > embedded devices with limited power, memory, and processing resources > interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, > Low Power WiFi or other low power PLC (Powerline Communication) links. Sorry, low power PLC sounds contradictory to me... low power and powerline... I think the PLC devices are powered by the line itself. Where does the low-power characteristic come from? Or is that low-power radio? (short range, small dBm). Alex > 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. LLNs have > specific characteristics: > - LLNs operate with a hard, very small bound on state, > - In most cases, LLN need to be optimized for energy saving, > - Typical traffic patterns are not simply unicast flows, > - In most cases, LLNs need to be effective with very small packet > sizes, > - LLN routing protocols have to be very careful when trading off > efficiency for generality; many LLN nodes do not have resources to waste. > > These unique properties lead to unique routing requirements that may not > met by > existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For > example path selection must be designed to take into consideration the > specific power capabilities, attributes and functional characteristics > of the links and nodes in the network. > > > > 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 home, healthcare, environmental monitoring, > urban sensor networks sensor networks, assets tracking, refrigeration. > The Working Group will only focus on routing solutions for a subset of > these. It will focus on industrial, connected home, building and urban > sensor networks and specify the set of routing requirements for > these scenarios. > > The Working Group focuses only on IPv6 only 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 explore aspects of mobility within a single LLN > (if any) in the routing requirement creation. > > The Working Group will pay particular attention to routing security and > manageability (e.g., self 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. > > > 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 protocols 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: In light of the application specific routing > requirements, the Working Group will either specify a new protocol > and/or will select an existing routing protocol (with the appropriate > extensions in cooperation with the relevant Working Group). > > - Documentation of applicability statement of ROLL routing protocols. > > Goals and Milestones: > > Done Submit Routing requirements for Industrial applications to the > IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Connected Home networks > applications to the IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Building applications to the IESG > to be considered as an Informational RFC. > Done Submit Routing requirements for Urban networks applications to > the IESG to be considered as an Informational RFC. > July 2009 Submit Routing metrics for LLNs document to the IESG to be > considered as a Proposed Standard. > * Feb 2009 Submit Protocol Survey to the IESG to be considered as an > Informational RFC. > April 2009 Submit Security Framework to the IESG to be considered as > an Informational RFC > May 2009 Submit the Routing for LLNs Architecture document to the > IESG as an Informational RFC. > July 2009 Submit first draft of ROLL routing protocol specification > as Proposed Standard. > Nov 2009 Submit first draft of the MIB module of the ROLL routing > protocol specification. > Dec 2009 Submit the ROLL routing protocol specification to the IESG > as Proposed Standard. > Jan 2010 Submit the MIB module of the ROLL routing protocol > specification to the IESG as Proposed Standard. > Jan 2010 Evaluate WG progress, recharter or close. > > PS: I marked * the Milestones that will be "This Week" and before > submitting to the IESG for re-chartering. > > > > Thanks. > > JP and David. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From jvasseur@cisco.com Fri Feb 13 05:16:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B51B28C1F0 for ; Fri, 13 Feb 2009 05:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7Ojq-cTrClM for ; Fri, 13 Feb 2009 05:16:17 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id BAF473A69BB for ; Fri, 13 Feb 2009 05:16:16 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,202,1233532800"; d="scan'208";a="33722858" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 13 Feb 2009 13:16:08 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1DDG8OI013284; Fri, 13 Feb 2009 14:16:08 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1DDG824014515; Fri, 13 Feb 2009 13:16:08 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Feb 2009 14:16:08 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Feb 2009 14:16:07 +0100 Message-Id: <985801EB-0080-47C7-BAC0-B23FB6BCB403@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <49957091.5090101@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 13 Feb 2009 14:16:06 +0100 References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> <49957091.5090101@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 13 Feb 2009 13:16:07.0794 (UTC) FILETIME=[3B3D6D20:01C98DDD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7470; t=1234530968; x=1235394968; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20re-chartering |Sender:=20; bh=Hv46datfE25artYf9T8LziR2AUzwqbqFP4VWQp4/8kU=; b=iMIopjjfa8zCIMuRDcuzHsqiFZQ8ImzRWdbvL4q5HksbvoDM9+lL9dhRri vZDO9jmGcL+z0E/51MqeTb9FtKgVduG5daAlt22C2sCJ3oztKqbvJmA/AF9q 02oYG/TtJJ; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 13:16:18 -0000 Hi Alex, On Feb 13, 2009, at 2:07 PM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> Dear WG, >> As indicated in a previous email, the protocol survey I-D will be =20 >> send for publication this week (after posting of the last revision =20= >> incorporating several useful comments). >> As promised please find below the new proposed charter to be =20 >> submitted to the IESG for approval. In the hope of getting quickly =20= >> re-chartered thanks to let us know if you have any comment by the =20 >> ned of this week. The new charter is pretty straightforward. >> Thanks to Dave Ward for his comments and guidance. >> Description of Working Group: >> Low power and Lossy networks (LLNs) are typically composed of many >> embedded devices with limited power, memory, and processing resources >> interconnected by a variety of links, such as IEEE 802.15.4, =20 >> Bluetooth, >> Low Power WiFi or other low power PLC (Powerline Communication) =20 >> links. > > Sorry, low power PLC sounds contradictory to me... low power and =20 > powerline... > > I think the PLC devices are powered by the line itself. Where does =20= > the low-power characteristic come from? > Although they are main powered they can consume more of less power =20 (thus the term low power). You can find PLC chipset that consumes a few dozen of Mw. In our =20 context we are referring to these PLC type technologies that opposed to other PLC technologies =20 that are in the Watt range. Thanks. JP. > Or is that low-power radio? (short range, small dBm). > > Alex > >> 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. LLNs =20 >> have specific characteristics: >> - LLNs operate with a hard, very small bound on state, >> - In most cases, LLN need to be optimized for energy saving, >> - Typical traffic patterns are not simply unicast flows, >> - In most cases, LLNs need to be effective with very small =20 >> packet sizes, >> - LLN routing protocols have to be very careful when trading =20= >> off efficiency for generality; many LLN nodes do not have resources =20= >> to waste. >> These unique properties lead to unique routing requirements that =20 >> may not met by >> existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For >> example path selection must be designed to take into consideration =20= >> the >> specific power capabilities, attributes and functional =20 >> characteristics >> of the links and nodes in the network. >> 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 home, healthcare, environmental monitoring, >> urban sensor networks sensor networks, assets tracking, =20 >> refrigeration. >> The Working Group will only focus on routing solutions for a subset =20= >> of >> these. It will focus on industrial, connected home, building and =20 >> urban >> sensor networks and specify the set of routing requirements for >> these scenarios. >> The Working Group focuses only on IPv6 only routing architectural >> framework for these application scenarios. The Framework will take =20= >> into consideration various >> aspects including high reliability in the presence of time varying =20= >> 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 explore aspects of mobility within a single =20= >> LLN >> (if any) in the routing requirement creation. >> The Working Group will pay particular attention to routing security =20= >> and >> manageability (e.g., self configuration) issues. It will also need to >> consider the transport characteristic the routing protocol messages =20= >> will >> experience. Mechanisms that protect an LLN from congestion collapse =20= >> or >> that establish some degree of fairness between concurrent =20 >> communication >> sessions are out of scope of the Working Group. It is expected that >> upper-layer applications utilizing LLNs define appropriate =20 >> mechanisms. >> Work Items: >> - Specification of routing metrics used in path calculation. This >> includes static and dynamic link/node attributes required for =20 >> routing in >> LLNs. >> - Provide an architectural framework for routing and path selection =20= >> at >> Layer 3 (Routing for LLN Architecture) that addresses such issues as >> whether LLN routing protocols require a distributed and/or =20 >> centralized >> path computation models, whether additional hierarchy is necessary =20= >> and >> how it is applied. Manageability will be considered with each =20 >> 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: In light of the application specific routing =20 >> requirements, the Working Group will either specify a new protocol =20= >> and/or will select an existing routing protocol (with the =20 >> appropriate extensions in cooperation with the relevant Working =20 >> Group). >> - Documentation of applicability statement of ROLL routing protocols. >> Goals and Milestones: >> Done Submit Routing requirements for Industrial applications to =20 >> the IESG to be considered as an Informational RFC. >> Done Submit Routing requirements for Connected Home networks =20 >> applications to the IESG to be considered as an Informational RFC. >> Done Submit Routing requirements for Building applications to the =20= >> IESG to be considered as an Informational RFC. >> Done Submit Routing requirements for Urban networks applications =20= >> to the IESG to be considered as an Informational RFC. >> July 2009 Submit Routing metrics for LLNs document to the IESG =20 >> to be considered as a Proposed Standard. >> * Feb 2009 Submit Protocol Survey to the IESG to be considered as =20= >> an Informational RFC. >> April 2009 Submit Security Framework to the IESG to be considered =20= >> as an Informational RFC >> May 2009 Submit the Routing for LLNs Architecture document to =20 >> the IESG as an Informational RFC. >> July 2009 Submit first draft of ROLL routing protocol =20 >> specification as Proposed Standard. >> Nov 2009 Submit first draft of the MIB module of the ROLL =20 >> routing protocol specification. >> Dec 2009 Submit the ROLL routing protocol specification to the =20= >> IESG as Proposed Standard. >> Jan 2010 Submit the MIB module of the ROLL routing protocol =20 >> specification to the IESG as Proposed Standard. >> Jan 2010 Evaluate WG progress, recharter or close. >> PS: I marked * the Milestones that will be "This Week" and before =20 >> submitting to the IESG for re-chartering. >> Thanks. >> JP and David. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > From mischa.dohler@cttc.es Fri Feb 13 05:47:32 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BF4D3A6B3A for ; Fri, 13 Feb 2009 05:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tXoG2eJ+k31 for ; Fri, 13 Feb 2009 05:47:31 -0800 (PST) Received: from scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by core3.amsl.com (Postfix) with ESMTP id BC7233A6B01 for ; Fri, 13 Feb 2009 05:47:30 -0800 (PST) Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by scorpius.cttc.es (8.13.8/8.13.5) with ESMTP id n1DDjE3U018127; Fri, 13 Feb 2009 14:45:14 +0100 Received: from [84.88.61.89] (pcmdohler.cttc.es [84.88.61.89]) by castor (Postfix) with ESMTP id 322582FC25C; Fri, 13 Feb 2009 14:45:14 +0100 (CET) Message-ID: <49957837.1000608@cttc.es> Date: Fri, 13 Feb 2009 14:40:07 +0100 From: Mischa Dohler User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: JP Vasseur References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> <49957091.5090101@gmail.com> <985801EB-0080-47C7-BAC0-B23FB6BCB403@cisco.com> In-Reply-To: <985801EB-0080-47C7-BAC0-B23FB6BCB403@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Fri, 13 Feb 2009 14:45:14 +0100 (CET) X-Scanned-By: MIMEDefang 2.57 on 84.88.62.197 Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 13:47:32 -0000 I am not sure why PLC has popped up again? Whilst they are and certainly will be part of the embedded system's landscape, I remember that we decided to exclude it for a set of reasons: 1) Where is the real routing challenge if you can only route 'along' the power line? I guess there are small items to be solved but I don't see yet *the* grand challenge. 2) A company trying to use PLC told us that they could not get a reasonable signal beyond the meter, ie if you have sensors reporting in several flats, there is no way you can aggregate this data in a single node placed in the building and possibly acting as a gateway to other nets. I have had a look at the circuits diagram of typical meters and have not yet fully got around why the signal gets so heavily attenuated but this is what it does (at the moment). Anybody on this list with other practical experiences with PLC? Cheers, Mischa. JP Vasseur wrote: > Hi Alex, > > On Feb 13, 2009, at 2:07 PM, Alexandru Petrescu wrote: > >> JP Vasseur a écrit : >>> Dear WG, >>> As indicated in a previous email, the protocol survey I-D will be >>> send for publication this week (after posting of the last revision >>> incorporating several useful comments). >>> As promised please find below the new proposed charter to be >>> submitted to the IESG for approval. In the hope of getting quickly >>> re-chartered thanks to let us know if you have any comment by the ned >>> of this week. The new charter is pretty straightforward. >>> Thanks to Dave Ward for his comments and guidance. >>> Description of Working Group: >>> Low power and Lossy networks (LLNs) are typically composed of many >>> embedded devices with limited power, memory, and processing resources >>> interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, >>> Low Power WiFi or other low power PLC (Powerline Communication) links. >> >> Sorry, low power PLC sounds contradictory to me... low power and >> powerline... >> >> I think the PLC devices are powered by the line itself. Where does >> the low-power characteristic come from? >> > > Although they are main powered they can consume more of less power (thus > the term low power). > You can find PLC chipset that consumes a few dozen of Mw. In our context > we are referring to > these PLC type technologies that opposed to other PLC technologies that > are in the Watt range. > > Thanks. > > JP. > >> Or is that low-power radio? (short range, small dBm). >> >> Alex >> >>> 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. LLNs >>> have specific characteristics: >>> - LLNs operate with a hard, very small bound on state, >>> - In most cases, LLN need to be optimized for energy saving, >>> - Typical traffic patterns are not simply unicast flows, >>> - In most cases, LLNs need to be effective with very small >>> packet sizes, >>> - LLN routing protocols have to be very careful when trading >>> off efficiency for generality; many LLN nodes do not have resources >>> to waste. >>> These unique properties lead to unique routing requirements that may >>> not met by >>> existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For >>> example path selection must be designed to take into consideration the >>> specific power capabilities, attributes and functional characteristics >>> of the links and nodes in the network. >>> 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 home, healthcare, environmental monitoring, >>> urban sensor networks sensor networks, assets tracking, refrigeration. >>> The Working Group will only focus on routing solutions for a subset of >>> these. It will focus on industrial, connected home, building and urban >>> sensor networks and specify the set of routing requirements for >>> these scenarios. >>> The Working Group focuses only on IPv6 only 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 explore aspects of mobility within a single LLN >>> (if any) in the routing requirement creation. >>> The Working Group will pay particular attention to routing security and >>> manageability (e.g., self 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. >>> 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 protocols 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: In light of the application specific routing >>> requirements, the Working Group will either specify a new protocol >>> and/or will select an existing routing protocol (with the appropriate >>> extensions in cooperation with the relevant Working Group). >>> - Documentation of applicability statement of ROLL routing protocols. >>> Goals and Milestones: >>> Done Submit Routing requirements for Industrial applications to the >>> IESG to be considered as an Informational RFC. >>> Done Submit Routing requirements for Connected Home networks >>> applications to the IESG to be considered as an Informational RFC. >>> Done Submit Routing requirements for Building applications to the >>> IESG to be considered as an Informational RFC. >>> Done Submit Routing requirements for Urban networks applications to >>> the IESG to be considered as an Informational RFC. >>> July 2009 Submit Routing metrics for LLNs document to the IESG to >>> be considered as a Proposed Standard. >>> * Feb 2009 Submit Protocol Survey to the IESG to be considered as >>> an Informational RFC. >>> April 2009 Submit Security Framework to the IESG to be considered >>> as an Informational RFC >>> May 2009 Submit the Routing for LLNs Architecture document to the >>> IESG as an Informational RFC. >>> July 2009 Submit first draft of ROLL routing protocol >>> specification as Proposed Standard. >>> Nov 2009 Submit first draft of the MIB module of the ROLL routing >>> protocol specification. >>> Dec 2009 Submit the ROLL routing protocol specification to the >>> IESG as Proposed Standard. >>> Jan 2010 Submit the MIB module of the ROLL routing protocol >>> specification to the IESG as Proposed Standard. >>> Jan 2010 Evaluate WG progress, recharter or close. >>> PS: I marked * the Milestones that will be "This Week" and before >>> submitting to the IESG for re-chartering. >>> Thanks. >>> JP and David. >>> _______________________________________________ >>> 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 From jvasseur@cisco.com Fri Feb 13 05:54:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 358983A6B01 for ; Fri, 13 Feb 2009 05:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nS5Xb4c1yiCd for ; Fri, 13 Feb 2009 05:54:51 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 302AC3A68DA for ; Fri, 13 Feb 2009 05:54:51 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,202,1233532800"; d="scan'208";a="33728867" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 13 Feb 2009 13:54:56 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1DDsuuM027751; Fri, 13 Feb 2009 14:54:56 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1DDsu0h000338; Fri, 13 Feb 2009 13:54:56 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Feb 2009 14:54:56 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Feb 2009 14:54:55 +0100 Message-Id: <8FA49B57-4046-461A-A0E7-D4DF21074099@cisco.com> From: JP Vasseur To: Mischa Dohler In-Reply-To: <49957837.1000608@cttc.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 13 Feb 2009 14:54:55 +0100 References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> <49957091.5090101@gmail.com> <985801EB-0080-47C7-BAC0-B23FB6BCB403@cisco.com> <49957837.1000608@cttc.es> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 13 Feb 2009 13:54:55.0820 (UTC) FILETIME=[A6DA00C0:01C98DE2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9472; t=1234533296; x=1235397296; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20re-chartering |Sender:=20; bh=eLpL33BwTgB2+GEI9Gb/qyGerFFkkyEyi91D9QEMM/w=; b=OQu1jr0DblGMoSBjnaNiSt1vLsWBT6CrU/B+VhKGYylsy2NH0xBi2+Qujn UrX3chV9VaLOVfCIXXmS3h1Xs/xtwsUHi0jTgoMrxO/N6gVY6Ll781c9ddqC HOhPq6Qbp1; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 13:54:53 -0000 Hi Mischa, On Feb 13, 2009, at 2:40 PM, Mischa Dohler wrote: > I am not sure why PLC has popped up again? Whilst they are and =20 > certainly will be part of the embedded system's landscape, I =20 > remember that we decided to exclude it for a set of reasons: > > 1) Where is the real routing challenge if you can only route 'along' =20= > the power line? I guess there are small items to be solved but I =20 > don't see yet *the* grand challenge. > it is just that LLNs can be made of both wireless and wired devices =20 (PLC and serial as pointed out by Jerry). Still constrained devices =20 thus they are part of ROLL's scope. This is very much true in Smart =20 Grid automation. > 2) A company trying to use PLC told us that they could not get a =20 > reasonable signal beyond the meter, ie if you have sensors reporting =20= > in several flats, there is no way you can aggregate this data in a =20 > single node placed in the building and possibly acting as a gateway =20= > to other nets. I have had a look at the circuits diagram of typical =20= > meters and have not yet fully got around why the signal gets so =20 > heavily attenuated but this is what it does (at the moment). Anybody =20= > on this list with other practical experiences with PLC? There is plenty of excellent PLC technos. I'll send you pointers, just =20= trying to focus on the charter in this thread ;-) Thanks. JP. > > > Cheers, > Mischa. > > > > > JP Vasseur wrote: >> Hi Alex, >> On Feb 13, 2009, at 2:07 PM, Alexandru Petrescu wrote: >>> JP Vasseur a =E9crit : >>>> Dear WG, >>>> As indicated in a previous email, the protocol survey I-D will be =20= >>>> send for publication this week (after posting of the last =20 >>>> revision incorporating several useful comments). >>>> As promised please find below the new proposed charter to be =20 >>>> submitted to the IESG for approval. In the hope of getting =20 >>>> quickly re-chartered thanks to let us know if you have any =20 >>>> comment by the ned of this week. The new charter is pretty =20 >>>> straightforward. >>>> Thanks to Dave Ward for his comments and guidance. >>>> Description of Working Group: >>>> Low power and Lossy networks (LLNs) are typically composed of many >>>> embedded devices with limited power, memory, and processing =20 >>>> resources >>>> interconnected by a variety of links, such as IEEE 802.15.4, =20 >>>> Bluetooth, >>>> Low Power WiFi or other low power PLC (Powerline Communication) =20 >>>> links. >>> >>> Sorry, low power PLC sounds contradictory to me... low power and =20 >>> powerline... >>> >>> I think the PLC devices are powered by the line itself. Where =20 >>> does the low-power characteristic come from? >>> >> Although they are main powered they can consume more of less power =20= >> (thus the term low power). >> You can find PLC chipset that consumes a few dozen of Mw. In our =20 >> context we are referring to >> these PLC type technologies that opposed to other PLC technologies =20= >> that are in the Watt range. >> Thanks. >> JP. >>> Or is that low-power radio? (short range, small dBm). >>> >>> Alex >>> >>>> 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. LLNs =20= >>>> have specific characteristics: >>>> - LLNs operate with a hard, very small bound on state, >>>> - In most cases, LLN need to be optimized for energy saving, >>>> - Typical traffic patterns are not simply unicast flows, >>>> - In most cases, LLNs need to be effective with very small =20= >>>> packet sizes, >>>> - LLN routing protocols have to be very careful when =20 >>>> trading off efficiency for generality; many LLN nodes do not have =20= >>>> resources to waste. >>>> These unique properties lead to unique routing requirements that =20= >>>> may not met by >>>> existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For >>>> example path selection must be designed to take into =20 >>>> consideration the >>>> specific power capabilities, attributes and functional =20 >>>> characteristics >>>> of the links and nodes in the network. >>>> 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 home, healthcare, environmental =20 >>>> monitoring, >>>> urban sensor networks sensor networks, assets tracking, =20 >>>> refrigeration. >>>> The Working Group will only focus on routing solutions for a =20 >>>> subset of >>>> these. It will focus on industrial, connected home, building and =20= >>>> urban >>>> sensor networks and specify the set of routing requirements for >>>> these scenarios. >>>> The Working Group focuses only on IPv6 only routing architectural >>>> framework for these application scenarios. The Framework will =20 >>>> take into consideration various >>>> aspects including high reliability in the presence of time =20 >>>> varying loss >>>> characteristics and connectivity while permitting low-power =20 >>>> operation >>>> with very modest memory and CPU pressure in networks potentially >>>> comprising a very large number (several thousands) of nodes. >>>> The Working Group will explore aspects of mobility within a =20 >>>> single LLN >>>> (if any) in the routing requirement creation. >>>> The Working Group will pay particular attention to routing =20 >>>> security and >>>> manageability (e.g., self configuration) issues. It will also =20 >>>> need to >>>> consider the transport characteristic the routing protocol =20 >>>> messages will >>>> experience. Mechanisms that protect an LLN from congestion =20 >>>> collapse or >>>> that establish some degree of fairness between concurrent =20 >>>> communication >>>> sessions are out of scope of the Working Group. It is expected that >>>> upper-layer applications utilizing LLNs define appropriate =20 >>>> mechanisms. >>>> Work Items: >>>> - Specification of routing metrics used in path calculation. This >>>> includes static and dynamic link/node attributes required for =20 >>>> routing in >>>> LLNs. >>>> - Provide an architectural framework for routing and path =20 >>>> selection at >>>> Layer 3 (Routing for LLN Architecture) that addresses such issues =20= >>>> as >>>> whether LLN routing protocols require a distributed and/or =20 >>>> centralized >>>> path computation models, whether additional hierarchy is =20 >>>> necessary and >>>> how it is applied. Manageability will be considered with each =20 >>>> 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: In light of the application specific routing =20 >>>> requirements, the Working Group will either specify a new =20 >>>> protocol and/or will select an existing routing protocol (with =20 >>>> the appropriate extensions in cooperation with the relevant =20 >>>> Working Group). >>>> - Documentation of applicability statement of ROLL routing =20 >>>> protocols. >>>> Goals and Milestones: >>>> Done Submit Routing requirements for Industrial applications to =20= >>>> the IESG to be considered as an Informational RFC. >>>> Done Submit Routing requirements for Connected Home networks =20 >>>> applications to the IESG to be considered as an Informational RFC. >>>> Done Submit Routing requirements for Building applications to =20 >>>> the IESG to be considered as an Informational RFC. >>>> Done Submit Routing requirements for Urban networks =20 >>>> applications to the IESG to be considered as an Informational RFC. >>>> July 2009 Submit Routing metrics for LLNs document to the IESG =20= >>>> to be considered as a Proposed Standard. >>>> * Feb 2009 Submit Protocol Survey to the IESG to be considered =20= >>>> as an Informational RFC. >>>> April 2009 Submit Security Framework to the IESG to be =20 >>>> considered as an Informational RFC >>>> May 2009 Submit the Routing for LLNs Architecture document to =20= >>>> the IESG as an Informational RFC. >>>> July 2009 Submit first draft of ROLL routing protocol =20 >>>> specification as Proposed Standard. >>>> Nov 2009 Submit first draft of the MIB module of the ROLL =20 >>>> routing protocol specification. >>>> Dec 2009 Submit the ROLL routing protocol specification to =20 >>>> the IESG as Proposed Standard. >>>> Jan 2010 Submit the MIB module of the ROLL routing protocol =20 >>>> specification to the IESG as Proposed Standard. >>>> Jan 2010 Evaluate WG progress, recharter or close. >>>> PS: I marked * the Milestones that will be "This Week" and before =20= >>>> submitting to the IESG for re-chartering. >>>> Thanks. >>>> JP and David. >>>> _______________________________________________ >>>> 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 From gkstuebing@duke-energy.com Fri Feb 13 05:55:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 960CC3A6B01 for ; Fri, 13 Feb 2009 05:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ECa92tRnhbU for ; Fri, 13 Feb 2009 05:55:13 -0800 (PST) Received: from duke-energy.com (cltmxim02a.duke-energy.com [192.234.122.10]) by core3.amsl.com (Postfix) with ESMTP id B69F63A68DA for ; Fri, 13 Feb 2009 05:55:12 -0800 (PST) Received: from ([10.251.15.227]) by cltmxim02a.duke-energy.com with ESMTP with TLS id 5503591.6767563; Fri, 13 Feb 2009 08:55:03 -0500 Received: from IMCLUSEXCP56.nam.ent.duke-energy.com ([139.46.50.56]) by imadcexchub01.nam.ent.duke-energy.com ([139.46.51.206]) with mapi; Fri, 13 Feb 2009 08:55:03 -0500 To: Mischa Dohler , JP Vasseur Date: Fri, 13 Feb 2009 08:55:02 -0500 Thread-Topic: [Roll] ROLL re-chartering Thread-Index: AcmN4bVORxNyktS7TNyUgHLkAl3IpwAAGf7g Message-ID: <7BE02BEE73BE0B448EA3E7BC0A1D984702378B491D@IMCLUSEXCP56.nam.ent.duke-energy.com> References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> <49957091.5090101@gmail.com> <985801EB-0080-47C7-BAC0-B23FB6BCB403@cisco.com> <49957837.1000608@cttc.es> In-Reply-To: <49957837.1000608@cttc.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 From: "Stuebing, Gary K" Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 13:55:14 -0000 Mischa: We have had a lot of experience with PLC. Not sure how relevant this is to = the discussion however: 1) I agree with you, I don't see a huge challenge. 2) Routing is extremely important when using PLC in an "access" scenario. N= ot as important in the Home scenario, although the importance does rise whe= n looking at Multiple Dwelling units. We have not seen any problems getting= the signal beyond the meter. We have had some issues in the North American= market moving the signals between both legs of a 240v access (i.e. the sig= nal is split into 120v inside the home). Gary -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mis= cha Dohler Sent: Friday, February 13, 2009 8:40 AM To: JP Vasseur Cc: ROLL WG; David E. Culler Subject: Re: [Roll] ROLL re-chartering I am not sure why PLC has popped up again? Whilst they are and certainly will be part of the embedded system's landscape, I remember that we decided to exclude it for a set of reasons: 1) Where is the real routing challenge if you can only route 'along' the power line? I guess there are small items to be solved but I don't see yet *the* grand challenge. 2) A company trying to use PLC told us that they could not get a reasonable signal beyond the meter, ie if you have sensors reporting in several flats, there is no way you can aggregate this data in a single node placed in the building and possibly acting as a gateway to other nets. I have had a look at the circuits diagram of typical meters and have not yet fully got around why the signal gets so heavily attenuated but this is what it does (at the moment). Anybody on this list with other practical experiences with PLC? Cheers, Mischa. JP Vasseur wrote: > Hi Alex, > > On Feb 13, 2009, at 2:07 PM, Alexandru Petrescu wrote: > >> JP Vasseur a =E9crit : >>> Dear WG, >>> As indicated in a previous email, the protocol survey I-D will be >>> send for publication this week (after posting of the last revision >>> incorporating several useful comments). >>> As promised please find below the new proposed charter to be >>> submitted to the IESG for approval. In the hope of getting quickly >>> re-chartered thanks to let us know if you have any comment by the ned >>> of this week. The new charter is pretty straightforward. >>> Thanks to Dave Ward for his comments and guidance. >>> Description of Working Group: >>> Low power and Lossy networks (LLNs) are typically composed of many >>> embedded devices with limited power, memory, and processing resources >>> interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, >>> Low Power WiFi or other low power PLC (Powerline Communication) links. >> >> Sorry, low power PLC sounds contradictory to me... low power and >> powerline... >> >> I think the PLC devices are powered by the line itself. Where does >> the low-power characteristic come from? >> > > Although they are main powered they can consume more of less power (thus > the term low power). > You can find PLC chipset that consumes a few dozen of Mw. In our context > we are referring to > these PLC type technologies that opposed to other PLC technologies that > are in the Watt range. > > Thanks. > > JP. > >> Or is that low-power radio? (short range, small dBm). >> >> Alex >> >>> 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. LLNs >>> have specific characteristics: >>> - LLNs operate with a hard, very small bound on state, >>> - In most cases, LLN need to be optimized for energy saving, >>> - Typical traffic patterns are not simply unicast flows, >>> - In most cases, LLNs need to be effective with very small >>> packet sizes, >>> - LLN routing protocols have to be very careful when trading >>> off efficiency for generality; many LLN nodes do not have resources >>> to waste. >>> These unique properties lead to unique routing requirements that may >>> not met by >>> existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For >>> example path selection must be designed to take into consideration the >>> specific power capabilities, attributes and functional characteristics >>> of the links and nodes in the network. >>> 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 home, healthcare, environmental monitoring, >>> urban sensor networks sensor networks, assets tracking, refrigeration. >>> The Working Group will only focus on routing solutions for a subset of >>> these. It will focus on industrial, connected home, building and urban >>> sensor networks and specify the set of routing requirements for >>> these scenarios. >>> The Working Group focuses only on IPv6 only 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 explore aspects of mobility within a single LLN >>> (if any) in the routing requirement creation. >>> The Working Group will pay particular attention to routing security and >>> manageability (e.g., self configuration) issues. It will also need to >>> consider the transport characteristic the routing protocol messages wil= l >>> 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. >>> Work Items: >>> - Specification of routing metrics used in path calculation. This >>> includes static and dynamic link/node attributes required for routing i= n >>> 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 protocols 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: In light of the application specific routing >>> requirements, the Working Group will either specify a new protocol >>> and/or will select an existing routing protocol (with the appropriate >>> extensions in cooperation with the relevant Working Group). >>> - Documentation of applicability statement of ROLL routing protocols. >>> Goals and Milestones: >>> Done Submit Routing requirements for Industrial applications to the >>> IESG to be considered as an Informational RFC. >>> Done Submit Routing requirements for Connected Home networks >>> applications to the IESG to be considered as an Informational RFC. >>> Done Submit Routing requirements for Building applications to the >>> IESG to be considered as an Informational RFC. >>> Done Submit Routing requirements for Urban networks applications to >>> the IESG to be considered as an Informational RFC. >>> July 2009 Submit Routing metrics for LLNs document to the IESG to >>> be considered as a Proposed Standard. >>> * Feb 2009 Submit Protocol Survey to the IESG to be considered as >>> an Informational RFC. >>> April 2009 Submit Security Framework to the IESG to be considered >>> as an Informational RFC >>> May 2009 Submit the Routing for LLNs Architecture document to the >>> IESG as an Informational RFC. >>> July 2009 Submit first draft of ROLL routing protocol >>> specification as Proposed Standard. >>> Nov 2009 Submit first draft of the MIB module of the ROLL routing >>> protocol specification. >>> Dec 2009 Submit the ROLL routing protocol specification to the >>> IESG as Proposed Standard. >>> Jan 2010 Submit the MIB module of the ROLL routing protocol >>> specification to the IESG as Proposed Standard. >>> Jan 2010 Evaluate WG progress, recharter or close. >>> PS: I marked * the Milestones that will be "This Week" and before >>> submitting to the IESG for re-chartering. >>> Thanks. >>> JP and David. >>> _______________________________________________ >>> 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 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From Jerald.P.Martocci@jci.com Fri Feb 13 06:27:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E70A93A6BD9; Fri, 13 Feb 2009 06:27:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.323 X-Spam-Level: X-Spam-Status: No, score=-4.323 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DC_GIF_UNO_LARGO=2.275, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LITRPf4omngD; Fri, 13 Feb 2009 06:27:15 -0800 (PST) Received: from exprod8og117.obsmtp.com (exprod8og117.obsmtp.com [64.18.3.34]) by core3.amsl.com (Postfix) with ESMTP id 974023A6A78; Fri, 13 Feb 2009 06:27:14 -0800 (PST) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob117.postini.com ([64.18.7.12]) with SMTP ID DSNKSZWDPGR+GDHCw57GdiYxUgT3xcHPEvbh@postini.com; Fri, 13 Feb 2009 06:27:22 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009021308274214-1033567 ; Fri, 13 Feb 2009 08:27:42 -0600 In-Reply-To: <49957837.1000608@cttc.es> MIME-Version: 1.0 To: Mischa Dohler X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Fri, 13 Feb 2009 08:27:02 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 02/13/2009 08:27:06 AM, Serialize complete at 02/13/2009 08:27:06 AM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 02/13/2009 08:27:42 AM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 02/13/2009 08:27:57 AM, Serialize complete at 02/13/2009 08:27:57 AM Content-Type: multipart/related; boundary="=_related 004F61648625755C_=" Cc: ROLL WG , roll-bounces@ietf.org, "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 14:27:18 -0000 This is a multipart message in MIME format. --=_related 004F61648625755C_= Content-Type: multipart/alternative; boundary="=_alternative 004F61648625755C_=" --=_alternative 004F61648625755C_= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Powerline carrier (PLC) has been around for at least 30 years in many=20 implementations. It works quite well in the home market since all the=20 wiring is 120/240v continuous within a home. It has never worked well in=20 commercial markets. Most large buildings will bring in high-voltage=20 (13.2kV) as primary power into the building and then transform the power=20 to 208v (lights) and 120/240v (general purpose) within the building. The=20 transformers will not allow the data riding on one secondary of a=20 transformer to 'hop' across to the other secondaries. Hence there is no=20 ubiquitous wiring network within a commercial building. As for your comment about PLC only traversing 1 meter, that hasn't been my = experience. The technology is pretty good at data communication rates and = quality albeit the comment above. The HomePlug Alliance (homeplug.org) is = a consortium of companies developing and refining PLC for the residential=20 market. Just last week ZigBee, Homeplug, and EPRI announced an alliance=20 to develop the HAN standard. (I copied part of the press release below)=20 EPRI is the governing body over all utilities in the US. I am only=20 speaking for North America, but there has been considerable interest in=20 the meetings from Europe as well. If we want ROLL to be successful in the home market, we should not lose=20 sight of PLC technology. Mischa Dohler =20 Sent by: roll-bounces@ietf.org 02/13/2009 07:47 AM To JP Vasseur cc ROLL WG , "David E. Culler" Subject Re: [Roll] ROLL re-chartering I am not sure why PLC has popped up again? Whilst they are and certainly=20 will be part of the embedded system's landscape, I remember that we=20 decided to exclude it for a set of reasons: 1) Where is the real routing challenge if you can only route 'along' the=20 power line? I guess there are small items to be solved but I don't see=20 yet *the* grand challenge. 2) A company trying to use PLC told us that they could not get a=20 reasonable signal beyond the meter, ie if you have sensors reporting in=20 several flats, there is no way you can aggregate this data in a single=20 node placed in the building and possibly acting as a gateway to other=20 nets. I have had a look at the circuits diagram of typical meters and=20 have not yet fully got around why the signal gets so heavily attenuated=20 but this is what it does (at the moment). Anybody on this list with=20 other practical experiences with PLC? Cheers, Mischa. JP Vasseur wrote: > Hi Alex, >=20 > On Feb 13, 2009, at 2:07 PM, Alexandru Petrescu wrote: >=20 >> JP Vasseur a =E9crit : >>> Dear WG, >>> As indicated in a previous email, the protocol survey I-D will be=20 >>> send for publication this week (after posting of the last revision=20 >>> incorporating several useful comments). >>> As promised please find below the new proposed charter to be=20 >>> submitted to the IESG for approval. In the hope of getting quickly=20 >>> re-chartered thanks to let us know if you have any comment by the ned=20 >>> of this week. The new charter is pretty straightforward. >>> Thanks to Dave Ward for his comments and guidance. >>> Description of Working Group: >>> Low power and Lossy networks (LLNs) are typically composed of many >>> embedded devices with limited power, memory, and processing resources >>> interconnected by a variety of links, such as IEEE 802.15.4,=20 Bluetooth, >>> Low Power WiFi or other low power PLC (Powerline Communication) links. >> >> Sorry, low power PLC sounds contradictory to me... low power and=20 >> powerline... >> >> I think the PLC devices are powered by the line itself. Where does=20 >> the low-power characteristic come from? >> >=20 > Although they are main powered they can consume more of less power (thus = > the term low power). > You can find PLC chipset that consumes a few dozen of Mw. In our context = > we are referring to > these PLC type technologies that opposed to other PLC technologies that=20 > are in the Watt range. >=20 > Thanks. >=20 > JP. >=20 >> Or is that low-power radio? (short range, small dBm). >> >> Alex >> >>> 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. LLNs=20 >>> have specific characteristics: >>> - LLNs operate with a hard, very small bound on state, >>> - In most cases, LLN need to be optimized for energy saving, >>> - Typical traffic patterns are not simply unicast flows, >>> - In most cases, LLNs need to be effective with very small=20 >>> packet sizes, >>> - LLN routing protocols have to be very careful when trading=20 >>> off efficiency for generality; many LLN nodes do not have resources=20 >>> to waste. >>> These unique properties lead to unique routing requirements that may=20 >>> not met by >>> existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For >>> example path selection must be designed to take into consideration the >>> specific power capabilities, attributes and functional characteristics >>> of the links and nodes in the network. >>> 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 home, healthcare, environmental monitoring, >>> urban sensor networks sensor networks, assets tracking, refrigeration. >>> The Working Group will only focus on routing solutions for a subset of >>> these. It will focus on industrial, connected home, building and urban >>> sensor networks and specify the set of routing requirements for >>> these scenarios. >>> The Working Group focuses only on IPv6 only routing architectural >>> framework for these application scenarios. The Framework will take=20 >>> into consideration various >>> aspects including high reliability in the presence of time varying=20 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 explore aspects of mobility within a single LLN >>> (if any) in the routing requirement creation. >>> The Working Group will pay particular attention to routing security=20 and >>> manageability (e.g., self configuration) issues. It will also need to >>> consider the transport characteristic the routing protocol messages=20 will >>> experience. Mechanisms that protect an LLN from congestion collapse or >>> that establish some degree of fairness between concurrent=20 communication >>> sessions are out of scope of the Working Group. It is expected that >>> upper-layer applications utilizing LLNs define appropriate mechanisms. >>> Work Items: >>> - Specification of routing metrics used in path calculation. This >>> includes static and dynamic link/node attributes required for routing=20 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 protocols 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=20 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: In light of the application specific routing=20 >>> requirements, the Working Group will either specify a new protocol=20 >>> and/or will select an existing routing protocol (with the appropriate=20 >>> extensions in cooperation with the relevant Working Group). >>> - Documentation of applicability statement of ROLL routing protocols. >>> Goals and Milestones: >>> Done Submit Routing requirements for Industrial applications to the=20 >>> IESG to be considered as an Informational RFC. >>> Done Submit Routing requirements for Connected Home networks=20 >>> applications to the IESG to be considered as an Informational RFC. >>> Done Submit Routing requirements for Building applications to the=20 >>> IESG to be considered as an Informational RFC. >>> Done Submit Routing requirements for Urban networks applications to=20 >>> the IESG to be considered as an Informational RFC. >>> July 2009 Submit Routing metrics for LLNs document to the IESG to=20 >>> be considered as a Proposed Standard. >>> * Feb 2009 Submit Protocol Survey to the IESG to be considered as=20 >>> an Informational RFC. >>> April 2009 Submit Security Framework to the IESG to be considered=20 >>> as an Informational RFC >>> May 2009 Submit the Routing for LLNs Architecture document to the=20 >>> IESG as an Informational RFC. >>> July 2009 Submit first draft of ROLL routing protocol=20 >>> specification as Proposed Standard. >>> Nov 2009 Submit first draft of the MIB module of the ROLL routing=20 >>> protocol specification. >>> Dec 2009 Submit the ROLL routing protocol specification to the=20 >>> IESG as Proposed Standard. >>> Jan 2010 Submit the MIB module of the ROLL routing protocol=20 >>> specification to the IESG as Proposed Standard. >>> Jan 2010 Evaluate WG progress, recharter or close. >>> PS: I marked * the Milestones that will be "This Week" and before=20 >>> submitting to the IESG for re-chartering. >>> Thanks. >>> JP and David. >>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> >> >=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 004F61648625755C_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"
Powerline carrier (PLC)= has been around for at least 30 years in many implementations.  It works quite well in the home market since all the wiring is 120/240v continuous within a home.  It has never worked well in commercial markets.  = Most large buildings will bring in high-voltage (13.2kV) as primary power into the building and then transform the power to 208v (lights) and 120/240v (general purpose) within the building.  The transformers  will not allow the data riding on one secondary of a transformer to 'hop' across to the other secondaries.  Hence there is no ubiquitous wiring network within a commercial building.

As for your comment abo= ut PLC only traversing 1 meter, that hasn't been my experience.  The technology is pretty good at data communication rates and quality albeit the comment above.  The HomePlug Alliance (homeplug.org) is a consorti= um of companies developing and refining PLC for the residential market.  = Just last week ZigBee, Homeplug, and EPRI announced an alliance to develop the HAN standard.  (I copied part of the press release below)  EPRI is the governing body over all utilities in the US.  I am only speaking for North America, but there has been considerable interest in the meetings from Europe as well.

If we want ROLL to be s= uccessful in the home market, we should not lose sight of PLC technology.









Mischa Dohler <mis= cha.dohler@cttc.es>
Sent by: roll-bounces@ietf.org

02/13/2009 07:47 AM

To
JP Vasseur <jvasseur@cisco.com>= ;
cc
ROLL WG <roll@ietf.org>, "= ;David E. Culler" <culler@eecs.berkeley.edu>
Subject
Re: [Roll] ROLL re-chartering=





I am not sure why PLC has popped up again? Whilst they are and certainly
will be part of the embedded system's landscape, I remember that we
decided to exclude it for a set of reasons:

1) Where is the real routing challenge if you can only route 'along' the
power line? I guess there are small items to be solved but I don't see
yet *the* grand challenge.

2) A company trying to use PLC told us that they could not get a
reasonable signal beyond the meter, ie if you have sensors reporting in
several flats, there is no way you can aggregate this data in a single
node placed in the building and possibly acting as a gateway to other
nets. I have had a look at the circuits diagram of typical meters and
have not yet fully got around why the signal gets so heavily attenuated
but this is what it does (at the moment). Anybody on this list with
other practical experiences with PLC?

Cheers,
Mischa.




JP Vasseur wrote:
> Hi Alex,
>
> On Feb 13, 2009, at 2:07 PM, Alexandru Petrescu wrote:
>
>> JP Vasseur a =E9crit :
>>> Dear WG,
>>> As indicated in a previous email, the protocol survey I-D will be
>>> send for publication this week (after posting of the last revision
>>> incorporating several useful comments).
>>> As promised please find below the new proposed charter to be
>>> submitted to the IESG for approval. In the hope of getting quickly
>>> re-chartered thanks to let us know if you have any comment by the ned
>>> of this week. The new charter is pretty straightforward.
>>> Thanks to Dave Ward for his comments and guidance.
>>> Description of Working Group:
>>> Low power and Lossy networks (LLNs) are typically composed of many
>>> embedded devices with limited power, memory, and processing resources
>>> interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth,
>>> Low Power WiFi or other low power PLC (Powerline Communication) links.
>>
>> Sorry, low power PLC sounds contradictory to me... low power and
>> powerline...
>>
>> I think the PLC devices are powered by the line itself.  Where does
>> the low-power characteristic come from?
>>
>
> Although they are main powered they can consume more of less power (thus
> the term low power).
> You can find PLC chipset that consumes a few dozen of Mw. In our conte= xt
> we are referring to
> these PLC type technologies that opposed to other PLC technologies that
> are in the Watt range.
>
> Thanks.
>
> JP.
>
>> Or is that low-power radio? (short range, small dBm).
>>
>> Alex
>>
>>> 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. LLNs
>>> have specific characteristics:
>>> -       LLNs operate with a hard, very small bound on state,
>>> -       In most cases, LLN need to be optimized for energy saving,
>>> -       Typical traffic patterns are not simply unicast flows,
>>> -       In most cases, LLNs need to be effective with very small
>>> packet sizes,
>>> -       LLN routing protocols have to be very careful when trading
>>> off efficiency for generality; many LLN nodes do not have resources
>>> to waste.
>>> These unique properties lead to unique routing requirements that may
>>> not met by
>>> existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For
>>> example path selection must be designed to take into considera= tion the
>>> specific power capabilities, attributes and functional charact= eristics
>>> of the links and nodes in the network.
>>> 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 home, healthcare, environmental monitoring,
>>> urban sensor networks sensor networks, assets tracking, refrig= eration.
>>> The Working Group will only focus on routing solutions for a subset of
>>> these. It will focus on industrial, connected home, building and urban
>>> sensor networks and specify the set of routing requirements for
>>> these scenarios.
>>> The Working Group focuses only on IPv6 only routing architectu= ral
>>> 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 potential= ly
>>> comprising a very large number (several thousands) of nodes. >>> The Working Group will explore aspects of mobility within a single LLN
>>> (if any) in the routing requirement creation.
>>> The Working Group will pay particular attention to routing security and
>>> manageability (e.g., self 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.
>>> 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 protocols require a distributed and/or centralized
>>> path computation models, whether additional hierarchy is neces= sary and
>>> how it is applied. Manageability will be considered with each approach,
>>> along with various trade-offs for maintaining low power operat= ion,
>>> 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: In light of the application specific routing
>>> requirements, the Working Group will either specify a new protocol
>>> and/or will select an existing routing protocol (with the appropriate
>>> extensions in cooperation with the relevant Working Group).
>>> - Documentation of applicability statement of ROLL routing protocols.
>>> Goals and Milestones:
>>> Done   Submit Routing requirements for Industrial applica= tions to the
>>> IESG to be considered as an Informational RFC.
>>> Done   Submit  Routing requirements for Connected Home networks
>>> applications to the IESG to be considered as an Informational RFC.
>>> Done   Submit Routing requirements for Building applicati= ons to the
>>> IESG to be considered as an Informational RFC.
>>> Done   Submit Routing requirements for Urban networks applications to
>>> the IESG to be considered as an Informational RFC.
>>> July 2009    Submit Routing metrics for LLNs document to the IESG to
>>> be considered as a Proposed Standard.
>>> * Feb 2009   Submit Protocol Survey to the IESG to be considered as
>>> an Informational RFC.
>>> April 2009   Submit Security Framework to the IESG to be considered
>>> as an Informational RFC
>>> May 2009     Submit the Routing for LLNs Architecture document to the
>>> IESG as an Informational RFC.
>>> July 2009    Submit first draft of ROLL routing protocol
>>> specification as Proposed Standard.
>>> Nov 2009     Submit first draft of the MIB module of the ROLL routing
>>> protocol specification.
>>> Dec 2009     Submit the ROLL routing protocol specif= ication to the
>>> IESG as Proposed Standard.
>>> Jan 2010     Submit the MIB module of the ROLL routi= ng protocol
>>> specification to the IESG as Proposed Standard.
>>> Jan 2010     Evaluate WG progress, recharter or close.
>>> PS: I marked * the Milestones that will be "This Week&quo= t; and before
>>> submitting to the IESG for re-chartering.
>>> Thanks.
>>> JP and David.
>>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>>
>>
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 004F61648625755C_=-- --=_related 004F61648625755C_= Content-Transfer-Encoding: base64 Content-Type: image/gif Content-ID: <_1_0F131C240F131218004F61648625755C> R0lGODlhdAK2AecAAP////j40Ljo+JgwcDAwMHAAGPjQmND4+JjQ+JgwMPjouBAgKPj46HC46DAw mOi4cLhwMOj4+DAwcDCY0HAwmDBwuJC46HAwMBAgmHBwuNiYENCYMLhwKHAwcLDQ+HCY0NCYKBCY 0HAAmNj4+Li4mJggKND40DCYmJAAEOi4mHAgKLAAEBBwuMjo+HAAcMhwEBAgcLiYuJgwmLjQuHBw cOj40Oj46JiY0LhwcHC4uLjo6NCYmNDQmJjQ0Ljo0HCYuHBwMJhwuLiYMOjouJBwcDCYuNCYcJiY KLAAcJCYmLCYmJiYMJi4uHBwKBBwcLCY0ND46JAAmJBwEJiYcLDQ6Li4cMhwcNjQmBCYuHAgcJCY 0LC4uNC4cJC4uJjQ6LDQ0MiYEMjQuMjo0NjouNj46OjQmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAdAK2AUAI/wABCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjojRQoKZN mx4A0LxZIEOEgQ949vwpMMCKmz4XGkVKdGFQCwKfNtRQIKdMk1ShIqRqteFSoTVzZnW4k2fSqwql Igz6waDamULPAniLFmjcpmSRgimgFWTZmnLrjqTZFuFfmyJGRAXbt+iKxAkJK1SAArJABi+qzuW7 uPHhwlwJGnXRgrJlAJg10x34ufNAo4XteqAZOGHQnJg/aCANALbrzY1D2228dmhBqaNbEFQrmSDV xL6XV40uW2FrAMJdJ5dOXHrs4QBMK/++nFmsZsenka/4vjnn4ZqW1WYH3nsFb/DF+4ofmLrrcc4G cUXdYu4Z99t86rF320JU3WRVdkalB6BA1622mmAYZqjhhsX5x+GHdS0I4ogklmjiQRdalCJBlAGG 14kwarRijDTWaCNB77mIXU2FLfVgAbHtFxSQzhUgIVTb1XdagDx9R9cD/jXXYI9H/XjaWHNFSeRm Wwr03Hg7dseagamdRVVSQ7JXUHMIlUnUmT9N6Zhm+6FmhXIIAtigVUPylppWVAVZmWJpMkRZUknu eN6OSe05EJz0RUrVfXO1BSWOWz7JmZteGidnfXQOetmdN5Zqao5h7ahlY0PCN96FX1X/RZdRtR10 3UAtGqlYg6QdGueiOk34FWlv8VoaCmhO+NpRBRCr7JoGkmeTXDMaFGuXqGWmY6erUsjUsq7Kt2iE YLLJpau/tVkeikRStQUKNgVXwLvxcpfuuRMa66tAuSb2VmrbqoqpVn/VaurBCCes8MIMN+zwwxBH LPHEFFdsMcIgLMDCixUzwAEGB/CbBQkLIHAZBxtH5DHIKRmwQAMjrRyyQCCw3JHMEz1QMkEeLxCC Rzhr1DPMGMMggMQPGJ2RAirYbFLQHjG9gNM41zxzbyXsrNPUIWdMdM8/A2A1UBpHYEDY4amANms+ D5RxymMXlTXaHpt8UM9a6wRDEylj/621yyzHjdrHIev8c9VOB1DCz4rnrTPRkb0sWtZ2A35A43bP JXnjdHNgMghK05z44n53/rnTB4F+tN+Vc41i3lKzzDl/nlO4AA1az34yAjJjbnvgTuvc95oLtA1U CL5vDXLQHvet+MbMo0zU8xEkb7nYo69NkOrEo/32T4IrzjjlZBPt9cltu+x92clrDrPug2e+XOjW uy64QQpksbrtRkfvfAkbU5/byoa9q4ktdBdLoAIXyMAGOlBn8tseyHRWPPk1rnjem6Dr8LYAJqig AR5DIPXckjd+NW1mF2zbCE+GASgQDn0YfE3WYghD4xUEcQegYAllWLzigcxqOrTgDP9tSMIIugxy UltA6GSWMcnhDXJ+o6EDp0jFKeqwhxUsoAzD5jIsZvF+V+wh5MCWFi/68Gpd9KLdetY3nKWxhz97 Yw8RIEcE0g54VxPfWnr4w+zZzowRjMoOj/hHLMLMf9MD4E/kmMUqOvKRkIykJCdJyUpa8pKYzKQm N8nJTnryk6CEGAMgUAGO8YsCl0vABMKDStEMYHUbWCWLUBkAVYbnAqtUAC0TYDIDOCCVuWzlQRTQ gf3hj5avDEAyXykRZRpzlDDTJTB1IgEB1LKUvWGmM2eZSmw+AJsbgCJBwtmQb0ZAmuEpJjqJKQBf hoydD9lmUWzpTmiy0oBAwaYz7en/zG0aoJT2lGZAaRmECDAAB9bkJQCMYEzUIFQBiFqmNZmJq10G 8wCjXCUDYmADCERTmMecpkA9mk1jbrOWq6wnSdH5Gor2U6HuROktLzrQy1E0lv3U5iv5mcyCHjSh JmOoK2E5gVr28pcPWKUyf/CTDfBupbvUp0RlOtKP4vOnEP1JTidqTGlSFZUZRQ1HoYrPUEosllXc AAEI8EuzkkitbC2rW13iVVvW9aJG1ckvT5pMu4IVAhodq1V5alJtwvSXhOWmOQFAzpYeTabu5KY8 HdsbeiKWrEMdak3DutEaGFaqAuBsDJoiT5weNodKHQBTGftUq17zRaXVKFnhGYAb/9RUsgnApmhr YFl8vvSitL0BX7la0pJu87YVRSFFi3LTojaXuav76VCDKxq/pvKoqM3map3KM8CKlbfY3SpuU1rN vMY0ty/yqk4TSlOSTnYuqd0uAsQL2bZStr4YJStVcXnPzJrXvnPFCFoDHGADECCQFDEwgikJVwAT 2CCEremAk1rTl4aXntVECEsv493Onna/eLUrf+t64YtmNrlfze/7JFrc5EYYs/f9MHoLgt//inTE f7WqhqP6E+Se0oAprjAzk6rdps5XxqBtbHKhy2SsRlQADJWndPnj3p2SdcLODW2HBXtP6sYYu/5l 8VYny04fF6SqJcXyeO8p2o4Otv/KJhVxe13LzArP+LdshnMn33vWtTqYIQ2W64MjomCMFHrQCws0 w/Cs3sfOmJvBPemd17vb9Rp3xmbesJO1OgAfLNPTj6XolBEyWfyambCvrWx41wvZano5KvE18piX C98is9bGqXamkqGb4u4GFrx6vW6wW61l1z4axayWsYmBEutbi7m3/u2tmUHcXxRbd7G7Hq62p0rp 2RazNzfYsU0TqlsY/5iw2IZipJNNXvZSE6jDnnSo3Y1mPkcFtKhm5j8NSlYzV/HQCT5wSRQ9EXs7 0OCeHPBZZdlMWiP8IgR3SMRRMkpsvkbO1f5xrmnd4nnO+Z6pRjc4xWntj7+XyEv/lTW3Cwvv865a ALsuLq6PDWtbcze56X61zE8b5nlv3NEpvayxLU7lNzfAqMRec70dbtigqzjjqCElXqi9YZDLe01E nye+9Xzxdqfb19/FtLlBzu48r7ihS8bVt2vL57uaveNWL/fZET1wP89M4QlneMMe3km8r2TidAfJ bpU9U6vnEsfjvjRerRzYpjT60iWG+poNUF4Mk1urPHfxlnnr9Oq2W8hHQ7lqjbxZ/Vr3hg+NKKiV CWq4BzfnaxdunU1/eODGXtxB5jqTi7vpkkb5lToXt85FL1/QI1yawU87h39NeAUgnuq7jHzVgwt6 Gn+Y4202PWiN2+3GI9vnzQdp/+A18l6+913v40//g4md69Nm3+jcB7/cu3x79dv//vjPiPnzz//+ +///ABiAAjiABFiABniASsF0RBVbu+dYuNZXtvdY4RZjTudv98ZpxRZ/OgFQ/TZ2SpdjcCdPFhZv tfd2j8dYWTZcieWA1kVftPZ4uiZLFDZ2+9SBc9d17/Z1aieBEiaDE2BnWUd2LJdpIDhm1rWCTOaC XKWENTV8zeZU9AVtFBhspwZnNiZZCqhqwQZ2HjZ/04dMR2OBP/YwBiZwHwJ4DoSGiYZ+DqOGCuSG gadtLShmVgZ/fNZ7rPdpljZMFvV25edSdZZ6GPh7XRV7D0hcSjhzy2YtLsVLPf8Ia8ZHeJRHb4hn Z4vXUNUnaRe2fTp3iDTWdFRIgxAohMOFhfOGZWZGfCq3hLT2foYnhFE3dLAVfgZUekfHS0lXcn44 VUeoeztXgR54gSWVb0ezb7YoeQjoSPuXjAfHcR8Bhx0BjRpScVOHcV/YTRj4iXH2cXU1f86kgx73 bnLYblslWqbkdpPIfhJljt8HeSQIdex3Z9fnc3WIjCdWWcCoYyx4iaXYjjEIiWOnis7Gis9Ee68Y Wbo4UoHlZvAIiiqlj8snVo7Xh5M4eeW1cirobRJYXS93Q1LneYV3jT+njSCJZt3YY3AGjjsHZn1n dwLhdw1oEn+IdiqxjMxIIjb/+UkEB5M4OYoKGXabiHnkiGTpBYaxCI+9aFUCeXNNNnYwmGxeiErJ xy+GWHbpaHkzt30osnVn508cCH9Vt5Tz1VdROW5NGHtT+YpLx3K81nyVqF/NxYS+KJYvVZZIeJQ1 aFVYVoMLqZHgZih9uJbiln19SWcZeJJnZpTT5pBCZ48Lk5OgNJMjIY0ASJk3aTEvppc+GImRd5Ul aJKBaZS4l5Rw54qIuW3zxo4al2zSJ36eeGLHJYi+R1xFN4xX5oN8KVYMiXz1F5EbNZHTVJG6mI71 WHWviYPEiYj1mJfxl3s32JaXqIUImYTSNnbUWJKIh1tayRpB+HN3uW6puXlS/xhSnciYT3ea1hh9 wQaeiZl4aVkXkHmZJRKfHpGTO+mSC2GZ8lkx8XhhHYmcFwl+n0mRrtabx/GE8vN4QDiL+Qh1Cqp9 P/Gew1l55MhiCflXhUl/G8mHIlWEDoeVdJiBfMZo4oeKBhlTjPddxSmVBrqfdEefBwGjlJVJkmkj 9omfLpqjOrqjPNqjPvqjQBqkpVadsniUVaedKAmR7VmSRsloz2d5C2p9/8lsNpegqAR7G0qdndeO 99hiOPVcpbllwNlrVMZ8rZl4P6eO9BiGouhoLKmlwwZ8BpqJhhWUcDcZBtpod+lQApBVlYVNkTae u1hYq9dpLxiaBxCo/hlvQf84TriZohu1m66JlWJnVeCZmWopmkH6EDy5qZ4aEzIqGMcZjleJXWIZ pd11dsb3SiZapCr5gU8nmYlooenUVU3aV2cabXbapbHFgHdKaoDYp1VJbx4aZx1Zly8yeC/3XuhY ebvqj6y6mTSYnsL2kLZpmGuBoNMmqNLUqg0JdKGopBZJkOKlkpq4hQB6eYo3qCcSqhjSqUGqn596 IvBKEvJaEtCHpiu3rsm5rZ8HobUKbsRWer+2Xt7Km1kqnXvFasx0qXC2mOBqrUf6feJ1ofmVocZZ p+jqmzHAW2VpikYqftwEklepT5l3bg8LsFzYsbRIfQaJsAK7XuXppoyarH7/yXYc16wEGahOR6Kx +oLD2p7O6Xo8hpdymrD86YwM4a7uOq9OqyH3+rRSO7VUW7VWe7VYm7Vau7UwYS7QoiCcQReYQSnk ohBYkjMAUi2PAiwjobYpQRfzIRGBkmDYEixiIhgzwhZu8Swl4bVS4bYVAbi2wbdBYTDQYrgdUbYt IbiDUbeYoib4ASqNobiG0SzKQWNPUCfZohppyxnmsi/zQS6a2x+R4i3fsS9vobnW4bhA4QJhgAJW QRNdsB74AbfAQhN3GyyGKxWqyxx12x+qiyui0hCfiyy/0i29y7d2oSa8O7ybax5dQbmSEbxjArkH AizNuyR5OyGjuy7sQhyU/8Eb1Ost1KInt8sZ4ztMWgBh6wIhj1EuRFK8yUIcjMu19nu/l+S1OGkf l/u9IlG/DDEj+8IRNEEpr/EEF4MZIjAGxssRAOwUyou/J6K/a9stFHwvfjshbCEiEPG3E0IbjtfA 84G7wQK2UAHCwju/j/sfuYvCJczCpZsQZ2sQGQwVI/wsAGPD2Gu+0fu+1fvC+RHAYFETgMK2oRG3 oaEWUkHBLhweDawpJ1y3UnHDxJHDEnww17IkY9u/VwwicVskHtLFYjzGZFzGjwQ1D3M/mPlCZsxD RORAAmRCfNQ1ThPHgsQ7bJw2YXM/GUNHb9wmHIBFcFPHZlQ8JDc4G8M0vf/UP9KzNWsDQVrEQjxg QziEK2qjxyzyQQtBSGzzyCXDNGvDNDDDSIYMNYIDyltTyDCjxjzDxnasOQgGyQXRx6T8MjjTPGZT yLZMOK8MyXy8Q+5jGEQEQYgkN9DDxrhszLnsyadzNaicOnZEO4IMPk6Dys9sQoeUx9fMQWVzzWkz yrp8yEmzOr28M6wMYYEsRoNjM8mMNW2UzsUzyFeDxjRyzpikONGcuCWQzwFmz2aFzzRZEQD9YGE0 RxhS0Av2ECEU0Bmx0Bjhzw8hy2xzyG1c0R8h0bPsR7W8yoSsbpq8NTCD0cuxQwu90bAM0uucQ8C8 0RykPXdEx3lEOujsNOH/QzomXUTEE9IldETF7M65rMoWHdQkUdCPzM9CfdRIndRKvdRM3dRODTHM egEEQNEW0bSPqbQ1UrEygXBW/RFdnRJf7YBYbSMKEBv7Bk/JGYIUNYloHaAy11ejvLDzNhd/dmgB EARD8G3JKV5h5RWtSFIAkALEhaLRBQEm8wAFWoxuPU91bTeL9QAOVktQNEq9xIGV7XgXkNAxulwZ STSCjSMZxoK95NaTaE+BnYGnfdcGhVDSJVSswXCUPWvCqtjKqWUZetosotduPYLCOU8m09kC8dkz +lJxra/h6dm0CV2UPRfOKo4+xdoItVBseXHFPRc0IEsbQAMmY9qCLYL7/8qcuP3aVDaWO6vbte2K 4T1JMBqqTcu0Y02j7y0TAHcR850hWt2lILJ/YQ0jbV3bcljcy43Y571lDJnaMBXavl1ZxW1eif1u lfVneTVc/Z1XHPnWqC3cMQnegq2sLZabvzmj81TdD3DdL6ndR5nazihPpQ3Ygm0ARANRBS7YEy5q m7eHYj1vLs4vGQBsIxjgzc3dXXUWNbp7FSll0e1YOR4ecvHfWzji2G3iK8tbCy5RM16Me5UAU746 E65QiXjgDeXkJf7buGrhFQ7cKD7X5cflWL6xGyKj+y2q8b0SzjfV8RTnF/Nw9T0ReY7fPcnQVW3n GPHmksTgF340xEQDbP+K3MQdp1ZuQP0d5WtO2BZeiosu6TNZ5e644ofd4KX6bkAebVnOiOAX6maO 4QGb1icu4+bdc0BO4WDOWCYu2YwOXfCEK0IerAYA24Z9XBAQ2qMmndX06Ycenrfd4i++5Gpe3ePN 3PAm27We6oVI24SeToh+6rsNqVxm4KPNlqUOb60erHK47RYz51TNIXv+EOeuEIIO1rR6EeuuMPoN 6Fst7wVH75vt53M1q3Nt7e107DxO45tu20AZdQEvZSwe5ESR6+PtT3Nn5AIv6vdVj+kN7LQp6ypV 8Pr2S0nup0BB4rAu5gR5HB6f3b8d6XJN699242HKfAtu8olnrWdOldL/zuVwPet89uok7479mODd 3nMlhemS9mc+3uwYSfOFvvFyUeUGj9xbLu61VNfH3lEY3+j+dOWhroVdLu6sgeCZTtrBfvCfHkrx ed82eXxSXe6CQe51ju8vwdX2riFDXkWQ+e78bdalROlHK46NGEGyKvHdvfcO/vT4BPRj3ttRMfKx vq8s2PJZ/uw7d/Ui/+Qm8+iCrxPHTlrJzua8PvU8322K7oxAHtu4mPGJat7h7uAXB/LXGtxdZffV Y2nOhOlaWBAbAFre3XJcX/UhU/lRTuNMb/pGf/qG/+is4e8KRfi4P9t6vzrT/tTkh9V0f89v3+bt fklqzxHX30CDR+oM/4vmVsb55bhleT3zIG/xJ8+spk/6ui+CLt/flbbvTAbz3a1Q1i350P7t8K8T uk7elk/mxQ8QAAAoyBAhQAIHBwAYaCCQYI0ECAAwgNAQQAoBAQYIAKCRo0eGDgsKHNiBowEJGTd2 3HhQIkqOJD0KBDmBJEUEMymmDDmw4IOEJEue5GmRYAShD2jYBLCBhkSKFjF6nElSgcmFRUUidYgV plCKNhnEgNjQQMKZaVuuVJsxgVm0bFeS7EnQRkWBUyMK7fh2YdyYNyGIjXFXqsqYLlkiXhx2Yowh XlMqpur37IG2fDVv5tzZ82fQoUXLnDva9GnUqVWvZt3a9WvYsWXPpv9d2/Zt3Ll1w555uepBuAcc jzWc1+3LlDgBPJg8N6rxuhnuMt1d3fp17Nm1b+fe3ft38OHFjydf3vx59OnVr2ff3v17+PHlz6df n31V+zRLY8cfv//m/v7zLsD9RBNwtgN3S1CoBWNrML/qCAxsMYG++q+y4KiSS4DouOpLoraeu2jC r0g7LivGYBIRoxUnvIooxipDbsLfWrIMMAo9alFC5Zg7sUT9YlzrRI9eRJGyla6igaMWGdxox72A pPCyvoISKrriRixpyYnwGrEqI2Hi0UuMwpwsyuaE/DElsCCQyEckEZOxMTI5NGokkpRiyikQbezz o/3ipPMwBtF0Kzj/MxmTaS/g/lJIMMJqcK7ORBVr0irJJpxPgQsIsOizBxUs8LpQxys1O049TfVT 2lYFcFQINdQUQtZOBRVWWk/rMc3FZB3UOMWkNIA6nHprKDNMYWwrWDZNDHJYwXJaaScS7yzLUR3d XO7MPxv1bUPHnOSI04aaVJLJOjHEdqVvAXV3xw0Va/OwzLzF8cOF7vTQXswKFDRbQk1c1s/FKmU0 yQ64vDTPpQTis9ch2yQsy6ni3QveWflFVqAWi42ot4QqtXhGX+eU8t8n67yy2SCZTTG5OhfO1T0J cbO1O1cprBVX+3w97ebWgH7tQKFPy3lm+hT4gK4KDNqw4Ex/20tc/6oBBnYul6t81NnLdk0RsGwJ 81Dkk3BsN+zHIlP24EPXdZfqdmm6sV93rR4xXL7wC1FlgeMluMio2d4S3YAZ3vMpiBXlOF2/3SWb zon5lvvPX7WENO2o2Q0587LpljXOFjtcNMMClWba6bcBVxbrqZ111u6KEzNU67wZnRvp/I7GfXeq SeU5t6JlSzB4/n5XjfifjU+v5JQjnbvGzjWey2CoJM8xZUL1dBhxqlukvss3ee3ysA6B2jpfke4K /2u6sX2edYlWppFgMdmF+TCZl2u4KcR9xjj0O5VBX8k60shQ1Dt1xW1v9ApUytaXtaTs72H+S9fs FjUjcyXsXYN5DP/F7LQV8wnlcSZj2VBQNJzCcJA4jBMAxrqytuoVDl8LNE57goc87eBwM7rbDg9p o8Ps1Aw1PuwdfYAIHhwe0XW8u+AJVXau8V2tbXFTILhY2KvWvbCAdbPg4iLHQNl1y4qEUduR2Ca9 t43ObXnD2kagtThpoauELssgl9C2QvIN0IuYW13nHtcumaGRjdFz4LbWdEjmHVJcy7JdcApFOdi5 aGkValq9NvI4fPFlA01LXMu6iD6fqM+QKJRUGrUIE9FN7notvOIqsRic6EBEIt8rn5Wso8T14LJ4 szKV8XSZPF5q5pdMJGYxeaM5zDzvffPrnNcsyb5ank9/h5tl4GL/KEVhWvEw33MhKI8SQgLWj5Dj VN0WIdfBOqXShOLE4ozgBhhnfrKT/4GiC2VFSuxB507TMWY//flPgAZUoAMlaEENelCEJlShC8Xd WUyQxSIWE5dEvM0waWXR0ABxVRT9jEMhmpokKm+JDDUNRktaGhp+aVIyxKTMElW1QsLpab7qWisL RbpZaY9/1YQR7dSJMgF8L6JCtNB+UFhGdvaHlMtsp85ompB4XtNyquTXI1cJEj1GUaWpY2omwbmZ 6CA1TRCsELHcVJVYboiWc2TXsS7JucXEUpk4zZMtu2LH5qFThiBrn1YxktZD2pNgtuFohGBl0tEI DbE77BSruOPR//gZMWLZDOZ9DivSk1Y2aJjlDNE4C0ykCfKdyXSkTh/WTauqiIUzqadND2LXdfKK hBOKauLKeUpuvXKNNRPtUBsYk6Kykjqc2YBFHtA0wDLSnWqs6QNHtVSclpOdvunq91irQb8y86rK xOAVvyoQ0yIukGrN1OCya9WUYkSEcD3bkOT1WmlS5nZcu1ciyeofzC6WibZCns8UqkT9aqewCPpt ZwKc2M82CLLneaYz/xYxQFqPr90ErKM6pkKyCK61edwKc6GqLThFyVr0u18Nm5heF3FOViPMKx5N TNX57nEspVzcNq153nCydZxyQ9SNVQtGzUB3t27c5xWxmj4Qa//FJ/tiS1fnpU+RyDK27JNVhT9n QGFZay8sPiQmXYYlDpJUzGMmc5nNfGY0p1nNa2Zzm938ZjjHWc5zpnOd7XxnPOdZz3vmc5/9/GdA i9kABZgkWAktFA0UQAQjWE4BLHCTFxQATx1ZwaI/k2hHI/rQn3lAphv9aNAk2gPW6TSow1NqTY+a NQpAgaVPM+hCTyTSsUYPqjnTaVp/Ojuw1rSlbV2bX6fm1wyI9KZBE4BKM3o3nXZBC5Iy6dwE+7EF oHa1qT0SXkO6AKMONqsnjWxX7xAF0NYMq61dgGaD19O27vS50w0ATJ972w5Bgbud3WgiVHvR7bZ2 s4l97kX/+9z/oI43td/NF29zxdymFvWnBa7vESRaCQBXNqhWcHBdy1renh60vGP98GqDGuTUNrVm +F3td0uc4hwrdrXzXXK+nFzeoDZ3v++d6HxbmwotV7SyR85xY2uc255ueJ48/XNP82Xki645yu+9 GWkLXeMDhzfFba1ya7v65zBPyrU9pOmcV3vnWVe2zNF9706H3QVSWPl2sm3oXBud4JL+OqXDLcyL P10zb1f3o9mdaWSfnd4jKTpJRM13XQc78O9OeMYXsnGSD6Te1Y47TVbwk0Uj+yfv/nvJC/94rjNo BfM2eaYRb2vEf7rjG7fA6mcOoNEzftxI+fygH336pJc+16jG//2jCw/uivPa9VRPvdwF8nneB93x pTd172+de8svevjWvj3djV91VVfI9JCHvmf+PerfJ5suh178vRsv7ahrZ/rVHnXx+86XQTc78NUm N18Kbu2lNd3gaF830c+dhNmrOnnDE/0TvOUTwGoDwJFouswbPXubvrvLm9GLtUQ7OFtjwIgjPe0L vcfjPr8DOtbTvo1ztfmzOUqTN4zTNGtTQNrTQNCjtxB8vt3ztAJMOQ0EvvGbpBJ0uservIzbwZAT wdfjDAysQb2LOcgrOSAUvEGbtKtzQduzPBQ8QhicwuO7QfHTvkm6PxY8QAwMNDAcjQJ0wTCsjTHM vjJMQzVcQ/82VMP1ozY0RA+kqz/bSL/VsEON48DWuD/KI6iOS0HXeEI9XI1EG8Q2JCn3w775i0B+ s0BH+zdX4zcRuIJHjDQ0bMK6k7og47me079wE7VFrDh1g8MLnDxqC7dSg8SyYz87vD9LezgnrMSe wztAVLqWmzRQdMC7O7m5Q8Mn9ICaUzVMS8FGfLpUjLQI7LoP9Lxtq7mDEzVnNMb+KzlerMJTZLSl G4Fhu0UPycVr7LogPESkScTa274kXD7nkzzCq8XOGj1fy731Izwo3D5aQ72NG4lgS0dDwxPnw8PB y8QcRELfm8dHm784RD7/yz4c1MIODEF/ZLmDw8QrPMh5+zz/7Mu45Ku8eESKYMtIgbzI8StIB4xD ccwVciTIKwy3AEACZwu2fyu0hVNBH5S83Es0fLQ+yXu3jpPHS8y0lzS8yGM1nfS65fvJK+y+8cOT f8MTm+RIpNQMTGPGD1hKrmhKkNzAhYjFD2TKyLvKhezBlKy4lWzJp7SKVhNFybO0QpSJCbxCUwu8 Seq8sMyTDxDKe9tJp9RKjeNKnrwS09PLkowzBYiC4JvF6EPLwCQpi0y1xGxMx3xMyIxMyZxMyqxM y7xMzMxMzdxMzuxM3FAAFVgA0RzNBcAAaWIiA1gAVgGBBWABD0nNyBINBuAA01Q6DoABzfqZEiBN 3sRN2pjN/9oUCBAITtkAztMMjQfgTdEkzuKkzeNkjeRUzhCoDxDwzX5Kzel8DdBUTuacDeM0QxVw Tc9gzdE0zdTkzXJxTqtQgewkT/TsiN0kzdgkCfcczfipT9PcTtIUz71TTeEMgdnMTtisEOW0CPyE AvXEzolQz+E8AtK0Tv0kTcfqT8c6Twl1iNB8z4HI0NFkgRqIz+U8gAZ90JiIUNEUT/w8nwAA0dI8 AAsdzQkFrwWYz9n0TRNtzQhgzcgCzem8Udf8zhcVTQNVTv/sz+wEqwJdUBhoAtLsARaFittk0tF0 UvkkUA0d0dG0Ts2ozlmpT9G8Twxw0CwtUQ6F0QUlTh4VTv/ljJ8bLVIfrbvZJE3zTFIASFHbbNEg i9ImfVI15c37JNLyfM7jKQEt5RgGJc7kjM3UbIDvxND2ZM5ExVD7LLfQjJ8VRVFEndHRgE0QEM8A HdDl0FS68M/h3Jo4ZQIVCM7vLFWZKIHpBFUMjdErKVIZVVTVhNUNbYhIzVPiZFWacNVQnU/67E6w UM9gndUY3dX1NE1lzRtgZdVmvQnnbNZFrVNIFVURStXjpFbVbNTZ5M9LjQBv5QBwLQHX5NaG8FX4 PFK+4FKEq9RfxdStWdFXxdZcPdOtSdPttFRzjQBcBU1dtVfPeADrRFdrFdRb61Zj/VauCNd9jVek UNdGvY3/6JxU4exO/SxUC22ANLVWMcXRPBnTzorPEAjXg71Ti+WM1OTPBaVVSV0ALZXYheWABcCC Q51XYLXS1hwCFZDVUZ3QjCWRDuXZT4nTlCVP01RXepXWKj3Z8QzRDRXNQo25Nc3TppVRxzLaL8XX l43ZMO1QgGQQPu3amBjXcv3RmT1bhctQr8VZdhUKL23RFRXNku1Xp13XUT1Ros1b1ezYuV2AuuVP C2WBvTXUq425Qg3aYUXYv4Varl1QtYVPujVZde1TYn2Pyk2zihVSYNNQP8vcOdtcl71Dz/VM0z1d 1B2oaK01bD3Py7WPiQVd1IjWak1d21VdIq1N1ixYwF1Q/3aNVNZUVZr9FICFT/6U3dXV0QBNihnt 2OXATeOM008xAADlgN+d0dqtU2FdVZiNieR8W0Pt1e6V0elc3pAV1lAF1GPZTTbV1jgVz+0UTwU1 31q9XfsVj9W9WLddiN7dDHVV0PX8FIKdgZ7tjGaVXv4FX/qEAR/IWeME4FlVYPjr32LVXeJcWl7d GqUFVgjmNIGt1g5OVLNt2H7t4Ps94YPK3rtFYRZuYRd+YRiOYRmeYRquYRu+YRzOYR3eYR7uYR/+ YSAOYmJSjo4IgrD1jKr4rt0wAAKwVCOmrJEyEF/6rFWLS07aISsWV20xgKZRDi42iL3YpCOG4iBJ DU5BX//6QljNEOPFuWKEowGs6CTx4C3Ogp6hmYsHmICbYeMuceMyXo7huuPcBA0FgOPEmCxiMp9G SaRF8ou+cCs1iStOKpan2aE4VqMrUxwEIxEC6OROjiPwsWN18a/i+mKVha3aMQoKUIgXUYBVXidP LqFbCYy2YGJPbuJUNhFT9pUXsWVPRgBf/uQHqJ5PrhDH2oBbtolMXuSIAQlbCmZcxuRmdqOgoGN3 gebYhB5TpuTUcaNbbmIJqWVO8ohh7pJiBqU/piSkKBYZOIANAGaOLQhshp5EwmZNSmbbshFIruVn /mY0PjMjISgi/oyANiYc4mOK8GPIrAqEhgCFFmKIjmj/ie4OIUJiKt6YzvKXSs6oAjs2Kv7jPK4o PEZl21iQUqnoQUJOphCiPE7iap6L4lIP/4ookPpo0Bqejd6sQSYPZlYTcV7ns2qcuOrnWwbml9au bXYTKhnllShlP36mnr6QmfLmovYtDvFnKiljbSbp/kjqnGjnd2aIo5jnUVGXhfDns/7kefYLn8lq V1qkp/FlUGZkmkJruqAOlDZrnWmKbGaXX4YpDpnkswJreD6KK3lmwY4jpmYMnPBqqdlnoQaJcQ4U whbrgqDrAqtlf34muEnsxxzoidaOkJ6NmH6zAwtt1E7tOLshm6aZ1hbpnabp/AipYBptOx4IQ9YP vIqJ/9J+ldgW5JrWrh967czamd82qKWm6l/GibHebDdKbJ3QFmkmEcQG6rmO7A1x7Jxe7J+eJ32W ZKQACbsuY+3OmOyG7qm+6qqebrTabLbObOX+5LSo7Hj2V/SWHU/ZO7xuI45AZk9W5ifBAR8ojXc+ bIUQ76Jm7sum5q2xZ7nubOsG7IFRlA1gCnue7uRmJQQ4iqjObqL+5QwH7Lhy7pMg8ZY57/AmboM6 bZ7+aBY/s9GGjd5W7b2mcRu/8YIqGh1XcfAarkKO44OIZk5hE4b22XR+cQLTZOOWD8TCaBFnsI6u cdegbSTicYe4gH+eEpIWnmmO5Eeekl9GFn6e1/Ru7//1Liuh8O9OBvCgooAluO7AKHADQ6nsHu+F mGxFKe9O8uK/lgn65nD3omx3Lmx5vm+5ye9Bwmi39mo9b2wT//J6NvQA+fMFj2RrHvEzdyXufhqn /roJz2c1cfA+5zFQrxD3huQQ73T4C3Oh5mbw0fOrQnEpb5RnwfPrUm8Qt/OFivHWmHHgsWkkzyUr XyjQLqZil2LhLmkXH3Ycb3Znl03pDoAnXnLZ7qXjluN0nmXfDo9QOemcLo9Lh3YnHmOOzikrMYJB Rulfv3ZqB61NJjNFLvP3VhSp1i4EZ3XgwvOmaABTZm8PP3BBD+v6zmRxYXToTgBEh/BQLmtKB2NI 3nf/U35wrvHs1xFqTY9vcB6VCw+h6M6JeR/zGn+mC4c6HGEkyD5kTTFlZBYfZwZ47VIOVacLWzLz MP947A7sFKeReV91+W6ykx9ql+9w4Drq1O34OTv20GJ2hUL6IFL6Z396qN/hYJ9yXHmQAPtx/GbT CyBy4p76bL9trNdtU+KOmV5x5aHyKPZodm+PRZf0m/dun2Zwf79mt9f5n3d1V79z6+5pt8bojifr j2h4bAZ8KVdzAmBzV35zJ39wVZfr3jDxzJB4Uq9nonedmTB8NmcAAffrcxamnZf8jhB8Eg+Qzx91 SN+Ptt/7Mk9vPf8PuSb8KzF0A6eLR//0lp978F74/7GvTHWvM6b/p4KOeuEffuIPKK8vfuQns45H q8RedKw+6k9P678G/eSv/tV2euvPfu3ffu7vfu//fvAPf/Eff/Ivf/M//+9gaT0eaZdfdykXjTO2 6M7RDSECoiRe/7VXe20/nilO9ioHCAEABgIIMEAgwYQKFRpEuPAhRIYHEzYkWDEixowWJ15cWLGj xpAQQYIUaZLixJMqV7IcSDKly4MBEjTY6DCmAAMVIgBgAAFBw48TDRAoigClQKE5izI9SpGmTZ08 g05U0GEpUwIIiGZ16hIq1aQHDTg4UBDmWYQNpfb8qTQt16YvBShlO1dp2LQza+Zt6BOBggwR4hpF Sv9YK1mzc9se3dCAbcK4W7Nq/Rt4MGWgKffqRbs2M+e1ZTvT5Th2Z1qkpEn3HZsZgGSKMg5s2Nrg cmuxN99+7hoZ9VrUf0PL9DxU+M/Io3EOPAwUbHGBzp/yRdvyOvaVJbNzz7i9O/jwLb+LL9/yr/n0 4smrb1+evfv48ufTr2//Pv78+vfz7+//P4ABjmQdRtspQMNVX2k1kAIXSKAbdoulBsCBCZ5FA4Qn fQefhlVdUNN4BLbHYWokTtjhTSWKeB2HJrIYHXcuCviQjB6ZlqJIDXpF41DLzahabrk5l9iJA22Q 1QRpKUDBEppl+FV1pelGpIQVHclUkn7h4IN1krH/NRyMQiLnZJGqFZTAZF1ZJphzwfEEpkBwqoiV XDeW1OaNsI150UWxEfSlW9bx5ppvNuEVpkzQSZnWmpgV6tJstRlwm2BhgURkc6DZOZSmOAJK5qWv AfDAaBUNp2hdpUZXF3DGQdhbUwxBhZNdMFpFp1HT/bgrr72OuKKvwQo7rEg1ZmfsscASuyyzzTr7 LLTRSjvteckVFARPEQqqrH4Sqlcjssnuxq2NDoUbUYvkaruoSuea9NZ9G8LkLo8pondtti+mSK92 6gZI6gGD0oXqZtuOO2WnzbUqkGOQMSdnXnCKZpZHBMcZ6MVOTmyRxXDtmadNjPX5sW6wFobuvDfq /4rToYsG1bFfP122ckGR2obbqmjhWbKdMI/lI80C04zpmVGa6lbHEueMsG9+KvwmxhgBLDBx7Ja0 mMlajTzVRA2jFvKn1Pp39I7M2eftfvyKvbavarMtH9lvyz033XXbfTfeeZvn9rv+lgktezoW2CPF 8foNXpWHo4zQAxPwre+AOO76eMj9Si7Rk84KCTTJD//0KZ8dB60yaDZPeplqbfrMM0LTOb2QZC2L PNFfoBeMI2e0LlzRrUOKCiltN1cKI2yduh7r61WnqpirukMNKuld3aXywrIFf/rw7A6p6k1UEtpU oxtn2nSsNK7u/W6KEr2+8QkXvdror35/ct6U6/99q+Vmwq243jPaPyP++ifAARKwgAY8IALrxz+z zYdf9EJbSOx3tdsxCEFqGQCG/sbAZUEwguT637o0Aq+Q3CsA2BLXQgA2ECNcTn8haiGKNPiry4EQ fc5p1M5slzGhJSwv1FnNxi4FNPfJTnzvE9PzRqinJBqMOVcqSpYOwoAt6Yx7N5RZ9thHPvrBxkfK ox3SjAZGJw2tc6pR2pQWVispsYprB5Nd2EJWl9+lsCxU61iZ2HKkB/HpZ8xLUexU5kWQQSk1yctT 1sg0J489r3hG+QgeX9crECawksVa4Hr418HIWbKT9QmgJ0MpylGSspTNomR8jIUsVPYNhmPjFiv/ RaiuWJqylm0b46d0eMao5WY16JGkRUxHqQh8UTruA9L8tCa6YwKzkBGLGhqLCZchbnFBHBPjlLi3 S41Rz42YUyIOexgdoiXSkda0JTrX5rYHKguUd3MnJysnrVViMp32vCc+86nPffKzn/78J0ADKtCB ErSgBj0oQhOq0IUytKEOfShEpxUYG+Dgguaq5ykxijn6KLFeG61c4y6iQlrKsoXpcqUMkYnSkqbU hRTKAEVX6h0CVWilMiJJAqzZoAfV0kWU7MgcpZeSoEWSjlVTaRE3lbGdwc6MwbzeMI/qNZ4cUn4D w+ZHN/gyEBWJnKtTTuF02Utf8hJG8VsiY1QK/7/yja9OENJlSxUSO4uhTyFPJEAUHRLIkqlPmzZZ UpO2CkRO5WpMcIVI+Pz4J6OOsU+v2asNxcmuiO7nXpTNGzwNmtnukPSynv0saPfZ2ZlKbrSDc+Um FxfCGILUcSkZ6YomWtE+yvQ/PszqC/Mjr9pekrcsZWdpU4baD2r0R4f13Fb2JMyZHfNPVuxUzADD pmNO9Yeb+yNSlXqRDSTpiIjKSecWc1ytuip3cTVbRfbaxq6Gl3hg/RPJBPvM5DJRLasL56MW6SbG RFaoNFzudPOLF0Xhl636TeaOpBlN4lUXbGPaJm3Xa1rEFVdAlg1teibcyc2K8sK6rTCGQyziEf8n 8Lbx/NGEfQpLQrLExHsDMWlRSGHfEut/5EnteVu8QHC1E6YV5RXVtKvU2eHqnKmpHTPdyt/MkPNG BS7M68RKPMg+V8CIRLB1lybf72rRwOl9sHML51jpLVPAioLwUPfU1z8yVa6cq68hm8LU9CqZzlz8 Mpzl+tg6Jw1jdtaakNPozcjwGatBTBRWu4jdZvaPnjR2KYkjTVANS7rSlr40pjOt6U1zutOe/jSo Qy3qUZO61KY+NapTrepVs7rVrn41rGMt61nTuta2vjWuc822BxTAAgPhta81ooECeGCUwy52P4G9 617fDwUFKIBgIGqAZ1O72sWedrWpjWxeZ7v/AC5ogUtWUO1oR2TY3S7ABzSi7FExW9jEJuCwg/2Q Y79L3Od+d7xFgu1uf3tY634Ir9OtkH/XZ9/Z3na7ecXtbguchC9IeL7Tw4CHd5vcA5x2w2GHboXk m+ABWEG/wy2CEWBk2iGnyBPU3W6Cl/vd9GF5fwhO7+tM3OUqwbhcoZ2vXsGcIAFPYcILvvGEdDzo 5em5SViuAGcjOyNLt7h7Pn7y/CD9PjiHyNV9zmyCT/zkHx85ukAObozU/NkWX/e6l15tsA/k2Gr3 9tgHUnada90CNR/5258N9rnrneTsfvbUF270Pw29Jy84+bR9DWy+F2Dkx/54300y7bMHfeEi/7hC u7NOIRRAfeFT/zvcMZL3xvsdAI+3N9u1/mwPVP3nA0/43C3udme73Nyf93zcNc9uxbd75r+uPLUv P3jDZ3vvFKd7RGD+9dLjvu3FH8G6Tx/5hDQfsQ9v+kJmv3rnh55BtJ/+7mvuAik8fz8GHzdVC1/z aP9b7dhffkR0r5D1Z2vY7F/5yrF/dXPL2/4RoL/z3V/hjYr+DZ3MFd7S4R0KsB0DWEHcJcTEsR23 RVsEkhzaBZ25CRzkYZ/1GV30kV7dNce9sd2wNVwCklwJEsQJQsQDFKDAZWC41R4IOp+8Ad29MRsA mh7dmRvChV7NBVsKeh/YZR0AfiD2fWDqtf8e7D0cufkfCw4fvQXh5g0h8u0e92mguCGbFK4gRJgb tWUcD/6eDz5csLVgZBjgs2Vc1dmH/BFettWg4M0gRaxA6i3E0+1czmWcFV5gsJ2f2fGE7zmfB+ie srGcH9Ldvx3is1kA5Nlc/DHb0g0isyXe75UhBjoiJYreApZeCBJi5g0g8UnivVmAIg4fbJxbtAUi JXpiDb6eHlohK+pg08GfCKZbKfqaH8Jh7zmissXiE8qbLwJdKxret93iKVIeEGLiJN7gMI6EuIGd 79HiKQrcId5fK66h0L0i4WljJcrdw+mhNM6bKU7j6/GeJeJiFd6hLHIcscUiwU1evqhjIoL/4kOU XTMangiQwQu84LdpgATiXw2q4jjqIDf2Iiium/wBWxuSo76lI+cBojKiox4q4Ssa5EQyWzTSYenh 3EIyJMDt4hEu40XeoxXWYjn+ItDZIj0SHjIK4hlKJHcoW0amHkc6pDWepH90ZEcSnPtZhEZmBP8R HbrloBPy4eaFHLalos1BXroRJSIG3dIh5R+ym+zJYQAgQQsYQEtChNqxXSM23QVWZQHeY1Q+4EnW nAk6Wx8OIOQpZepdJbgN21ti5UOUpQjuYEQSX8MF5RNWJA4yYf3h5Sz+pEnq4FyC207iXxMuol6q oFomH/I5JdRR3yVCnFXSJTyG4DoSXjIe/2ZdPiZBOOFMbuTG2eUpPuU1VqH53eC1rWQ3sqMLiIG9 TWWBzOYAxl6+GCX3fZs6DtsXzGYr4qZmCiXcqePmTZ/gsZ3BTWb2KeNWHifpCeQ9luLWJVwjEhtC nhsHgp4ccmcdNmdxPuRmiqC8NeK3UaQwEoRwuqTIkaYarp3fJWZ5oh70Wedsst5Avp3xURtzUma2 9WdyxmcVGuFL+if4PcT5geFSEqZH2l4LyOPg6Scn6poBKUAUkOZ3jpqFYuiEUqiHTpJtZiipXWd3 fqiJniiKpqiKrmgtleJ29sr59ad6YKNKrOFy4uGx2KaM6k1b4mh2fCBJXkfEseiMdKSw8P9a4N1k e9DoSVRdOIIHXzofN+bNsBHBQLIEkybdlRIpgBhp2zBoei7pljbpOGameAzphqHAB3SdWf7omGpp kHJpl96bUipB+RHfG/6elfYd4zGmmY7n66kmngZffWZbyA2bncKnN2ablVqioY4dr+0p6TFeo3bh 841e90UqodqheEYEph5qASTqpupgtfVbIH6gpD4bFRzfDPapJUqqiBIjYlahFx4c93Ubwp3jomZb usUh3DHeyKXd9wHe2CHqndZq98npzbkmoCrbx11ksXmc2FFmMq5lnJKqtr3mGVbbC/Iis0ndA74j r2prQUzrcGocuXFhKJbkI07pFJZezRX/26kuI3POazIOZhJ+6wpAK7tKjWX2nyOCK6AKrFEKLNaN a78qm7rGa7PSq48q60l0pHSe5rmZ4xmOpDfyZqeKBMP+G+SFXG/mZSx+7NhBaA0GI7pmizteqcEi 6EFiZF5CZxqy52uO5jZSbLdZrNMNK7WBKgdGoSOuo1G2Icl6n5J2YyxOrMwyK8S2a8uN5buipGPW oceCnBTEKoVowUJ0bMJpXshCrbrC4gCabEKEbdWZ6cJeX78e7OcVxBOkLb7FbB427L36JE2W5iZK bUQwLGV2K/atYCCuoFGa5sWWrXgSnMLm7aLKq9wWbtNKHmsCaiaSKLGurSKebLJ+5rmB/+z3OV62 JYF4Ki2mMia2PhvoHq33VewjWtynQuqbIusXLm33Tawfgh3lkq7NFubt9hs2uh4Eqi3sIl/wkptu 3m66Ievp8kTeBWu7tS7NniI63unjLguvheS1Tq97BCI7vij2NtToumD37of2CiX3hq/5ni/6pq/6 ri/7tq/7vi/8xq/8zi/91q/93i/+5q/+7i//zsgDLAAAAzBX6Q0IwMBN/O8AK4AKhIBKMAAHYEDh yB0HGHB4BEAJBDAGAzAFywcIQLD/ZvAClI14OLAHv8cFB/AAP0sBP9qzOHAAM3B2uHAAlzDgXDAN j8oNv9MCW4QNF84KN/ADR/B8GMACpP+weZCwD+dwdyAxlobwnwCwEnMHE4cHES8ADP/aFavwBufN A2wxdrhwFhtAFIPHFJuwFy9EBx/A/3qwAmswQpSxAsNwGoMACqsnB7ww1mWwV6TxGivGCVtxRPww DptACYBIHKugCrgxQfDxAmAAFATxry0ADOgAJDMyAO+IDC8AE6iAEctVEdthIkvyTWTyJnOVBePx Kc/wAViyE/MwHg8EI99wKkOxWbSxKCdfKyNyCc8yA1swC+QLE/OyBJewLW/xHNdxXarAGFNIKG8w EtPxJ8swiDyzAPfEHX8yIisyLEPw/15yIJ8xbOjxInNzAGPyNWsyJ1szDR9yOGOwOQf/cCm7MgBn sR1jMBs3s0PEshBbcBRTczRfM1dVcTmPsxqDcCMLcXYQMT2j8UG7xAU7hQJDMBzvMADQ8S83x0ET MVeBgAgDwA6IWQlcNB2XsANn8f929CFbcE08gAd3cVI8NIMos1mMNMUgsUIP80zf8qgAsgtzlQJ3 cmRgs0O3ckQfQE8jck2UNPWFcBnT8Qb/LwMrtc85MU0jFiQXBEwzcxSfNEMjgFRHMmBQ9KgY8Ffv tFcH8SlDtExX9AJcdDgrMQKPRFYXtQtfdBtf9E3XtfImMl4DclrHtAc7NeMA8kMIckJ8NA+LtE5D tTUL9U+rc+GwM2I79C8fdUwnNQeY/3QuU98G/7VW5/QyzzJhN7Zd8zVVEfZkY7Vik/RVl4cCu7Ut N3QaT/WOaPREy/ENn3QmL/Qig7BI07BAZzBQr7AY+3EDWDAMc/UT18RsS7A2Q3ZF0zByh3MCp3PJ CbVZB/VjYPdjBzcGN0BTS3cJMLB313Fz1+NVKzdGd7J6S7ABl3c1c7VGtzMIg3cQt/d8n3d2ezJv 7/d6T7EDu7Uv/99VB3i2DDh+f/J5T3dhgzM0Y/BvgzR5c3c63zYs+/ZgUHhNwDd2+9xTb3Z+LzOC ijKAc4CAhzRPPHgAR7gdizh2WPTOMfF53zRtW3h0R7BhY/RCq/eA3/gT93cyYwEHbP80BlTBBtM4 WPs4ThPxRcu4eE94Fj/2dQ8wkpt1lXf3aENgay/4eIdzf+v3/F11lbc3bWv5J1e5QhSwD3S5l6M3 BI85Vd9wjjt3J8P5WbP2iVd2gZv4gaO4nSs5Vn/5GfM4igP6dF95hbf2IRP6LyP6hme51Bx5lnM1 mGsEHds3nvf5LzN6itNwGZtHbNvzTN9weYMIfMsxCFOwd4OzaDuBCrD4E4NwR1/4FrdxGNf3NhfO FF+6k0t4JOP6lHuycP/6sNO3O+80LXM5DMP3UVT6UtNyqbOgQQO3QTuFXse6HjNxtLN1BoPzVIPw hA97iec5gWc6ZZ92sSs7RKg4FBP/Mga7OqwHOrF/N0aDO1a/+6vzRDcXO7MD3BZvu7PHtEFjtrmr NjH98QLAe6dH8L67eLAEPD7Nt3tIfEJBvEBRPHhgvKhZfCnt+yuLh8fPM0NxvD6FPKQ3cQYDef+u PMu3vMu/fMU7PMyvr8l784/UvMxbtbeT8QT7Vngj9EqQucbPPK6ROc9tNhjPzc/H5GZTN9F7KM6P +hFg8AaHelunuKhb/ZkLNRF3NJk7MAVb/S/TsVfEsbbbu9gfvDiHeWBjwNQHMKsjPAR38Ntrc9oD nEFXs7FXM9g3AQb3AMKrdQa79dNLmtHnOiKHO66fNztfNixTMIOnUNOz9VbkPaab/4WB2/TJc/h2 qzx0M75YazkNg77iF/vANf182/m4a3qGD3zhV9rhG3qXx/6Mb7aUB7gN8Lm0l01Rx/50zzYSG33s M/NAs/2o+/rWbvmT+3dGCP0nJ/jlSzC5D//rkxjtL/8pX7EDN7t453JcC/zO+3cbe3D227FTEDEN tDISn3JAh0D5S/BWXHHjt/jx87Cg5zP2X7D2c4DXo/4nA0SAEgsQAABgYAGGAww4KDTIkEUEgwIj ClwQwiAAhgUzdvT4EWRIkSNJljR5EmVKlStZtnT5EmZMmTNppnywAGdOnAVBOJxYAuNDDjo59jzg ESFOFkNUNOh4k2PImzoJfmRI9P/pAqdCfVrEGVTj0Jwcpy6AIQAkQ4dGMwoE+xEEToVsf4K9OlZq 1Y4ItwJQoALnWa5Hw0b8aTgs1pqLGTd2/BhyZMmTKVeGLFCwwb9vLXf2/Bl0aNGjSZc2fRo1ybI4 +wKgKDF1bNmzade2fRt3bt27eff2/Rt4cOHDiRc3fhx5cuXLmTd3/hx6dOnTqVe3fh17du3buXf3 /h18ePHjyZc3fx59evXr2bd3/x5+fPnz6de3fx9/fv37+ff3/5+5ABIggMAJWBKQQAIcIKwzBS5I MKqOAhhAgAkFYACCCE9CMMEKYJOQQsowJFACtELisETNHlxQRQUJc9BFk2BMkMD/BixEyQAaCZjg xo84JEBDk3KEUCQMPZyIQgt7HG1J10JskqQeoWzpRw+nJGlIAoN0bUACj6xJyRBZMhK2MCsUszgF KGBwoi6BdJKEGj3qUc0DfixowjgJaGDIrWBMMU85Q8KwNS6JDFMHCAhkESUoOcRzAD2dmnCGCxww 4ckk3YS0UgmA2MqALz2qsyQDFlSgA7TqRFXVNU09itVG0Qx0zza1HBSCSUOcscQbSX3U1jcBeKCB EQnw8AEDPyKWWCTPfPZOOAXl0EBgJdxU2loNJSDFhxRVEFNJg9VQyl0fBDTSGvsc10kTFcighiQz VfVBbtEi1lhklW1LzHcj+PPC/1wN2mCrZLfl1FJMoU1XW2s9YnYrM5XEltaIu6y2yy1BM7ZbFJ9t 91oig+113nZf5RKBG6/0a00fuyR5YRNBeoBEmbctkFQMU34ygZ1NVJnnmsv9+GF7S3KwoJMtVJpC pP1K9amafZx13pwz/ChWk1mcmEirEfDaAKcYwOFjAzQ0wECd2zVzW5jbzZrlo9QO2V6gBfgVTZDt 9prumpXu2e63W9b5x2rlRWvprSkMWyOybzS7bwP/RiDUCNBO4Vmvh2bbQr73SvtqiYOuu2qoNRv8 6tQSP4rzvH29IGnFP7Z78sDTEngv2UW3ecO8T+YXccDFpF13NEMVotCO4Ha5r/9YV4Wa1Iwql1Vm 4tn0aANRV1+bZ8oZNeh38MUmu9mDIgxABsLQt/Pw7Vu/u2Xwv0eqeMSbbrnJwLcHaejaS97fWSCa 3eJkx7ixCaB8kANe7ljXMwBsoAfpQx8PnBI+kHFvgAKwoITSNxEJto+ArDuc4Bi0QdIYK0bDItAJ Rpg/ND2gRDQjAAszCDKA6Y1ChALJjN4kQxruTiMQ2FeU8rYtK73MfjIbUg5C5MMRZmQDQ2xRjHS4 Fx1NakCMQtDWBtQt6i1QZV0S1QN1xKMQDemH2DKiRDh0JHyR7SAV4MIQq2iQB1QgXjFT4QxbODqM eelDdlxhH9GCxiLS7FL/E2P/IIfml3MlEYfBA6QLC0kgJlaSj/cqFhxDNcc5FfGGjuTI79oYgc0R co0ZqeOw8AjCew2yhtRKZXvQlp3oYUmKytnBUaYHkywJC0Ar2WUcP/RLjQUTmclU5jKZ2UxnPhOa zaFkSVYmEttZs4jXpKab9lRNAU6Nd3Ny0xgX86P5RWZlWTomGJ8ITpOEkUY2Gqcp3cQidd4ygKZh mztfos2YvO9EJZOJN2UTrYply0+PjORBt/VHYXlMld86lULbVqFNVbGXxkqkuO6kUcJoNFzTytgn bQbPh3apCBLFVKUSKckdfdMvGfjXI6tIMDs6FGHfoxP+RnqQBOH0Zjm108UY/ypAhmYppYvCVKKU mimmushhD4HjBfP5rjyeToTukuk3szREhgKspgWToixvKDGKMSyhRqNUwi6qUnmJy5FS89ZWbDos Mz51o4LyVlPhCqyKrSuiizpAKGnjMbtZD2WHLZ3MvIa3kp6Ri1/D3+hgNk39IdFR/7uf3FIXLC11 DnVfM10knbW8trhJcpGt3OUyF9opRStuQfwa7DLCN8P2a7T+fJ/TAghQtnkOfPv6EZAKF9QFDux8 TaOtO93Xs9VOAHNNgpv/ZofZ7lH3tEKbF2Kb9NzoupK07Eyi5jT72EJGljZMyyB3hZfEvcXvIPNz LFcj61j1xhF5JI2kejMLSf8A6hd4Fryl7UB7vXzKr4EFgaAEZUDB+LLpteaKnYHlx4P58bdf8NUt KqXXUgwuFLIUPohwXVdienFkSRtIrs3Cx14FR9BODS7ULanrvhY6N7I9wrB753Xfjiw4xg72rYn3 Oz/9EXlytXHieksWyiWiUpal9GkmizZRo02ZhnvM8gNzqUIP32jJXmYTIhWmt0X2rZujO5IsyTw8 P8K0thTlLSkXGWGZwdCik0RiKpe8JGppM0s92O6e2/zKBT3Z0EMFZEcO6Nk0mzcjMNTTm/xl1D2L N67dmvM5G5ppHr8ykxD1NFXDXOjAGZJ3m86ql8sMpUKbeZLlrfJgKRpN5cH/19beIahK8ImeYfYy 18EW9rCJXWxjHxvZndl1QMN5nGVbZm5fdHYRV7IyAouJTG1a865wDWAiNjslz9YvEGki7n5SO9zo 5ud1IPqonSr6Ta9TK1rFKTK6GaisaF3XXwWVb7gCz6D0jivp3KtGXrk0Qh7NN0sZ9FWF8rthPc3u rda6IL+qkV99zRjHPjUwsY664grLtlR/5mYTQQxJM/jABStNN0BlbKetvtjBwPfTwLqIsL0dAF4V ZiYZFojmfUPxy3yQYROcVeNAt5aokSQpwD7Ko34dAEt7LvCDK8exYFuQzsirwRx3r95X1sxosatY /4YwsQLtrXWTuGNY20u9/8AFGXbHjXYB+SyScq/ou2Vb0W8WWLaP8xBrm4t3J00hebV0dIpqqbal mVFmKr51VrW+kAx1brSNXa5+kyxes0spAU7Ru8fsu/XQsf1tmQ/tfDENeMJxm7OGf5+PkVP66yWr WRYsfBgjRPvYIjjtZ4+l3dtLVa1llbuEVO/yOR1Auv+d+HhHLEjc/mAGGn/6+QTyBCv49ZIn6mwk LnmFOuiaDxZyyw+MkO0fNoFmAR741NdpiFEGfSZ/7AGMMiHwAQ9m93cf+aoGvgRssiAt++bOyEwu +cBtOFBtlrKnTOrMXNTq0qKGyu4N5MrryOhl3iBpgfqsZBwQ0bTsjGBplv+q6uGoLXDyTfhOUJBC bVbOLMxaTwZxbrl+hwUDCM9UaarKJVFa446u6iA0bausiMqk7IG2zaUc6ojkKtJsUOykx5KaCFxc aQNopAmPJZBIEJO2DAJf8IcUSenOzAFbT80kApHgzUoUMARN0D3MrTh+jZxGQg63EJrgUCR6LdlE ow730A//EBADURAHkRBt40qiLd0YcCTwkH/QZOQE5Hs2oETuqdviTEce7TfI7Z/QjREpw59gAqAa 0QMLarvAqxPhjErUTdnUDkfK6Epg6zLeqkZAaurYSmSQyq2oTgwJIKmqkMcYLqoax2ZQDk7c6JJY rgiZLeNE6lZGpV5IhuH/cjBM4KqrIoquxEoTw+qmMlAXA0Z7ZFFbMDCU/I0Z460WL6WtmooD0eXf gugab2pCeE7g9qoKkw6Ymk5d5CTgJAWjvtF+5HFhADLoqnHizPFMgHGkYAtFfhB8xqirFIujrC4F OwUI1NHhnJDRBEbeCC62lk7iDoSQron0Nu/axiu3NDDDYu9zVtLxKCRZ0OaaJA+bqkcAVbLDAtBE yu7GZmtLvCtm9qkhLQe6noXuJgTxwEmbpku1vA9lum7i3Gb3WNEngUibNlDuNnDvSpFodO7+dmv1 Ni/sKisl+470ChAoRcnzuof3ilIrj8/4xm78+AtbGiu0XOJ9bMf3TKXV/0yOhMyQaPZvxNqi/Nbn RiAwJtfJz3qs+axvn3SyunpvfrZPxjAISiTTwdgS/EgqKQdwKRNsLRMwJ+vHLe/OnyxTV4bPABVT xDbQ7QQvv+zv85RvMcNnx3TswmRnvo4neTpsLx/zMz2TL2dPdrDHH1sTx9gEMFXiLtWuzwjNF6WQ AI6RzVwE0fzszHgQLVYpCE1MnWIqAjCkyxLTv64TOsOQsSiqOveM6VRklOoHSlStRdBl/IbFi0Jx 4vBNzh7u0kppSUrtOaURlG5wOF/N1Z7TpMYIK0HQA6OI+qbQ0KoO/wy0zioQDMErWNzIBMuQQcMS ky6p3S4tBwWppU7NDf8HxhVLMNTUSMqQEDxOsbYqkTH6sNpUMTtcNDz0kDlwlJqILEZ5aQ5FQkYL UUiHlEiL1EiPdD+KCxSziZt2k0lo1Kja6S1n8nbWyTJ2DRGp1EbRicjMTUnPrdl+jpym6bgm4xPL CUqVUdq4o9cgDosOpRY9RbDKFKHYpeJojUQYkpgKElLs0Yu00a400YbyswNHTuEm0lI+CnfqKlk6 CndWy+bo0cq8KIjUkXsokq/KUajoBgGyzQAkoOg4CunK8U/dyh41pE31TR/PClNT6Gl4J+Qo67H4 8VERlKjOEd7wJB198SKjEBahkxdValQjTmhYNVHXczs4pgVNym3ecrj/pG+zAk9MapNJtWu8CnAv Bm8od4eSJsd/jpLzmBIptPW7XEos7wYsF6jzuPLDSMv1Lo/a+EZNqsBwgkdXrbUvLasm+y4jpQYr b2s+s3ULh4b11s5npOsk3aUuAfbDbAxWKZS3Lohh+09W+W5Ll2PIvA4nD4xjD9A2V0036WdjKZZ3 TJMyubMz0y4z6Qs4m81k7ytkr8/50MsvG8ljqW2D1GQJ6hVlWjNa9bXtFlMzy6v63tN09olk/86B YvZFG25ab3NkZXPVbnJK5afMfBZ+sqr6CjZZvyVGEhSW+tNVh8tGdnENlcgNN7RoYBCSyjDO2hMn p2kcU/Be6rNf6HaH/wSUMGZwQ5E1DXPugqrzhQz0DF9RjGxAiGquBy5NQeeuREW0N10QhYYzcBpX RG+vQ0yJL93W7wYmPG+1emqQykytDS/wCU3X79KwcR/HBC0Xy9L02PpQR9VjdovjYr+jdiUjSJGU d3vXd38XeINXeINj2c60sNSNoG63JB4xASJxEu1tRhXRTHm0R5hXCUnjLGs0TbM0etulJaWXXZ1t 5shxT/ZNVWsFIvXRjxzVUsm3UPZRfSMyGvVTZP5sHvGRWIGE497RroJO6tox0hqgfPLEGFlxyoIV VAYvQXrR4hLyfEElUj2rT0kV0i6IGCll5VgX6PhHjQjSHT1uG6VuK/+N64C9CuPuMwOdLn7zUVvc 9yOqEeokik3ASoYxUOpaNZEE8s921cNcODeUsmVBTPjMDoOWZ2KjT7dQjzTV8mkTrKLgpiq7xymn Mlq5zrUMuPFCxyUnACZZMWLN5IthT1qFL2I59L2mdvEKCXQgRYMgr4xPBIneOCgJr4rhdYSfOF2f 0maAOPiEuMiCWLo2zymvb4lTTfViz2YJyYiVGIkNmDZojCmJWJJDMlr5T2r7uLtEs5D7mDGPsy/D 12B1T0xeFmrtj4PU5/ySUHNHUWSZ1mrpzy9lljEVGVuPS0kGM5UNIP2s74WHk2qhCMa4j5edJZPR eJh9D5IBuS1dzHj/TcXCIKyIng+rfjmfJjlrqVY4lRl8T4Os8NaaHTc6KXkJuZDVJlA+37I5/VU9 0SSUwsx+WVnUpOxv9fZC2UgCR1E7W8m8unNkTKRvnbOBY22IKZQLSRR1fRB37EifwadXkGiVKjTP ohAteZk/pbSgCXoGURhAP420NtrlXApD5Qtvw44JV/kJR3QXDcQ/e9ibYTfXyPQ+cvc5FG94a9qm bxqnc1qndxo/lJenf5qnD+pOQynKeuqID/JYe8qDgZqpb5r3PrYpD1m2HIuIY4vr8rips1p4n7qJ m5IzZ9gs23KYRVaryxp4242dKaqoF00EHdQ69axmwNOs5/pIfZqu/+8ar/Nar/ear/var/8asANb sAebsAvbsA8bsRNbsRebsRvbsR8bsiNbsiebsisbOci2SugpQewJel/RpTHtJH5pRwwXeh+DTC82 s/HQs2uIuT6bY0URFbGXRxMRtbXSPjeRtVt7m5e0grl0tw2RR61qLLvLaFjwqCKYFk8VV05z4Nzm V4z6I42Lodazkdz36RxYq/JoBZ/RvIR659wqovXXrYpOYXN13KAbIyumHwMJhmEuJW/YFimuSxNS RdmuVykVaAASUcB7IJF7UbHxuzM1HCu1HjUVa7gb5M5KZg5VohvqTi8OQqIuun+Vm7kpZVCLhJ21 kTNIjt21joMka/8cNlro0ib1+Iyxj5smMZL3lXAwPJuxT5wvC19Xx4pLvC9rHMbt9SwjtvJw/PVC F1+Bx7biOKwzyPesmSo/vMOpWI+imIzrEpujLyshbV1f9biGHF9Hj6BLA6YHFcWyacMBbf6ELzm/ 0FmM03uQczY1+Wepd8P/GBVfnJJiM2ij9l7+b6wFiACNmffwy0nj65nbL/dA05JH+L/irsgXEDZt +5Llj01MNmNN+b8IOfqqb2aduGmPy4LcDjB9T5+aFKYlrbPNmaO5RqIJ9Ax/7ES7UFPq98xYFKIN eperu6XHU6C5ykFft7vb8tVWusxUuZ6Vlq0fl+nUVo8f8Esq+s7/wna+Fy3MUA2gOHfKjpF0I/TL JhQjJ/q+UJ13uN0FdX3UCvqQoJBSgwXyJg5DRxeqyBOioSM5T2N3uSPesQ5GdclH7RA75t2y953f +93f/31HA4aNv80qICDZm5dBJFGDSjsRYap6DT4Cr7fhdbufTrh7PXF7r4Z7YVslstR4OX5oWRm0 B8pCwZQ4svedHFkkRPvcXYbhYyN90TfAJbQZkXVYBDhiIqWA4XlYLSa9+fLmB3jqMjiabc64nYq/ fZjj/+az3hu7U3iFy9fA1buGJ65Tv0VOyd1+cPgAltrTPEpSQyp/yQUcdUW/eRhTyBurogpQG7Xk zZ3mqF6w4Fuk/+cNgA/GU0GV3uA3f8USrq4u7AUuGK1xULOcp2o+ulex1E1RyWtZeta4XV7y3B2F ka85f1JcjclycVqePbG5vazZMdX07no8Q7qu7IrvxH+8XTNd9R9HXF+nJ8XVL68yxncRKkPIxzuL mOj4J/MGbpzyt644nEKf9a9mXnn27qY8XxlfY3M876BceY7W7lr9VkicXz8DyRt9mvMHl9kHLQxT Ktnc8t2c/FDZ+w9il3Mn0AsZ9Fcc3D52g3APAPU8klFfNRedd0S5bV8/mr9HmgECQIABAgQSNCjA gIMDABo6bDhQQESEESdGVMiw4sGJDyY8aAAA48ORG3rIOBBABv8PkBolHnSogALDhiIdWiQ4sSbE lw9FBkiA4GZBhzobxlwyAaFAoD5xbiQYM6NTlwUvLlRq82lVgkVJVoiQNeHVlksRFO06Mq3atWzb GiBAIMdUinMtJoD7NSTcEzwZQADp8EGFGjwRvoWL4OGDvXUPHuY7dOfQgTr+Kh780oCEyEvhbgag 4AKBzznhyi242IGJg6FHb33tN+nDn3AJJIZ4l0BeABt209YdYWJr0rlJa1X6+6tQAKln4sYb/Dho 0cYjpzZRnPN011gVE1B9PDnYsEI5fl+NmnF68EN7jxc/MvTtplQnzs6dVPzy5voLw6T+WnfP6WYD BLK91UN2DS3/RgBkyz021YPqjXRdeLnt1tAGtcE1QWkN4pSbbQPmBV9bJp6IYooqrshiiy6+CGOM Ms5o34w23ohjjjruyGOPadXo4w4MGYChjwAIGVKRRi7JZJNOPglllFJOSWWVVl6JZZZabslll15+ CWaYYo5Jppa/ESBbjEB2VhtgWAJJ1o5xmrgck34lNqeJrW1IQANrtvUnXQH+KJ2NLQVKp39yFvok nBE2pp2Ld/4YYpowrnlmn0wiumVUIw1EAlwNHMZSiHgOMMMFEgAB11WSzTZAqJqyeWqqC+0pQWWA ETmeQbKypBWoogrKpqVnnvqrr8OS9VuHpvrVKnrbGZcsrMkO/2TrAcMJAO15deV2G1s1Cjvrb+FK Ri6wlUULYm0IdAueDy9FZe5DfgG2AWAdHepfvekqq+mxAAPWLK32QsButfV+ip/A/zoc67KPrutt VeDSVJul03KL8HfOeWqtqKSyKSK2qrLqcVghl3uxybeKNpquNO0Gr7YAdtltdchtlJ19mIZom1Ce 3mkffXnaFVSwPCdNlQIdRDrgZkhPPZXTnP0mtVY+AVXnqz8xTdNYXCstwNAQnEtoZELLBMCk5JG9 HNZUGbbQnWafy6sBE6RQ36Oc3V2ehZ7NHZHVMLHtttda3f2Q4Tb1vDSbWVvMNL+v3S2fWluDPVLO AcYN+WT9Av8NduGIn130WH7DWtDmYDKrtepzCyigUEWlLlXrFQjhptdjv0Z102ynZfTSwZvuXPGv bd41cr+HndHzLaG11rixO/cppLCLlft+HoFEfYYmoaQSsH1zdjvZdHe/+PAhuZr2ztyvBfL77FOu fFmW2w7/SDoxryjWxY0rsvNZvwrDP+zhTilE4l32Wic2tFmpWykbYHo+NDvmpGxAogIddGoEofZo THJDOcxp5EasgnkHgyhs4bc4pEEMapA9G5PffQbXnW3Jzy7QiY1arPe5C/UqhXOp0AUhM0Np8cY3 QozPBeZTwLncEDiBCxCDHCQ4NLFJSUZ0HnQYBsMrtos7MXT/kIIsl0SefVBBjbvZmigoOxuKMYPN edyG/JRF5fAkhBka4QxtRsYyfQlJvAKN+1QGJUdBLUqcEqQjH7moRUJyTITMS/0miclManKTnOyk Jz8JylCKcpSkLKUpT+nIRjIygD5K3IlUKcg1HSZjgRJYjmAJSx0p8lU0CpEeJemiXCIyfq9kZZOE uSJksq6Yg8KkRhSGnxq6bDXV0uE0n9WxhSwsK9BEzL0ypK801cxf2GQX8FB1AW1eTC8wXMssO6S0 a0VsVtZE56pahb2GfFM4MJucIaOHmAGd65u8CadGsuUvNYqInVp85xRLNk+CsZGX/OROukZmMPso IAOEIRxr//oZGYLma0HwdAlC14nCKRIHMRqlgLQKtjCH/tBUA4va1WharJwm1GIBvaa7xrlOfWaT msMymJi25zj76e8lSAOg2kL3z7adbZnIk6pZvqI3vu2ScXKzYEsZYrcn6kmsiiOc9JgSQQNCzXFW 6R5NMXc6vGF1b+f7qlWrGtZwZW6mg1tb7h7qGqfKD3CVIuL8gJQ3uqIxqnZjG5A8hdezYYRoUHna 4cB6tr0CCqpV/dngkgrauEaWcyQUTlyp2j7MSpBLSHWfYJ1nlrRmJooQzKfK2kqS8aVkJQ9UKlFo u8PZ2hZ6JlLIS79VOrRGj3N/ck9Y8ve1s/QvtyfZrfkW+P/c6f42efCDLlQci0CmEnC5Fkzf1SBF H+qSj7dxKgpkC/Pe+SnmewipX/io592ygRd9squfffuHW0TmL3zl1e7rIJXTek6GjQoOzIT408Tb KtSSZO2Kz5o4xz+aUIpbDE52CGpH7mxYImdksBt5UscM8amk7DSju0YElhL9B4r3C/EvO9zViS5I PRKSISIrqjMPUjG8rTONYybURhoTC8Yt9g8fS+RcHmpRPx+2DIV4fBw+rhCJMI1mf3g6ZOs82GMy 3jENpawkUyoTlSnSWzCJvKRKDpHNj5TzKd1M5zzrec987rOf/wzoQAt60IQutKGztOZhbsqYKUo0 ajl2KmD/SljSKXIlVuzjFyaSiJW5dDSPdskiS/+Q0YmiNDF7W2ra0amwMgoUg4CDal5eitSNZtSi F+npV5aYpfOSyU6lGdGBYTShv6pZiCHazUAOKD8tsyfKwEOxMzesnBUDdrXa6BpjU/QlH/nITmbw Adq1EFwtfamX1ynTEDvrxQ+j6cMUKsFtabum29sOd3DVt2qCVIARrZkOHQIvorIsoI07pLCX5W5n 4xMmloWVrcyNw57QMovwvDYH55MxgA812BlFJ3h+hdF/z7IIQ6X2QtINo/jebbKZFe14l0o5CwJO fWB0jV8FFFrVqtWwSS3t9WAuoNceW8RJmdRFWHzZ+saV/+VMy7lVNdu4htsUaT6P+XdV2xPZaud4 P8ctGr1O5Coq9WuPVjrWD4ZDC1Zd1jObs1rjm+RJJ7V5JIT6pM1+V/F+7uVf0+yF+/rR1b4ovl3p iLfNK9ivFViBNN8uz/dbcO4yXnTnvJxrget16RVG6NuWyEkgUl3HIDHpAQ4MfatKXM3B7781ji7m f3dfrfdW8eiVnfISWDvtOSaCZS89oBAM9tmtia1S7CwrjZvauzsesfBb/DJtmHm80TB/WR8ui54c Yefi+KMWPWN4JhwdK25wxyzMMpLVvX0xs0fISclwFxs8/BNvXbwyCwxmSvgZicsQypsGM7PXGHHo N0cpNf+A3gdmStJgKhUgI9ZkRVZ+HuWAo4cux9Ec/+YdZwZ+aLdwajeAKDZ+5Bdmr6JlNsVOp1Es dFeAAWhmx3WA4VdWSmFNCtIc7nceVdY7XpJrh6aDzHQlyGRndtYWQLiDQ2gjeEaER4iESaiES8iE TeiETwiFhZaDVbJmiTaFhsJhrEVqjnaFoPZ8UQiGmvQvNQRs5yVP5wRyElMtKKdx+GJQJocSzZYt 3FRU5PRT2RSHPeVxB8CGx4Ysaigx9ZFwyfZ/C4VyEJNs+bcTZ7gc+PZAY8hL9NJsZ3iC8IYx7RSG maiF+BNBnBc8hpVCQGF3xDNXWqVQ/jRzkXJzRgdVqWj/FGS1WYBndbMoZf5UOFKHObBYc7Z4dblH i11HEAwyOc3DdK7YEnPXi3mlicvYJU3VibJ3W5oHgaEofdZXEtVVPmM3F+YVP743YACmKPj1eslV OXwHKaznTt2Feb24S7QHgenFb81EUocHjpVXP75Xfcyoj1RoYmSUgCRYgsA3RiuVbVYWd75Fg+r0 QYoiZHmRkHkYgiQEYg7GQrtmUUWEZUEEQ1SmgmWEYCNIQgxkZBF4QNPoFe8hRGLXLGjmYYPjQ/sI k05yhaqWTIxmhKh0k+ICZ5zkg0OSZjEJlEEplENJlEVplEeJlEmplEvJlE3plE8JlVEplVNJlVVp lVeJ/5VZqZVbyZVd6ZVfCZZhKZZjSZZlaZZniZZpqZZreSIxsRqpwid9MpNlMpdWJZO2dmocJJe+ 1JILN0uC1ygMmYWjRmm4xChrNimiRpjx4VK0FmuqlmlzVj2OyXY/AT8boIhmQpm3tJM8SCNBYAM4 QHl0OHAQdVIE54cGcZoLlZorYz50kYYBw3EJNYf/UZALJ1VuSFLHQlB5k3FClTAId4e46YtGwVG9 9ldTtG56aHHLZm2iEnAehx7vthXRBpEDhYcWKFXBKZsOqEVT9C4dc08eU0+pMp7NB5qi6T+0lHBg lpkL0gDepprpxIcTdy04lVKL6JAnNIhF5VD/Vp70Sf9MbqlQhYg277aaGMchtQhmf9gn84YjQIR3 lDUUjKOAdmVp+RlclbehZeGK/gONRFGKZiWLhaOLd8egnuUuZ1KIrPlYUrd2LxoZiYdg1Ch2FiqC vIeiVXOiRuFyCwiNwgR1XcWOTlZ0U6VRsChkmwF3YdERepOiiwOLm8N5xFM3qFNZkYGjsIWhmaWk RapfOtd4usQTuCdgBqaNsxN7yVlWKqk+rjd5VkpeinKN6wU+cdRAN6gTzpcnxakye/VYl9d68CWo QFdvNqo+BLZ7y9V7Wfg/9chAQbqZv8UDtNWkoDcTKYES4YiBhwWmy+QewUeMDlCpy1WlaWF45oOO i+n/jqlnpehBeJDapxFapnnkgky2ZRxWZh55Xgs4kl7FRl+mFv84Y6mXYbwhGxqaRuInQylGMnLZ mQ8gAbLCmjnVgfKYYPKnFF1EEWzEgBD2RRcISO+5rIKirMKapBepflBgkHzFHdfagG14GR01dRQ4 ISC5S/BaEQoCoNqam2oRZQXaYQrYHRxpc0e2fylpr2jKlknXsFuSk0AZsTdSlw9rsReLsRmrsRtL Z4opJbU0mKskaVXUaXh5Ih4rLkDjJ3x5Jlfxl8PamMInmKYmsiBLszqJrUZis2R6syhCdyyiSIuF s565mJAkb3hImoBxtLrJHAY6nwBmkZE2EPJSob4m/4cnsysYgoh1qGM3EW3TORWvhia8uXEFUU8W 528nVpt+ulH0GlWIEgDpKbPeWVJj6IjYFmROsbbZqq77ym4cF6CqYXKrQbU+ep3ZE5tKezMh+Wtp IVLhZFRJSzKcI4mouZ3ekmwH2p/dqREUsypZOx5pq2z0Jp1OoW8daSVV6oymOqKj9Scq96Nt1Vhi SnkqyothWpzbEyc/IVGyuD6GCmenmilBUVi2RJPEZKLhsj3wSFytOqtJ5VRRyolz+lS+K7std3Yv GH2wS7vu1LrJOFUomh3FeFo7irsZylm/83VZmBM66jvMVXtsiiWquzSuU6fW5VtsZ7i/+zaoQV/c OP8zDpSPrSW/bno+zOEq+UWjvTp2z/OYW0VWnQYURgGjyPeOcbR80vi6heqOolq/0JhfTUuP1sen orhfAAywupWNiro8cZSq+Tt7P6d6rae+q5MkAqwyrhON8HvB8oslxBqSZLhXNSGsxDMhX2Yf2lfE faQW+oqwEniJJmhELaEhtfEVCSkt8LeTQPyseMTACzKtteEFBmIixkak0wiSZDhitRRNCmYeFRlx /4jFL6HEEaa93Jd/2LeQHHOD06FkA3t3x1rH4epgnQrIFOlifYuRV7EBflSBixtiOgOKaUyXk0om l7SWQpiUE6uDmPwkmsyxoSzKo0zKpWzKPVijj7n/icfLs0Wrv91oyY8YsljYs7NWy3nZarFcJihr y5PZq3/ihb3cIsrUSAR6y3eZuMH1taYbiJG7iFyrh9nyTmO4ML9BcuxSuP8UU79pm3lrndN8ig2q gR8HzdU6ueY6RshWzk6rcfikncvmModLtvi0TReHuBKTLTH4Yox7tVALQ2frnxlHbAG9oOaHiaJr HHu7zXBxzTX4t4yIsGMbbM9UVHdLFLXR0IL70OUsNQm3mp9xiHJ7YHsHgbprPOB7LkjzoX63NJgj dQk0u0/Xow1cOnPB0rg7Wo16vuEbyXUVzkKDi+Wbo4zKcGqDnHZ5xozF0wD5vgtEdnLDvXkXKdAr /3vJm3QUWl9fejkz3b7Umxa5qLxMlb7lWDZajc4tLL83Xa+W91dJ/bZQMdOVTNIk+6awh6ar+4W/ ZW6xhT33SIH/i6aP6tV9asGxSsLfJ19yetYezNaOt5g6vL+8JF01tqa568BU2l8nDKmMKXnAy1+l WnZ6zSh7uqhAB6LWZ8FpynX8xYLLi8GvWtoE/LtxcqkwTCZqt8YHMcUGeMhBXMQ5FnHwUTDcOshU pGNqPJJJBFV6DGsXyIK9zato5MT+B92PPLqVWL2w9pC7eqwkWCP/lmHMfWOU8s/a6rfdt8fdikNr 3LXz4q81pxwy6DEpqMgkZr2r4yFQjEIzmJEi2Tms/X2JibwZL7lnVqjLinbKCT4loKzgDe7gDw7h ES7hE07hFW7hF47hGa7hG87hHe7hHw7iIf6UAQEAOw== --=_related 004F61648625755C_=-- From alexandru.petrescu@gmail.com Fri Feb 13 06:35:21 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 069753A6BE0; Fri, 13 Feb 2009 06:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8yGoz5lhZKj; Fri, 13 Feb 2009 06:35:20 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 0EB7C3A6BD9; Fri, 13 Feb 2009 06:35:19 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1DEZNem023408; Fri, 13 Feb 2009 15:35:23 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1DEZML6015071; Fri, 13 Feb 2009 15:35:22 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n1DEZLu3016127; Fri, 13 Feb 2009 15:35:22 +0100 Message-ID: <49958529.5010306@gmail.com> Date: Fri, 13 Feb 2009 15:35:21 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Jerald.P.Martocci@jci.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ROLL WG , "David E. Culler" , roll-bounces@ietf.org Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 14:35:21 -0000 Jerald - ok, PLC is important. It's related to routing and energy transportation. But. It doesn't sound as PLC devices having limited power, they sit on more power than they'd ever need. I this sense, I don't agree with the Charter saying: > Low power and Lossy networks (LLNs) are typically composed of many > embedded devices with limited power, memory, and processing resources > interconnected by a variety of links, such as [...] or other low > power PLC (Powerline Communication) links. What do you think? Alex From mischa.dohler@cttc.es Fri Feb 13 06:35:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B080828C16D for ; Fri, 13 Feb 2009 06:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GzDtUGROGPl for ; Fri, 13 Feb 2009 06:35:25 -0800 (PST) Received: from scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by core3.amsl.com (Postfix) with ESMTP id CE00C3A6C48 for ; Fri, 13 Feb 2009 06:35:24 -0800 (PST) Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by scorpius.cttc.es (8.13.8/8.13.5) with ESMTP id n1DEXq5E020010; Fri, 13 Feb 2009 15:33:52 +0100 Received: from [84.88.61.89] (pcmdohler.cttc.es [84.88.61.89]) by castor (Postfix) with ESMTP id 561F82FC26F; Fri, 13 Feb 2009 15:33:52 +0100 (CET) Message-ID: <4995839D.3050507@cttc.es> Date: Fri, 13 Feb 2009 15:28:45 +0100 From: Mischa Dohler User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: JP Vasseur References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> <49957091.5090101@gmail.com> <985801EB-0080-47C7-BAC0-B23FB6BCB403@cisco.com> <49957837.1000608@cttc.es> <8FA49B57-4046-461A-A0E7-D4DF21074099@cisco.com> In-Reply-To: <8FA49B57-4046-461A-A0E7-D4DF21074099@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Fri, 13 Feb 2009 15:33:52 +0100 (CET) X-Scanned-By: MIMEDefang 2.57 on 84.88.62.197 Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 14:35:26 -0000 I am happy with the charter, JP (also just having seen that there are a lot of PLC players listening into this list). Mischa. JP Vasseur wrote: > Hi Mischa, > > On Feb 13, 2009, at 2:40 PM, Mischa Dohler wrote: > >> I am not sure why PLC has popped up again? Whilst they are and >> certainly will be part of the embedded system's landscape, I remember >> that we decided to exclude it for a set of reasons: >> >> 1) Where is the real routing challenge if you can only route 'along' >> the power line? I guess there are small items to be solved but I don't >> see yet *the* grand challenge. >> > > it is just that LLNs can be made of both wireless and wired devices (PLC > and serial as pointed out by Jerry). Still constrained devices thus they > are part of ROLL's scope. This is very much true in Smart Grid automation. > >> 2) A company trying to use PLC told us that they could not get a >> reasonable signal beyond the meter, ie if you have sensors reporting >> in several flats, there is no way you can aggregate this data in a >> single node placed in the building and possibly acting as a gateway to >> other nets. I have had a look at the circuits diagram of typical >> meters and have not yet fully got around why the signal gets so >> heavily attenuated but this is what it does (at the moment). Anybody >> on this list with other practical experiences with PLC? > > There is plenty of excellent PLC technos. I'll send you pointers, just > trying to focus on the charter in this thread ;-) > > Thanks. > > JP. > >> >> >> Cheers, >> Mischa. >> >> >> >> >> JP Vasseur wrote: >>> Hi Alex, >>> On Feb 13, 2009, at 2:07 PM, Alexandru Petrescu wrote: >>>> JP Vasseur a écrit : >>>>> Dear WG, >>>>> As indicated in a previous email, the protocol survey I-D will be >>>>> send for publication this week (after posting of the last revision >>>>> incorporating several useful comments). >>>>> As promised please find below the new proposed charter to be >>>>> submitted to the IESG for approval. In the hope of getting quickly >>>>> re-chartered thanks to let us know if you have any comment by the >>>>> ned of this week. The new charter is pretty straightforward. >>>>> Thanks to Dave Ward for his comments and guidance. >>>>> Description of Working Group: >>>>> Low power and Lossy networks (LLNs) are typically composed of many >>>>> embedded devices with limited power, memory, and processing resources >>>>> interconnected by a variety of links, such as IEEE 802.15.4, >>>>> Bluetooth, >>>>> Low Power WiFi or other low power PLC (Powerline Communication) links. >>>> >>>> Sorry, low power PLC sounds contradictory to me... low power and >>>> powerline... >>>> >>>> I think the PLC devices are powered by the line itself. Where does >>>> the low-power characteristic come from? >>>> >>> Although they are main powered they can consume more of less power >>> (thus the term low power). >>> You can find PLC chipset that consumes a few dozen of Mw. In our >>> context we are referring to >>> these PLC type technologies that opposed to other PLC technologies >>> that are in the Watt range. >>> Thanks. >>> JP. >>>> Or is that low-power radio? (short range, small dBm). >>>> >>>> Alex >>>> >>>>> 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. LLNs >>>>> have specific characteristics: >>>>> - LLNs operate with a hard, very small bound on state, >>>>> - In most cases, LLN need to be optimized for energy saving, >>>>> - Typical traffic patterns are not simply unicast flows, >>>>> - In most cases, LLNs need to be effective with very small >>>>> packet sizes, >>>>> - LLN routing protocols have to be very careful when trading >>>>> off efficiency for generality; many LLN nodes do not have resources >>>>> to waste. >>>>> These unique properties lead to unique routing requirements that >>>>> may not met by >>>>> existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For >>>>> example path selection must be designed to take into consideration the >>>>> specific power capabilities, attributes and functional characteristics >>>>> of the links and nodes in the network. >>>>> 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 home, healthcare, environmental monitoring, >>>>> urban sensor networks sensor networks, assets tracking, refrigeration. >>>>> The Working Group will only focus on routing solutions for a subset of >>>>> these. It will focus on industrial, connected home, building and urban >>>>> sensor networks and specify the set of routing requirements for >>>>> these scenarios. >>>>> The Working Group focuses only on IPv6 only 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 explore aspects of mobility within a single LLN >>>>> (if any) in the routing requirement creation. >>>>> The Working Group will pay particular attention to routing security >>>>> and >>>>> manageability (e.g., self 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. >>>>> 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 protocols 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: In light of the application specific routing >>>>> requirements, the Working Group will either specify a new protocol >>>>> and/or will select an existing routing protocol (with the >>>>> appropriate extensions in cooperation with the relevant Working >>>>> Group). >>>>> - Documentation of applicability statement of ROLL routing protocols. >>>>> Goals and Milestones: >>>>> Done Submit Routing requirements for Industrial applications to >>>>> the IESG to be considered as an Informational RFC. >>>>> Done Submit Routing requirements for Connected Home networks >>>>> applications to the IESG to be considered as an Informational RFC. >>>>> Done Submit Routing requirements for Building applications to the >>>>> IESG to be considered as an Informational RFC. >>>>> Done Submit Routing requirements for Urban networks applications >>>>> to the IESG to be considered as an Informational RFC. >>>>> July 2009 Submit Routing metrics for LLNs document to the IESG >>>>> to be considered as a Proposed Standard. >>>>> * Feb 2009 Submit Protocol Survey to the IESG to be considered as >>>>> an Informational RFC. >>>>> April 2009 Submit Security Framework to the IESG to be considered >>>>> as an Informational RFC >>>>> May 2009 Submit the Routing for LLNs Architecture document to >>>>> the IESG as an Informational RFC. >>>>> July 2009 Submit first draft of ROLL routing protocol >>>>> specification as Proposed Standard. >>>>> Nov 2009 Submit first draft of the MIB module of the ROLL >>>>> routing protocol specification. >>>>> Dec 2009 Submit the ROLL routing protocol specification to the >>>>> IESG as Proposed Standard. >>>>> Jan 2010 Submit the MIB module of the ROLL routing protocol >>>>> specification to the IESG as Proposed Standard. >>>>> Jan 2010 Evaluate WG progress, recharter or close. >>>>> PS: I marked * the Milestones that will be "This Week" and before >>>>> submitting to the IESG for re-chartering. >>>>> Thanks. >>>>> JP and David. >>>>> _______________________________________________ >>>>> 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 > From jvasseur@cisco.com Fri Feb 13 06:40:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5352F3A6CE7; Fri, 13 Feb 2009 06:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUKi2R+UOIWZ; Fri, 13 Feb 2009 06:40:17 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D872428C258; Fri, 13 Feb 2009 06:40:16 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,202,1233532800"; d="scan'208";a="33735445" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 13 Feb 2009 14:40:22 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1DEeMA5029806; Fri, 13 Feb 2009 15:40:22 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1DEeM9f029326; Fri, 13 Feb 2009 14:40:22 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Feb 2009 15:40:22 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Feb 2009 15:40:21 +0100 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <49958529.5010306@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 13 Feb 2009 15:40:20 +0100 References: <49958529.5010306@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 13 Feb 2009 14:40:21.0690 (UTC) FILETIME=[FF98C1A0:01C98DE8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1064; t=1234536022; x=1235400022; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20re-chartering |Sender:=20; bh=M5nkYQpENlLMbsIyZRFNAZburKeP4MMSKzyl1t1cfNU=; b=bW04Er0LUjDooEOm2erwzMxPTkoF+Za2KFN9fUl87x3t5Sm2n4tlg3aiSX LrwUOQL0EXnL5uGYUhFGKKJ9g7XcXgOjWdAmCZ3V3rn3ozKvrjb92knJVzYK pjXjJsIiic; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG , roll-bounces@ietf.org, "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 14:40:18 -0000 On Feb 13, 2009, at 3:35 PM, Alexandru Petrescu wrote: > Jerald - ok, PLC is important. It's related to routing and energy > transportation. > > But. It doesn't sound as PLC devices having limited power, they sit > on more power than they'd ever need. As I tried to explain before, still you want these device to consume as less energy as possible (e.g few dozens of mW) thus there are constrained. If you have a house and want to do energy management you could not afford to have all these device consume 3W each. Thanks. JP. > > > I this sense, I don't agree with the Charter saying: >> Low power and Lossy networks (LLNs) are typically composed of many >> embedded devices with limited power, memory, and processing resources >> interconnected by a variety of links, such as [...] or other low >> power PLC (Powerline Communication) links. > > What do you think? > > Alex > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From Jerald.P.Martocci@jci.com Fri Feb 13 06:48:00 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76FE228C16A; Fri, 13 Feb 2009 06:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.461 X-Spam-Level: X-Spam-Status: No, score=-5.461 tagged_above=-999 required=5 tests=[AWL=1.137, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-+KAPaLk71q; Fri, 13 Feb 2009 06:47:59 -0800 (PST) Received: from exprod8og109.obsmtp.com (exprod8og109.obsmtp.com [64.18.3.98]) by core3.amsl.com (Postfix) with ESMTP id 7173528C17E; Fri, 13 Feb 2009 06:47:58 -0800 (PST) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob109.postini.com ([64.18.7.12]) with SMTP ID DSNKSZWIIHbkTjNksiPyj0aWaevdp7qSmlnS@postini.com; Fri, 13 Feb 2009 06:48:06 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009021308482889-1036597 ; Fri, 13 Feb 2009 08:48:28 -0600 In-Reply-To: <49958529.5010306@gmail.com> MIME-Version: 1.0 To: Alexandru Petrescu X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Fri, 13 Feb 2009 08:47:47 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 02/13/2009 08:47:52 AM, Serialize complete at 02/13/2009 08:47:52 AM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 02/13/2009 08:48:28 AM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 02/13/2009 08:48:41 AM, Serialize complete at 02/13/2009 08:48:41 AM Content-Type: multipart/alternative; boundary="=_alternative 005147F88625755C_=" Cc: roll-bounces@ietf.org, ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 14:48:00 -0000 This is a multipart message in MIME format. --=_alternative 005147F88625755C_= Content-Type: text/plain; charset="US-ASCII" I think you're putting too much emphasis on the 'low-power' aspect of ROLL. Just because the routing algorithms must support low-power devices (i.e. sleeping nodes, battery power, energy harvested) doesn't mean the network is composed only of those devices. In the commercial building market, the only layer that will be truly 'low power' will be the sensors. As soon as the sensor data hits the next layer (e.g. room controller) this will always be a powered device. Why? Because its main task will be to modulate the airflow into the building spaces. The damper used to modulate the air will always need a powered actuator to open/close the actuator. The point I am trying to make is that LLNs will be composed of a network of devices that must seamlessly interact regardless of power source. Jerry Alexandru Petrescu 02/13/2009 08:35 AM To Jerald.P.Martocci@jci.com cc Mischa Dohler , ROLL WG , roll-bounces@ietf.org, "David E. Culler" Subject Re: [Roll] ROLL re-chartering Jerald - ok, PLC is important. It's related to routing and energy transportation. But. It doesn't sound as PLC devices having limited power, they sit on more power than they'd ever need. I this sense, I don't agree with the Charter saying: > Low power and Lossy networks (LLNs) are typically composed of many > embedded devices with limited power, memory, and processing resources > interconnected by a variety of links, such as [...] or other low > power PLC (Powerline Communication) links. What do you think? Alex --=_alternative 005147F88625755C_= Content-Type: text/html; charset="US-ASCII"
I think you're putting too much emphasis on the 'low-power' aspect of ROLL.  Just because the routing algorithms must support low-power devices (i.e. sleeping nodes, battery power, energy harvested) doesn't mean the network is composed only of those devices.  In the commercial building market, the only layer that will be truly 'low power' will be the sensors.  As soon as the sensor data hits the next layer (e.g. room controller) this will always be a powered device.  Why?  Because its main task will be to modulate the airflow into the building spaces.  The damper used to modulate the air will always need a powered actuator to open/close the actuator.

The point I am trying to make is that LLNs will be composed of a network of devices that must seamlessly interact regardless of power source.

Jerry




Alexandru Petrescu <alexandru.petrescu@gmail.com>

02/13/2009 08:35 AM

To
Jerald.P.Martocci@jci.com
cc
Mischa Dohler <mischa.dohler@cttc.es>, ROLL WG <roll@ietf.org>, roll-bounces@ietf.org, "David E. Culler" <culler@eecs.berkeley.edu>
Subject
Re: [Roll] ROLL re-chartering





Jerald - ok, PLC is important.  It's related to routing and energy
transportation.

But.  It doesn't sound as PLC devices having limited power, they sit on
more power than they'd ever need.

I this sense, I don't agree with the Charter saying:
> Low power and Lossy networks (LLNs) are typically composed of many
> embedded devices with limited power, memory, and processing resources
>  interconnected by a variety of links, such as [...] or other low
> power PLC (Powerline Communication) links.

What do you think?

Alex
--=_alternative 005147F88625755C_=-- From anand@ekasystems.com Fri Feb 13 06:54:19 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB5AF3A6B3A for ; Fri, 13 Feb 2009 06:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id By5sw-msqMEj for ; Fri, 13 Feb 2009 06:54:19 -0800 (PST) Received: from smtp108.biz.mail.re2.yahoo.com (smtp108.biz.mail.re2.yahoo.com [206.190.52.47]) by core3.amsl.com (Postfix) with SMTP id BFBD83A6A86 for ; Fri, 13 Feb 2009 06:54:18 -0800 (PST) Received: (qmail 75039 invoked from network); 13 Feb 2009 14:54:25 -0000 Received: from unknown (HELO ?192.168.0.207?) (anand@209.48.242.66 with plain) by smtp108.biz.mail.re2.yahoo.com with SMTP; 13 Feb 2009 14:54:24 -0000 X-YMail-OSG: rQpzzWMVM1nPrRN71TUhQgv4Ox7gU2uLTiidns4aAUq09YyaKwD.nYaGdrYYJsv1d9cF3uKa6MCfYI7F.lKRr3TGF5OfMnnwFzb07veJ5jnL0SEdMPNNa0xqjF_Vzo9FFvA7vtacseiynFvjf9sFWDvi X-Yahoo-Newman-Property: ymail-3 Message-ID: <49958B65.2040805@ekasystems.com> Date: Fri, 13 Feb 2009 10:01:57 -0500 From: "M. B. Anand" User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Mischa Dohler References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> <49957091.5090101@gmail.com> <985801EB-0080-47C7-BAC0-B23FB6BCB403@cisco.com> <49957837.1000608@cttc.es> In-Reply-To: <49957837.1000608@cttc.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 14:54:19 -0000 Mischa, > > > 2) A company trying to use PLC told us that they could not get a > reasonable signal beyond the meter, ie if you have sensors reporting > in several flats, there is no way you can aggregate this data in a > single node placed in the building and possibly acting as a gateway to > other nets. I have had a look at the circuits diagram of typical > meters and have not yet fully got around why the signal gets so > heavily attenuated but this is what it does (at the moment). Anybody > on this list with other practical experiences with PLC? > In general, that is not the case. They don't go through the *transformer* very well, so most implementations aggregate at the transformer and jump to some other medium. There are both broadband and medium-band flavors that do that. In Europe (and in other parts of the world), the number of premises on a transformer tends to be more than in the US, so it is actually quite a popular technology there for AMR and well-proven. There are several large implementations and several in progress or under consideration. There are also narrowband flavors - I mean really narrowband, like 60bps - that do punch through the transformer and these, at least in the US, are well-suited and quite well-proven in very rural environments where really nothing else suits the purpose. Regards, Anand. From lars.eggert@nokia.com Fri Feb 13 06:58:25 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4C2D3A6B7E; Fri, 13 Feb 2009 06:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DB1mVFlocBuO; Fri, 13 Feb 2009 06:58:25 -0800 (PST) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 277E73A6B74; Fri, 13 Feb 2009 06:58:23 -0800 (PST) Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n1DEv2fZ061356 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 Feb 2009 16:57:03 +0200 (EET) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: JP Vasseur In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-22-679268690; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 13 Feb 2009 16:57:02 +0200 References: <49958529.5010306@gmail.com> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Fri, 13 Feb 2009 16:57:03 +0200 (EET) X-Virus-Scanned: ClamAV 0.94.2/8987/Fri Feb 13 12:32:33 2009 on fit.nokia.com X-Virus-Status: Clean Cc: "roll-bounces@ietf.org" , ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 14:58:25 -0000 --Apple-Mail-22-679268690 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2009-2-13, at 16:40, JP Vasseur wrote: > On Feb 13, 2009, at 3:35 PM, Alexandru Petrescu wrote: >> Jerald - ok, PLC is important. It's related to routing and energy >> transportation. >> >> But. It doesn't sound as PLC devices having limited power, they sit >> on more power than they'd ever need. > > As I tried to explain before, still you want these device to consume > as less energy as possible (e.g few dozens of mW) > thus there are constrained. If you have a house and want to do energy > management you could not afford to have all > these device consume 3W each. I get the part about still wanting to have very low power consumption in PLC scenarios, but ROLL is currently chartered to look at routing for low-powered *and lossy* networks. It's not immediately clear to me that a PLC solution would need all the complexities that ROLL routing will likely need to have to deal with losses. Given that we don't yet know what the low-powered+lossy routing scheme will look like, it seems a bit premature to also make it work for PLCs. Lars --Apple-Mail-22-679268690 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTAyMTMxNDU3MDNaMCMGCSqGSIb3DQEJBDEWBBQsp9/jcWT9xXaf rpxXqZx2jFv25TCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAZL3kawYdvi3ioyhw7NnMTm2ymX7n5bj40r/iGYj0CNWTrEQq8Uo5 JL06Dm1NiKaM4FtfJe+IE7GE0Bfq3SU1EdaoCXpp4twQtFxeJT4Z3VFDHMOWX/KYuiIeTIyflauN tzrkNF3welaCwUZICRAzzQc6iA3WV2J/+DhAQFdj/n6s91IZkhvsv7xLmMSoFo7LrH91Sako0Ftb aC4TaEA/rgLLtgRAomyQgrL5QzHJ3F2OFEP6RUkFRn087ooBAaF58+CDt5rGryy/n7Kjn0dCxLFX +0kNioML3691KFL2hf8dwLLJNXPdk8cvgakSjMyqSsXJkGBCXh4H/8CMD7oXKQAAAAAAAA== --Apple-Mail-22-679268690-- From jvasseur@cisco.com Fri Feb 13 07:05:32 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9374F3A6B0A; Fri, 13 Feb 2009 07:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqXZgKNFXu7I; Fri, 13 Feb 2009 07:05:31 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 031C73A67E2; Fri, 13 Feb 2009 07:05:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,202,1233532800"; d="scan'208";a="33739249" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 13 Feb 2009 15:05:36 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1DF5axB006699; Fri, 13 Feb 2009 16:05:36 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1DF5aSD009352; Fri, 13 Feb 2009 15:05:36 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Feb 2009 16:05:36 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Feb 2009 16:05:35 +0100 Message-Id: <89BA3B32-421E-4A24-B075-B5518E78FD35@cisco.com> From: JP Vasseur To: Lars Eggert In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 13 Feb 2009 16:05:34 +0100 References: <49958529.5010306@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 13 Feb 2009 15:05:35.0637 (UTC) FILETIME=[85FABC50:01C98DEC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1664; t=1234537536; x=1235401536; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20re-chartering |Sender:=20; bh=BM64NJktYjO5ePv74M4YoSoEoDlmqql6w1LbFkGy9nA=; b=EC0V63OTm1E9V6JW76kMMWSNLCTSzn5Yh80I1Y8c961YJ952xjlmWfkftb cXWAIN4tS8GPOGrHWau9w4Q/FBeKUb5ktriJjMsjjonVtBtf4e2Tvi5W7+iW kvaePjTXxT; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "roll-bounces@ietf.org" , ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 15:05:32 -0000 Hi Lars, On Feb 13, 2009, at 3:57 PM, Lars Eggert wrote: > Hi, > > On 2009-2-13, at 16:40, JP Vasseur wrote: >> On Feb 13, 2009, at 3:35 PM, Alexandru Petrescu wrote: >>> Jerald - ok, PLC is important. It's related to routing and energy >>> transportation. >>> >>> But. It doesn't sound as PLC devices having limited power, they sit >>> on more power than they'd ever need. >> >> As I tried to explain before, still you want these device to consume >> as less energy as possible (e.g few dozens of mW) >> thus there are constrained. If you have a house and want to do energy >> management you could not afford to have all >> these device consume 3W each. > > I get the part about still wanting to have very low power > consumption in PLC scenarios, but ROLL is currently chartered to > look at routing for low-powered *and lossy* networks. > Well these low power PLC technologies and also loosy. > It's not immediately clear to me that a PLC solution would need all > the complexities that ROLL routing will likely need to have to deal > with losses. It does not introduce anything new, just clarify that these networks are made of wireless and wired links, which have been in our scope from the beginning. > Given that we don't yet know what the low-powered+lossy routing > scheme will look like, it seems a bit premature to also make it work > for PLCs. > This actually does not introduce any more complexity. The idea is to not exclude PLC technologies, which have been mentioned in several use- cases of the requirement document. Does that help clarifying ? Thanks. JP. > Lars From alexandru.petrescu@gmail.com Fri Feb 13 07:11:16 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A4283A6D38; Fri, 13 Feb 2009 07:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJvN3svyCC2M; Fri, 13 Feb 2009 07:11:15 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 0FC0B3A6CE0; Fri, 13 Feb 2009 07:11:14 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1DF9ZvE004922; Fri, 13 Feb 2009 16:09:35 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1DFBFCW011076; Fri, 13 Feb 2009 16:11:15 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n1DFBEwf029757; Fri, 13 Feb 2009 16:11:14 +0100 Message-ID: <49958D92.5040503@gmail.com> Date: Fri, 13 Feb 2009 16:11:14 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: JP Vasseur References: <49958529.5010306@gmail.com> <89BA3B32-421E-4A24-B075-B5518E78FD35@cisco.com> In-Reply-To: <89BA3B32-421E-4A24-B075-B5518E78FD35@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "roll-bounces@ietf.org" , "David E. Culler" , ROLL WG Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 15:11:16 -0000 JP Vasseur a écrit : > Hi Lars, > > On Feb 13, 2009, at 3:57 PM, Lars Eggert wrote: > >> Hi, >> >> On 2009-2-13, at 16:40, JP Vasseur wrote: >>> On Feb 13, 2009, at 3:35 PM, Alexandru Petrescu wrote: >>>> Jerald - ok, PLC is important. It's related to routing and energy >>>> transportation. >>>> >>>> But. It doesn't sound as PLC devices having limited power, they sit >>>> on more power than they'd ever need. >>> >>> As I tried to explain before, still you want these device to consume >>> as less energy as possible (e.g few dozens of mW) >>> thus there are constrained. If you have a house and want to do energy >>> management you could not afford to have all >>> these device consume 3W each. >> >> I get the part about still wanting to have very low power consumption >> in PLC scenarios, but ROLL is currently chartered to look at routing >> for low-powered *and lossy* networks. >> > > Well these low power PLC technologies and also loosy. Well it's obvious wired communications aren't as lossy as wireless communications. Alex > >> It's not immediately clear to me that a PLC solution would need all >> the complexities that ROLL routing will likely need to have to deal >> with losses. > > It does not introduce anything new, just clarify that these networks are > made of wireless and wired links, which have been in our scope from the > beginning. > >> Given that we don't yet know what the low-powered+lossy routing scheme >> will look like, it seems a bit premature to also make it work for PLCs. >> > > This actually does not introduce any more complexity. The idea is to not > exclude PLC technologies, which have been mentioned in several use-cases > of the requirement document. > > Does that help clarifying ? > > Thanks. > > JP. > >> Lars > > From Daniel.Smolinski@renesas.com Fri Feb 13 07:19:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 429093A6914; Fri, 13 Feb 2009 07:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqArwgahZ3DS; Fri, 13 Feb 2009 07:19:17 -0800 (PST) Received: from mail04.idc.renesas.com (mail.renesas.com [202.234.163.13]) by core3.amsl.com (Postfix) with ESMTP id 3AD163A67F7; Fri, 13 Feb 2009 07:19:16 -0800 (PST) X-AuditID: ac140387-00000005000005fd-0b-49958f7320e7 Received: from guardian03.idc.renesas.com ([172.20.8.202]) by mail04.idc.renesas.com (sendmail) with ESMTP id n1DFJFYm026118; Sat, 14 Feb 2009 00:19:15 +0900 (JST) Received: (from root@localhost) by guardian03.idc.renesas.com with id n1DFJFbi020092; Sat, 14 Feb 2009 00:19:15 +0900 (JST) Received: from mta03.idc.renesas.com (localhost [127.0.0.1]) by mta03.idc.renesas.com with ESMTP id n1DFJFbg022151; Sat, 14 Feb 2009 00:19:15 +0900 (JST) Received: from rte-rat-exch.RTE.ADWIN.RENESAS.COM ([172.28.128.38]) by rte-idc-bh1.RTE.ADWIN.RENESAS.COM with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Feb 2009 15:19:16 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 13 Feb 2009 16:19:10 +0100 Message-ID: <7BDC023EB136F0499F260228BE2991BC2C23D8@rte-rat-exch.RTE.ADWIN.RENESAS.COM> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] ROLL re-chartering Thread-Index: AcmN7RVDVBA1EnQqTkuwhjHuDK6FWwAAMgsA References: <49958529.5010306@gmail.com> From: "Daniel Smolinski" To: "Lars Eggert" , "JP Vasseur" X-OriginalArrivalTime: 13 Feb 2009 15:19:16.0324 (UTC) FILETIME=[6F25A240:01C98DEE] X-Brightmail-Tracker: AAAAAA== Cc: roll-bounces@ietf.org, ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 15:19:18 -0000 Hi all, Actually, from in the field experience, PLC can be quite a lossy communication technology. We have seen many cases where influence from appliances (e.g. microwave ovens) can cause disturbances on the power = line that makes communication impossible for some time. Also, many PLC links = are asymmetrical. While I agree that the low-power requirement can be seen either way, my experience tells me that PLC is definitely experiencing the same = problems as do wireless networks. Regards, Daniel -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Lars Eggert Sent: Freitag, 13. Februar 2009 15:57 To: JP Vasseur Cc: roll-bounces@ietf.org; ROLL WG; David E. Culler Subject: Re: [Roll] ROLL re-chartering Hi, On 2009-2-13, at 16:40, JP Vasseur wrote: > On Feb 13, 2009, at 3:35 PM, Alexandru Petrescu wrote: >> Jerald - ok, PLC is important. It's related to routing and energy >> transportation. >> >> But. It doesn't sound as PLC devices having limited power, they sit >> on more power than they'd ever need. > > As I tried to explain before, still you want these device to consume > as less energy as possible (e.g few dozens of mW) > thus there are constrained. If you have a house and want to do energy > management you could not afford to have all > these device consume 3W each. I get the part about still wanting to have very low power consumption =20 in PLC scenarios, but ROLL is currently chartered to look at routing =20 for low-powered *and lossy* networks. It's not immediately clear to me that a PLC solution would need all =20 the complexities that ROLL routing will likely need to have to deal =20 with losses. Given that we don't yet know what the low-powered+lossy =20 routing scheme will look like, it seems a bit premature to also make =20 it work for PLCs. Lars From alexandru.petrescu@gmail.com Fri Feb 13 07:24:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE38B28C238; Fri, 13 Feb 2009 07:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIDl0s+0LZZ7; Fri, 13 Feb 2009 07:24:49 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id D523E28B23E; Fri, 13 Feb 2009 07:24:48 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1DFOfTB024606; Fri, 13 Feb 2009 16:24:41 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1DFOd7h002083; Fri, 13 Feb 2009 16:24:40 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n1DFOcvb002356; Fri, 13 Feb 2009 16:24:39 +0100 Message-ID: <499590B6.3000305@gmail.com> Date: Fri, 13 Feb 2009 16:24:38 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: JP Vasseur References: <49958529.5010306@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG , roll-bounces@ietf.org, "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 15:24:49 -0000 JP Vasseur a écrit : > > On Feb 13, 2009, at 3:35 PM, Alexandru Petrescu wrote: > >> Jerald - ok, PLC is important. It's related to routing and energy >> transportation. >> >> But. It doesn't sound as PLC devices having limited power, they >> sit on more power than they'd ever need. > > As I tried to explain before, still you want these device to consume > as less energy as possible (e.g few dozens of mW) thus there are > constrained. If you have a house and want to do energy management you > could not afford to have all these device consume 3W each. The problem here is _not_ to reduce the energy consumption in house. It is to have routing work on small naturally-low-power devices - if that is achieved at the cost of 3W consumption by high-power devices then so be it. It's difficult to embark on solving energy consumption at all possible levels. Alex From anand@ekasystems.com Fri Feb 13 07:32:11 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B931828C161 for ; Fri, 13 Feb 2009 07:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vr2nU6Bfty47 for ; Fri, 13 Feb 2009 07:32:10 -0800 (PST) Received: from smtp108.biz.mail.re2.yahoo.com (smtp108.biz.mail.re2.yahoo.com [206.190.52.47]) by core3.amsl.com (Postfix) with SMTP id 4F7EE3A6869 for ; Fri, 13 Feb 2009 07:32:10 -0800 (PST) Received: (qmail 1131 invoked from network); 13 Feb 2009 15:32:16 -0000 Received: from unknown (HELO ?192.168.0.207?) (anand@209.48.242.66 with plain) by smtp108.biz.mail.re2.yahoo.com with SMTP; 13 Feb 2009 15:32:15 -0000 X-YMail-OSG: 2HqHuoQVM1mFsV9E350qRQtT.OiYQ4EGInkV5olppOoTAmFpIyQLAs1ZmemgeCMfLXvXX.852ZZWMEtYyU5cYnAnLV6yaWZgkWJc1hbY5pKaZcjRK34xarOQwADZOQ_SEwRfgWemN5pAAAE.Ab2dHo91Hxl36xYiilhdovc.i3hTPJgWXjDIV2TDMyC_l7FzUXbqIstP238dI8rfheHtgDxc3tPT X-Yahoo-Newman-Property: ymail-3 Message-ID: <4995943C.30404@ekasystems.com> Date: Fri, 13 Feb 2009 10:39:40 -0500 From: "M. B. Anand" User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: JP Vasseur References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> In-Reply-To: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 15:32:11 -0000 JP, The charter looks good to me. I would be OK with it as-is, but just a couple of very minor comments that don't affect the main substance: 1. In the paragraph on applications, that says: "There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (HVAC, lighting, access control, fire), connected home, healthcare, environmental monitoring, urban sensor networks sensor networks, assets tracking, refrigeration." may I suggest a small addition: "......environmental monitoring, urban sensor networks (eg. Smart Grid), ......." Obviously, I am biased :-), but given that it is a big driver application, perhaps it would be useful to mention it by name. 2. "Refrigeration" ? Really ? Everything else on the list evokes a clear image and resonates, but I find I need to work hard to imagine the refrigeration application area. Thanks, Best regards, Anand. > Dear WG, > > As indicated in a previous email, the protocol survey I-D will be send > for publication this week (after posting of the last revision > incorporating several useful comments). > > As promised please find below the new proposed charter to be submitted > to the IESG for approval. In the hope of getting quickly re-chartered > thanks to let us know if you have any comment by the ned of this week. > The new charter is pretty straightforward. > > Thanks to Dave Ward for his comments and guidance. > > Description of Working Group: > > Low power and Lossy networks (LLNs) are typically composed of many > embedded devices with limited power, memory, and processing resources > interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, > Low Power WiFi 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. LLNs have > specific characteristics: > - LLNs operate with a hard, very small bound on state, > - In most cases, LLN need to be optimized for energy saving, > - Typical traffic patterns are not simply unicast flows, > - In most cases, LLNs need to be effective with very small > packet sizes, > - LLN routing protocols have to be very careful when trading off > efficiency for generality; many LLN nodes do not have resources to waste. > > These unique properties lead to unique routing requirements that may > not met by > existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For > example path selection must be designed to take into consideration the > specific power capabilities, attributes and functional characteristics > of the links and nodes in the network. > > > > 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 home, healthcare, environmental monitoring, > urban sensor networks sensor networks, assets tracking, refrigeration. > The Working Group will only focus on routing solutions for a subset of > these. It will focus on industrial, connected home, building and urban > sensor networks and specify the set of routing requirements for > these scenarios. > > The Working Group focuses only on IPv6 only 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 explore aspects of mobility within a single LLN > (if any) in the routing requirement creation. > > The Working Group will pay particular attention to routing security and > manageability (e.g., self 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. > > > 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 protocols 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: In light of the application specific routing > requirements, the Working Group will either specify a new protocol > and/or will select an existing routing protocol (with the appropriate > extensions in cooperation with the relevant Working Group). > > - Documentation of applicability statement of ROLL routing protocols. > > Goals and Milestones: > > Done Submit Routing requirements for Industrial applications to the > IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Connected Home networks > applications to the IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Building applications to the > IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Urban networks applications to > the IESG to be considered as an Informational RFC. > July 2009 Submit Routing metrics for LLNs document to the IESG to > be considered as a Proposed Standard. > * Feb 2009 Submit Protocol Survey to the IESG to be considered as an > Informational RFC. > April 2009 Submit Security Framework to the IESG to be considered as > an Informational RFC > May 2009 Submit the Routing for LLNs Architecture document to the > IESG as an Informational RFC. > July 2009 Submit first draft of ROLL routing protocol specification > as Proposed Standard. > Nov 2009 Submit first draft of the MIB module of the ROLL routing > protocol specification. > Dec 2009 Submit the ROLL routing protocol specification to the > IESG as Proposed Standard. > Jan 2010 Submit the MIB module of the ROLL routing protocol > specification to the IESG as Proposed Standard. > Jan 2010 Evaluate WG progress, recharter or close. > > PS: I marked * the Milestones that will be "This Week" and before > submitting to the IESG for re-chartering. > > > > Thanks. > > JP and David. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From jvasseur@cisco.com Fri Feb 13 07:47:58 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDA4D28C254; Fri, 13 Feb 2009 07:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwWYAG1Dyz+n; Fri, 13 Feb 2009 07:47:58 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7AE2528C1D5; Fri, 13 Feb 2009 07:47:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,202,1233532800"; d="scan'208";a="33745226" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 13 Feb 2009 15:47:47 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1DFllPN002473; Fri, 13 Feb 2009 16:47:47 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1DFllsw024862; Fri, 13 Feb 2009 15:47:47 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Feb 2009 16:47:47 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Feb 2009 16:47:46 +0100 Message-Id: <8157AC22-684F-4FA9-8240-AA481A404F22@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <49958D92.5040503@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 13 Feb 2009 16:47:45 +0100 References: <49958529.5010306@gmail.com> <89BA3B32-421E-4A24-B075-B5518E78FD35@cisco.com> <49958D92.5040503@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 13 Feb 2009 15:47:46.0759 (UTC) FILETIME=[6AA54D70:01C98DF2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2083; t=1234540067; x=1235404067; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20re-chartering |Sender:=20; bh=5S+JSCOpuuQwI/wwKN0SMBRHUNeJmp5aaAryzVkoz6s=; b=dKVFz7snkzylJwDPDW5qSjFAFmX7jCxxk42D2wWMdnzMrCd15xFu6F7e6s NKN9e4fPFyt9mb8DGuT7k8m96ypAEHekU2MJuUm7f0mZYmwJ7FO81M1sePJ/ QHS0EySERQ; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG , "David E. Culler" , "roll-bounces@ietf.org" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 15:47:59 -0000 On Feb 13, 2009, at 4:11 PM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> Hi Lars, >> On Feb 13, 2009, at 3:57 PM, Lars Eggert wrote: >>> Hi, >>> >>> On 2009-2-13, at 16:40, JP Vasseur wrote: >>>> On Feb 13, 2009, at 3:35 PM, Alexandru Petrescu wrote: >>>>> Jerald - ok, PLC is important. It's related to routing and energy >>>>> transportation. >>>>> >>>>> But. It doesn't sound as PLC devices having limited power, they =20= >>>>> sit >>>>> on more power than they'd ever need. >>>> >>>> As I tried to explain before, still you want these device to =20 >>>> consume >>>> as less energy as possible (e.g few dozens of mW) >>>> thus there are constrained. If you have a house and want to do =20 >>>> energy >>>> management you could not afford to have all >>>> these device consume 3W each. >>> >>> I get the part about still wanting to have very low power =20 >>> consumption in PLC scenarios, but ROLL is currently chartered to =20 >>> look at routing for low-powered *and lossy* networks. >>> >> Well these low power PLC technologies and also loosy. > > Well it's obvious wired communications aren't as lossy as wireless =20 > communications. > do not think so ... I could provide you many pointers if you will. Thanks. JP. > Alex > >>> It's not immediately clear to me that a PLC solution would need =20 >>> all the complexities that ROLL routing will likely need to have to =20= >>> deal with losses. >> It does not introduce anything new, just clarify that these =20 >> networks are made of wireless and wired links, which have been in =20 >> our scope from the beginning. >>> Given that we don't yet know what the low-powered+lossy routing =20 >>> scheme will look like, it seems a bit premature to also make it =20 >>> work for PLCs. >>> >> This actually does not introduce any more complexity. The idea is =20 >> to not exclude PLC technologies, which have been mentioned in =20 >> several use-cases of the requirement document. >> Does that help clarifying ? >> Thanks. >> JP. >>> Lars > > From jvasseur@cisco.com Fri Feb 13 07:50:34 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B207D28C116; Fri, 13 Feb 2009 07:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uz2WrlhJ7abZ; Fri, 13 Feb 2009 07:50:33 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A742C3A67FA; Fri, 13 Feb 2009 07:50:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,202,1233532800"; d="scan'208";a="33745651" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 13 Feb 2009 15:50:38 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1DFocxg022328; Fri, 13 Feb 2009 16:50:38 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1DFocuM025849; Fri, 13 Feb 2009 15:50:38 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Feb 2009 16:50:38 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Feb 2009 16:50:37 +0100 Message-Id: <467AA005-8C2F-4505-8279-56179B7CAF85@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <499590B6.3000305@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 13 Feb 2009 16:50:35 +0100 References: <49958529.5010306@gmail.com> <499590B6.3000305@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 13 Feb 2009 15:50:37.0570 (UTC) FILETIME=[D074FE20:01C98DF2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1230; t=1234540238; x=1235404238; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20PLC=20discussion |Sender:=20; bh=XqzUSJ6xZN0NA9Vrh4OJimEyvIfR3Bou1vQSSIXSQik=; b=fqbLneUKTmUGD0KYdcXBv/mQ1CREXOBITUY6IYcLjAv9+03cHCTfzp5fGL metgUmvrB0QCC//VoffewtQrjGIC3RrzPugRwGYWjODiD4W56GrJ5cQoawGU WwlM+oZqpm; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG , roll-bounces@ietf.org, "David E. Culler" Subject: [Roll] PLC discussion X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 15:50:34 -0000 changing the title ... since this is not about the charter On Feb 13, 2009, at 4:24 PM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> On Feb 13, 2009, at 3:35 PM, Alexandru Petrescu wrote: >>> Jerald - ok, PLC is important. It's related to routing and energy >>> transportation. >>> But. It doesn't sound as PLC devices having limited power, they =20 >>> sit on more power than they'd ever need. >> As I tried to explain before, still you want these device to consume >> as less energy as possible (e.g few dozens of mW) thus there are =20 >> constrained. If you have a house and want to do energy management you >> could not afford to have all these device consume 3W each. > > The problem here is _not_ to reduce the energy consumption in house. Yes it is ... look at smart grid operation (DR, DSM, ...) > > > It is to have routing work on small naturally-low-power devices - Right and because we have constraints on energy consumption you end up =20= with constrained devices. > if that is achieved at the cost of 3W consumption by high-power =20 > devices then so be it. > > It's difficult to embark on solving energy consumption at all =20 > possible levels. > > Alex > > From jvasseur@cisco.com Fri Feb 13 07:52:58 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3023128C25A for ; Fri, 13 Feb 2009 07:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snlpPd028-K8 for ; Fri, 13 Feb 2009 07:52:56 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2635B28C257 for ; Fri, 13 Feb 2009 07:52:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,202,1233532800"; d="scan'208";a="33745989" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 13 Feb 2009 15:53:01 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1DFr115004392; Fri, 13 Feb 2009 16:53:01 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1DFr1Sr026766; Fri, 13 Feb 2009 15:53:01 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Feb 2009 16:53:01 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Feb 2009 16:53:00 +0100 Message-Id: <325B2B0B-B036-453F-87F6-17A9F54EAE44@cisco.com> From: JP Vasseur To: "M. B. Anand" In-Reply-To: <4995943C.30404@ekasystems.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 13 Feb 2009 16:52:59 +0100 References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> <4995943C.30404@ekasystems.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 13 Feb 2009 15:53:00.0517 (UTC) FILETIME=[25A8F950:01C98DF3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8093; t=1234540381; x=1235404381; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20re-chartering |Sender:=20; bh=1EoGWNvIAuhA3JzuFeCWM8FO6Q/Ri9DZSsK7sjJuMIc=; b=AHu36Oij1KLwdXlLQt207m00swF1cW8KT0p/BdotvrhB2etq9GVYiwHRAS QCZSZE1HaHDQaUiNzSiHpFX9IvtAoofvkmnOH67eT0aBK5yxszFz7KB4AvVI YiSyW24iJY; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 15:52:58 -0000 Hi Anand, On Feb 13, 2009, at 4:39 PM, M. B. Anand wrote: > JP, > The charter looks good to me. > > I would be OK with it as-is, but just a couple of very minor > comments that don't affect the main substance: > > 1. In the paragraph on applications, that says: > "There is a wide scope of application areas for LLNs, including > industrial monitoring, building automation (HVAC, lighting, access > control, fire), connected home, healthcare, environmental > monitoring, urban sensor networks sensor networks, assets tracking, > refrigeration." > > may I suggest a small addition: > "......environmental monitoring, urban sensor networks (eg. Smart > Grid), ......." > Good catch, thanks. > Obviously, I am biased :-), but given that it is a big driver > application, perhaps it would be useful to mention it by name. > Yes. > 2. "Refrigeration" ? Really ? Everything else on the list evokes a > clear image and resonates, but I find I need to work hard to imagine > the refrigeration application area. > This is a bit funny ... I never "noticed" that we had "refrigeration" in there ;-) Will delete it. Thanks. JP. > Thanks, > > Best regards, > Anand. > > >> Dear WG, >> >> As indicated in a previous email, the protocol survey I-D will be >> send for publication this week (after posting of the last revision >> incorporating several useful comments). >> >> As promised please find below the new proposed charter to be >> submitted to the IESG for approval. In the hope of getting quickly >> re-chartered thanks to let us know if you have any comment by the >> ned of this week. The new charter is pretty straightforward. >> >> Thanks to Dave Ward for his comments and guidance. >> >> Description of Working Group: >> >> Low power and Lossy networks (LLNs) are typically composed of many >> embedded devices with limited power, memory, and processing resources >> interconnected by a variety of links, such as IEEE 802.15.4, >> Bluetooth, >> Low Power WiFi 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. LLNs >> have specific characteristics: >> - LLNs operate with a hard, very small bound on state, >> - In most cases, LLN need to be optimized for energy saving, >> - Typical traffic patterns are not simply unicast flows, >> - In most cases, LLNs need to be effective with very small >> packet sizes, >> - LLN routing protocols have to be very careful when trading >> off efficiency for generality; many LLN nodes do not have resources >> to waste. >> >> These unique properties lead to unique routing requirements that >> may not met by >> existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For >> example path selection must be designed to take into consideration >> the >> specific power capabilities, attributes and functional >> characteristics >> of the links and nodes in the network. >> >> >> >> 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 home, healthcare, environmental monitoring, >> urban sensor networks sensor networks, assets tracking, >> refrigeration. >> The Working Group will only focus on routing solutions for a subset >> of >> these. It will focus on industrial, connected home, building and >> urban >> sensor networks and specify the set of routing requirements for >> these scenarios. >> >> The Working Group focuses only on IPv6 only 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 explore aspects of mobility within a single >> LLN >> (if any) in the routing requirement creation. >> >> The Working Group will pay particular attention to routing security >> and >> manageability (e.g., self 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. >> >> >> 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 protocols 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: In light of the application specific routing >> requirements, the Working Group will either specify a new protocol >> and/or will select an existing routing protocol (with the >> appropriate extensions in cooperation with the relevant Working >> Group). >> >> - Documentation of applicability statement of ROLL routing protocols. >> >> Goals and Milestones: >> >> Done Submit Routing requirements for Industrial applications to >> the IESG to be considered as an Informational RFC. >> Done Submit Routing requirements for Connected Home networks >> applications to the IESG to be considered as an Informational RFC. >> Done Submit Routing requirements for Building applications to the >> IESG to be considered as an Informational RFC. >> Done Submit Routing requirements for Urban networks applications >> to the IESG to be considered as an Informational RFC. >> July 2009 Submit Routing metrics for LLNs document to the IESG >> to be considered as a Proposed Standard. >> * Feb 2009 Submit Protocol Survey to the IESG to be considered as >> an Informational RFC. >> April 2009 Submit Security Framework to the IESG to be considered >> as an Informational RFC >> May 2009 Submit the Routing for LLNs Architecture document to >> the IESG as an Informational RFC. >> July 2009 Submit first draft of ROLL routing protocol >> specification as Proposed Standard. >> Nov 2009 Submit first draft of the MIB module of the ROLL >> routing protocol specification. >> Dec 2009 Submit the ROLL routing protocol specification to the >> IESG as Proposed Standard. >> Jan 2010 Submit the MIB module of the ROLL routing protocol >> specification to the IESG as Proposed Standard. >> Jan 2010 Evaluate WG progress, recharter or close. >> >> PS: I marked * the Milestones that will be "This Week" and before >> submitting to the IESG for re-chartering. >> >> >> >> Thanks. >> >> JP and David. >> _______________________________________________ >> 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 From chris.dearlove@baesystems.com Fri Feb 13 08:04:07 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 116273A6D38 for ; Fri, 13 Feb 2009 08:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HFENSpUQ85e for ; Fri, 13 Feb 2009 08:04:06 -0800 (PST) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id 1CA3A3A6D12 for ; Fri, 13 Feb 2009 08:04:05 -0800 (PST) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n1DG4AhF010957 for ; Fri, 13 Feb 2009 16:04:10 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n1DG4AD0020448 for ; Fri, 13 Feb 2009 16:04:10 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Fri, 13 Feb 2009 16:03:56 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Fri, 13 Feb 2009 16:04:10 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 13 Feb 2009 16:04:08 -0000 Message-ID: In-Reply-To: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] ROLL re-chartering Thread-Index: AcmMH+Nh6qv/bpyyQtu3IEJFip6GTwB04YBA References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> From: "Dearlove, Christopher (UK)" To: "JP Vasseur" , "ROLL WG" X-OriginalArrivalTime: 13 Feb 2009 16:04:10.0316 (UTC) FILETIME=[B4E430C0:01C98DF4] Cc: "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 16:04:07 -0000 I need to find the time to look more carefully at all the proposed charter. For the moment, just one thing jumps out at me. > These unique properties lead to unique routing requirements I would rather say that these specific properties lead to specific routing requirements. For a start, ROLL's requirements are based on four cases. These aren't all of the cases that could have been considered, others of which have very similar requirement (in fact they may hope to use ROLL's solutions). In addition, what ROLL is doing is not unique in the sense of no one else wants anything at all like it, but rather that in the possible space of constraints on routing solutions, ROLL occupies a particular area. But there's continuity between what ROLL wants and what some other people may want, it's not of totally alien nature. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From jvasseur@cisco.com Fri Feb 13 08:08:12 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D21B228C24B for ; Fri, 13 Feb 2009 08:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpfZmU8XGhiA for ; Fri, 13 Feb 2009 08:08:12 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7FEAE28C228 for ; Fri, 13 Feb 2009 08:08:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,202,1233532800"; d="scan'208";a="33747876" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 13 Feb 2009 16:08:17 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1DG8HXd009169; Fri, 13 Feb 2009 17:08:17 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1DG8GlP001711; Fri, 13 Feb 2009 16:08:17 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Feb 2009 17:08:16 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Feb 2009 17:08:15 +0100 Message-Id: From: JP Vasseur To: "Dearlove, Christopher (UK)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 13 Feb 2009 17:08:14 +0100 References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 13 Feb 2009 16:08:15.0714 (UTC) FILETIME=[4728F420:01C98DF5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1535; t=1234541297; x=1235405297; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20re-chartering |Sender:=20; bh=cFoLK/GjQP1NAZufpee8WVnWo9CeQh1NjYdwcAZKL5g=; b=TIn9qGGl9khSKM4/lWvKBIL7EJUFXfP6Fb4g2Gns98OhyLoj1qiThnpyl5 I5IDjgb/o4nZLRkJVaixv+uf68lTqq3AtAcREmVruBH/KQF/VIWCFNBUW+KQ bXM8HAhAaG; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 16:08:12 -0000 On Feb 13, 2009, at 5:04 PM, Dearlove, Christopher (UK) wrote: > > I need to find the time to look more carefully at all the > proposed charter. For the moment, just one thing jumps out > at me. > >> These unique properties lead to unique routing requirements > > I would rather say that these specific properties lead to specific > routing requirements. > This is fine. > For a start, ROLL's requirements are based on four cases. These > aren't all of the cases that could have been considered, others > of which have very similar requirement (in fact they may hope > to use ROLL's solutions). In addition, what ROLL is doing is > not unique in the sense of no one else wants anything at all > like it, but rather that in the possible space of constraints > on routing solutions, ROLL occupies a particular area. But > there's continuity between what ROLL wants and what some other > people may want, it's not of totally alien nature. > Again this is fine, I'll change the wording for "specific" Thanks for the comment. JP. > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > From pthubert@cisco.com Fri Feb 13 08:48:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63D923A6D45 for ; Fri, 13 Feb 2009 08:48:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+LtGs2TvZ2n for ; Fri, 13 Feb 2009 08:48:42 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 66DC53A6C10 for ; Fri, 13 Feb 2009 08:48:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,203,1233532800"; d="scan'208";a="33752427" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 13 Feb 2009 16:48:41 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1DGmflx020525; Fri, 13 Feb 2009 17:48:41 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1DGmapn013337; Fri, 13 Feb 2009 16:48:41 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Feb 2009 17:48:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Feb 2009 17:48:27 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC06F777B0@xmb-ams-337.emea.cisco.com> In-Reply-To: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] ROLL re-chartering Thread-Index: AcmMH+HSppMHNl/ASoi768NCIIrr4wB1wUqg References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> From: "Pascal Thubert (pthubert)" To: "JP Vasseur (jvasseur)" , "ROLL WG" X-OriginalArrivalTime: 13 Feb 2009 16:48:36.0432 (UTC) FILETIME=[EA053500:01C98DFA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8404; t=1234543721; x=1235407721; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20ROLL=20re-chartering |Sender:=20; bh=qv8a1EtjLRcv8Btuq3zv265WqOabsDGpNCqqy7TMqxA=; b=sxW9ikptVOpj+ilJS9x4mHLo5iaek0yW95xosIpslOICTOR58Pv3ji8Aib RIdtZMLRWjJO2OQoDrHZuNEmUs0mfgU3t5wl1h7bgOjt5sUotM82SyMMXuUl OiNdW1g+E6; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 16:48:43 -0000 Hi JP and Dave: I agree that autonomicity (self-*) is a key to scalability and = deploy-ability, which are required in that space even more than for = larger devices. We've heard too much buzz that L3 is too complex to = deploy for simple applications such as sensor networks and = backbone/backhaul, leaving the way for L2 solution. I also agree that the centralized vs. distributed discussion is still = very open and that's a good point to note in the charter. Maybe we'll = end up with one of each and for all I know, there's no reason to bar = either at this point. And I agree that the concept of metric must be revisited. We'll have to = cope with statistical information that cannot be properly abstracted by = a simple number. We've heard too many times L2 mesh network protocols = guys dismissing L3 because L3 would not be 'close enough' to the link = issues to route properly. Certainly we'll have to define abstractions = that enable a better visibility and accuracy from L3. In the contextual information, I would have liked some emphasis on the = fact that the routing should enable multipath to let packets slalom in = the midst of interference and sleeping nodes. Also a little chat on the = effects of density or the capability for the nodes to either change role = or reduce their environmental impact upon density could have been good. Nevertheless the work items themselves seem perfect to me. So the bottom = line is that I do agree with this charter; the time line seems as = constrained as the devices themselves but the people on the WG have = shown an incredible degree of aggregated experience so I do hope and = trust that we'll make it if we can find our own route past the = interferences :) Thanks a lot for all this work, Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = JP Vasseur (jvasseur) >Sent: mercredi 11 f=E9vrier 2009 09:08 >To: ROLL WG >Cc: David E. Culler >Subject: [Roll] ROLL re-chartering > >Dear WG, > >As indicated in a previous email, the protocol survey I-D will be send >for publication this week (after posting of the last revision >incorporating several useful comments). > >As promised please find below the new proposed charter to be submitted >to the IESG for approval. In the hope of getting quickly re-chartered >thanks to let us know if you have any comment by the ned of this week. >The new charter is pretty straightforward. > >Thanks to Dave Ward for his comments and guidance. > >Description of Working Group: > >Low power and Lossy networks (LLNs) are typically composed of many >embedded devices with limited power, memory, and processing resources >interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, >Low Power WiFi 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. LLNs have >specific characteristics: >- LLNs operate with a hard, very small bound on state, >- In most cases, LLN need to be optimized for energy saving, >- Typical traffic patterns are not simply unicast flows, >- In most cases, LLNs need to be effective with very small >packet sizes, >- LLN routing protocols have to be very careful when trading off >efficiency for generality; many LLN nodes do not have resources to >waste. > >These unique properties lead to unique routing requirements that may >not met by > existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For >example path selection must be designed to take into consideration the >specific power capabilities, attributes and functional characteristics >of the links and nodes in the network. > > > >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 home, healthcare, environmental monitoring, >urban sensor networks sensor networks, assets tracking, refrigeration. >The Working Group will only focus on routing solutions for a subset of >these. It will focus on industrial, connected home, building and urban > sensor networks and specify the set of routing requirements for > these scenarios. > >The Working Group focuses only on IPv6 only 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 explore aspects of mobility within a single LLN >(if any) in the routing requirement creation. > >The Working Group will pay particular attention to routing security and >manageability (e.g., self 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. > > >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 protocols 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: In light of the application specific routing >requirements, the Working Group will either specify a new protocol and/ >or will select an existing routing protocol (with the appropriate >extensions in cooperation with the relevant Working Group). > >- Documentation of applicability statement of ROLL routing protocols. > >Goals and Milestones: > >Done Submit Routing requirements for Industrial applications to the >IESG to be considered as an Informational RFC. >Done Submit Routing requirements for Connected Home networks >applications to the IESG to be considered as an Informational RFC. >Done Submit Routing requirements for Building applications to the >IESG to be considered as an Informational RFC. >Done Submit Routing requirements for Urban networks applications to >the IESG to be considered as an Informational RFC. >July 2009 Submit Routing metrics for LLNs document to the IESG to >be considered as a Proposed Standard. >* Feb 2009 Submit Protocol Survey to the IESG to be considered as an >Informational RFC. >April 2009 Submit Security Framework to the IESG to be considered as >an Informational RFC >May 2009 Submit the Routing for LLNs Architecture document to the >IESG as an Informational RFC. >July 2009 Submit first draft of ROLL routing protocol specification >as Proposed Standard. >Nov 2009 Submit first draft of the MIB module of the ROLL routing >protocol specification. >Dec 2009 Submit the ROLL routing protocol specification to the >IESG as Proposed Standard. >Jan 2010 Submit the MIB module of the ROLL routing protocol >specification to the IESG as Proposed Standard. >Jan 2010 Evaluate WG progress, recharter or close. > >PS: I marked * the Milestones that will be "This Week" and before >submitting to the IESG for re-chartering. > > > >Thanks. > >JP and David. >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Fri Feb 13 08:51:44 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9DC93A6810 for ; Fri, 13 Feb 2009 08:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHRQS8a-rTQU for ; Fri, 13 Feb 2009 08:51:43 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 910613A67F7 for ; Fri, 13 Feb 2009 08:51:42 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,203,1233532800"; d="scan'208";a="33752811" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 13 Feb 2009 16:51:48 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1DGpm2L008169; Fri, 13 Feb 2009 17:51:48 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1DGpmdf014607; Fri, 13 Feb 2009 16:51:48 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Feb 2009 17:51:48 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Feb 2009 17:51:47 +0100 Message-Id: <3D805B3F-4087-4DDC-9577-5F9A68D7ADA4@cisco.com> From: JP Vasseur To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC06F777B0@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 13 Feb 2009 17:51:46 +0100 References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC06F777B0@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 13 Feb 2009 16:51:47.0433 (UTC) FILETIME=[5BDDA590:01C98DFB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9197; t=1234543908; x=1235407908; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20re-chartering |Sender:=20; bh=Ccp4cJzvrcVC2sHu6w6MWXPdHuxKsezI2vivYsu6dfk=; b=LG+BJHHd7Gr6atqSHoc8gv81v69Z+NPkcyjlJmVGcPQvEFBLHqqjYnYS2r HjuPZDa5Ek0wFPA9wTqdNGgUCXg5GYAXwA6okbNI6MQE+LYF15MVlpPMOnKq XpLQ7AowI3; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 16:51:44 -0000 On Feb 13, 2009, at 5:48 PM, Pascal Thubert (pthubert) wrote: > Hi JP and Dave: > > I agree that autonomicity (self-*) is a key to scalability and =20 > deploy-ability, which are required in that space even more than for =20= > larger devices. We've heard too much buzz that L3 is too complex to =20= > deploy for simple applications such as sensor networks and backbone/=20= > backhaul, leaving the way for L2 solution. > > I also agree that the centralized vs. distributed discussion is =20 > still very open and that's a good point to note in the charter. =20 > Maybe we'll end up with one of each and for all I know, there's no =20 > reason to bar either at this point. > > And I agree that the concept of metric must be revisited. We'll have =20= > to cope with statistical information that cannot be properly =20 > abstracted by a simple number. We've heard too many times L2 mesh =20 > network protocols guys dismissing L3 because L3 would not be 'close =20= > enough' to the link issues to route properly. Certainly we'll have =20 > to define abstractions that enable a better visibility and accuracy =20= > from L3. > > In the contextual information, I would have liked some emphasis on =20 > the fact that the routing should enable multipath to let packets =20 > slalom in the midst of interference and sleeping nodes. Also a =20 > little chat on the effects of density or the capability for the =20 > nodes to either change role or reduce their environmental impact =20 > upon density could have been good. > > Nevertheless the work items themselves seem perfect to me. So the =20 > bottom line is that I do agree with this charter; the time line =20 > seems as constrained as the devices themselves but the people on the =20= > WG have shown an incredible degree of aggregated experience so I do =20= > hope and trust that we'll make it if we can find our own route past =20= > the interferences :) > > Thanks a lot for all this work, > You are most welcome. Thanks for the feed-back. We are all looking =20 forward to the next step. Thanks. JP. > Pascal > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =20 >> Behalf Of JP Vasseur (jvasseur) >> Sent: mercredi 11 f=E9vrier 2009 09:08 >> To: ROLL WG >> Cc: David E. Culler >> Subject: [Roll] ROLL re-chartering >> >> Dear WG, >> >> As indicated in a previous email, the protocol survey I-D will be =20 >> send >> for publication this week (after posting of the last revision >> incorporating several useful comments). >> >> As promised please find below the new proposed charter to be =20 >> submitted >> to the IESG for approval. In the hope of getting quickly re-chartered >> thanks to let us know if you have any comment by the ned of this =20 >> week. >> The new charter is pretty straightforward. >> >> Thanks to Dave Ward for his comments and guidance. >> >> Description of Working Group: >> >> Low power and Lossy networks (LLNs) are typically composed of many >> embedded devices with limited power, memory, and processing resources >> interconnected by a variety of links, such as IEEE 802.15.4, =20 >> Bluetooth, >> Low Power WiFi or other low power PLC (Powerline Communication) =20 >> 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. LLNs =20 >> have >> specific characteristics: >> - LLNs operate with a hard, very small bound on state, >> - In most cases, LLN need to be optimized for energy saving, >> - Typical traffic patterns are not simply unicast flows, >> - In most cases, LLNs need to be effective with very small >> packet sizes, >> - LLN routing protocols have to be very careful when trading =20= >> off >> efficiency for generality; many LLN nodes do not have resources to >> waste. >> >> These unique properties lead to unique routing requirements that may >> not met by >> existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For >> example path selection must be designed to take into consideration =20= >> the >> specific power capabilities, attributes and functional =20 >> characteristics >> of the links and nodes in the network. >> >> >> >> 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 home, healthcare, environmental monitoring, >> urban sensor networks sensor networks, assets tracking, =20 >> refrigeration. >> The Working Group will only focus on routing solutions for a subset =20= >> of >> these. It will focus on industrial, connected home, building and =20 >> urban >> sensor networks and specify the set of routing requirements for >> these scenarios. >> >> The Working Group focuses only on IPv6 only 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 explore aspects of mobility within a single =20= >> LLN >> (if any) in the routing requirement creation. >> >> The Working Group will pay particular attention to routing security =20= >> and >> manageability (e.g., self 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 =20= >> 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 =20 >> mechanisms. >> >> >> Work Items: >> >> - Specification of routing metrics used in path calculation. This >> includes static and dynamic link/node attributes required for =20 >> routing in >> LLNs. >> >> >> >> - Provide an architectural framework for routing and path selection =20= >> at >> Layer 3 (Routing for LLN Architecture) that addresses such issues as >> whether LLN routing protocols require a distributed and/or =20 >> centralized >> path computation models, whether additional hierarchy is necessary =20= >> and >> how it is applied. Manageability will be considered with each =20 >> 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: In light of the application specific routing >> requirements, the Working Group will either specify a new protocol =20= >> and/ >> or will select an existing routing protocol (with the appropriate >> extensions in cooperation with the relevant Working Group). >> >> - Documentation of applicability statement of ROLL routing protocols. >> >> Goals and Milestones: >> >> Done Submit Routing requirements for Industrial applications to the >> IESG to be considered as an Informational RFC. >> Done Submit Routing requirements for Connected Home networks >> applications to the IESG to be considered as an Informational RFC. >> Done Submit Routing requirements for Building applications to the >> IESG to be considered as an Informational RFC. >> Done Submit Routing requirements for Urban networks applications to >> the IESG to be considered as an Informational RFC. >> July 2009 Submit Routing metrics for LLNs document to the IESG to >> be considered as a Proposed Standard. >> * Feb 2009 Submit Protocol Survey to the IESG to be considered as =20= >> an >> Informational RFC. >> April 2009 Submit Security Framework to the IESG to be considered =20= >> as >> an Informational RFC >> May 2009 Submit the Routing for LLNs Architecture document to the >> IESG as an Informational RFC. >> July 2009 Submit first draft of ROLL routing protocol =20 >> specification >> as Proposed Standard. >> Nov 2009 Submit first draft of the MIB module of the ROLL routing >> protocol specification. >> Dec 2009 Submit the ROLL routing protocol specification to the >> IESG as Proposed Standard. >> Jan 2010 Submit the MIB module of the ROLL routing protocol >> specification to the IESG as Proposed Standard. >> Jan 2010 Evaluate WG progress, recharter or close. >> >> PS: I marked * the Milestones that will be "This Week" and before >> submitting to the IESG for re-chartering. >> >> >> >> Thanks. >> >> JP and David. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Sat Feb 14 00:49:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 490BA3A69F7 for ; Sat, 14 Feb 2009 00:49:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRc9fRo1Af6e for ; Sat, 14 Feb 2009 00:49:46 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 24B1C3A6921 for ; Sat, 14 Feb 2009 00:49:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,205,1233532800"; d="scan'208,217";a="33783987" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 Feb 2009 08:49:52 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1E8nqhi029425 for ; Sat, 14 Feb 2009 09:49:52 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1E8nqTu011863 for ; Sat, 14 Feb 2009 08:49:52 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Feb 2009 09:49:52 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Feb 2009 09:49:51 +0100 Message-Id: From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-10-743637446 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 14 Feb 2009 09:49:51 +0100 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 14 Feb 2009 08:49:51.0930 (UTC) FILETIME=[334BC9A0:01C98E81] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2836; t=1234601392; x=1235465392; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Preliminary=20Agenda |Sender:=20; bh=rhhiH9SCkFSaDQSJhxktuuFXEF7KBsVjZozXPNcf/6U=; b=gQzeuG5C0we1PthwL4pUBEEzwR2gAv6GZLjuNpzaNEv/C0hFimhZ/Z3tND pasUR8ZPDXsIa3QJVtkufkubQROkFv7LDHxRQZR7RzM/GF47vUwm8AmhcR3u Qnil0lfvFQ; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Roll] Preliminary Agenda X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 08:49:47 -0000 --Apple-Mail-10-743637446 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit The preliminary agenda shows MONDAY, March 23, 2009 1740-1940 Afternoon Session III roll Routing Over Low power and Lossy networks WG --Apple-Mail-10-743637446 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable The preliminary agenda = shows

MONDAY, March 23, = 2009 

1740-1940 Afternoon = Session III

=
rollRouting Over Low power and = Lossy networks = WG

= --Apple-Mail-10-743637446-- From jvasseur@cisco.com Sat Feb 14 01:11:08 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C59D3A6AF3 for ; Sat, 14 Feb 2009 01:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCybHfNCy3I3 for ; Sat, 14 Feb 2009 01:11:07 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D4D2D3A6AF0 for ; Sat, 14 Feb 2009 01:11:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,205,1233532800"; d="scan'208,217";a="33784746" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 14 Feb 2009 09:11:14 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1E9BEJT019499 for ; Sat, 14 Feb 2009 10:11:14 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1E9BElT014638 for ; Sat, 14 Feb 2009 09:11:14 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Feb 2009 10:11:13 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Feb 2009 10:11:13 +0100 Message-Id: <42DF210A-E9C5-484B-9FC6-FF3F8D2565FD@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-13-744918676 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 14 Feb 2009 10:11:12 +0100 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 14 Feb 2009 09:11:13.0435 (UTC) FILETIME=[2F21EEB0:01C98E84] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6914; t=1234602674; x=1235466674; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Important=20meeting=20Dates=20for=20IETF-73 |Sender:=20; bh=2x0jDfvz/n6r5eyKGaCP2TRU2pPFrQCBbP5WHgR5vwg=; b=AgJj6jXZFrgyLlaURGrAeWgZUUV5Nv0m1T0QWV3pBkHZBPdv1MQAgiX0Ud FSp3lgiG4gLdV3qe3AzTrf8+d0XcXNdrhVBI+ymR/e78f9Vkpo5S67h+yCFc /387hX+7ef; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [Roll] Important meeting Dates for IETF-73 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 09:11:08 -0000 --Apple-Mail-13-744918676 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Please note that these dates are subject to change. December 15, 2008 (Week of) - IETF Online Registration is now open. December 22, 2008 Monday - Working Group and BOF scheduling begins. To request a Working Group session, use the IETF Meeting Session Request Tool. January 19, 2009 Monday (Extended to January 21, 2009) - Cutoff date for requests to schedule Working Group meetings and for preliminary BOF proposals to ADs at 17:00 PST (01:00 Tuesday, January 20 UTC/GMT). To request a Working Group session, use the IETF Meeting Session Request Tool. February 2, 2009 Monday - Cutoff date for requests to Area Directors to schedule BOFs at 17:00 PST (01:00 Tuesday, February 3 UTC/GMT). To request a BOF, please see instructions on Requesting a BOF. February 9, 2009 Monday - Cutoff date for Area Directors to approve BOF requests at 17:00 PST (01:00 Tuesday, February 10 UTC/GMT). February 13, 2009 Friday - Preliminary agenda published for comment. February 23, 2009 Monday - Working Group Chair approval for initial document (Version -00) submissions appreciated by 17:00 PST (01:00 Tuesday, February 24 UTC/GMT). February 25, 2009 Wednesday - Cutoff date for requests to reschedule Working Group and BOF meetings 17:00 PST (01:00 Thursday, February 26 UTC/GMT). March 2, 2009 Monday - Final agenda to be published. March 2, 2009 Monday - Internet Draft Cut-off for initial document (-00) submission by 17:00 PST (01:00 Tuesday, March 3 UTC/GMT), upload using IETF ID Submission Tool. March 9, 2009 Monday - Internet Draft final submission cut-off by 17:00 PDT (24:00 UTC/GMT), upload using IETF ID Submission Tool. March 11, 2009 Wednesday - Draft Working Group agendas due by 17:00 PDT (24:00 UTC/GMT), upload using IETF Meeting Materials Management Tool. March 13, 2009 Friday - Early-Bird registration and payment cut-off at 17:00 PDT (24:00 UTC/GMT). March 16, 2009 Monday - Revised Working Group agendas due by 17:00 PDT (24:00 UTC/GMT), upload using IETF Meeting Materials Management Tool. March 16, 2009 Monday - Registration cancellation cut-off at 17:00 PDT (24:00 UTC/GMT). March 20, 2009 Friday - Final Pre-Registration and Pre-Payment cut-off at 17:00 PDT (24:00 UTC/GMT). March 22-27, 2009 - 74th IETF Meeting in San Francisco, CA, USA April 24, 2009 Friday - Proceedings submission cutoff date by 17:00 PDT (24:00 UTC/GMT), upload using IETF Meeting Materials Management Tool. May 13, 2009, Wednesday - Proceedings submission corrections cutoff date by 17:00 PDT (24:00 UTC/GMT), upload using IETF Meeting Materials Management Tool. **** Times are in US Pacific Time and UTC/GMT **** --Apple-Mail-13-744918676 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

Please note that = these dates are subject to change.

December 15, 2008 (Week = of) - IETF Online = Registration is now open.
December 22, 2008 Monday - Working = Group and BOF scheduling begins. To request a Working Group session, use = the = IETF Meeting Session Request Tool.
January 19, 2009 Monday = (Extended to January 21, 2009) - Cutoff date for requests to schedule = Working Group meetings and for preliminary BOF proposals to ADs at 17:00 = PST (01:00 Tuesday, January 20 UTC/GMT). To request a Working Group = session, use the = IETF Meeting Session Request Tool.
February 2, 2009 Monday - = Cutoff date for requests to Area Directors to schedule BOFs at 17:00 PST = (01:00 Tuesday, February 3 UTC/GMT). To request a BOF, please see = instructions on Requesting a = BOF.
February 9, 2009 Monday - Cutoff date for Area Directors to = approve BOF requests at 17:00 PST (01:00 Tuesday, February 10 = UTC/GMT).
February 13, 2009 Friday - Preliminary agenda published for = comment.
February 23, 2009 Monday - Working Group Chair approval for = initial document (Version -00) submissions appreciated by 17:00 PST = (01:00 Tuesday, February 24 UTC/GMT).
February 25, 2009 Wednesday - = Cutoff date for requests to reschedule Working Group and BOF meetings = 17:00 PST (01:00 Thursday, February 26 UTC/GMT).
March 2, 2009 Monday = - Final agenda to be published.
March 2, 2009 Monday - Internet = Draft Cut-off for initial document (-00) submission by 17:00 PST (01:00 = Tuesday, March 3 UTC/GMT), upload using IETF ID = Submission Tool.
March 9, 2009 Monday - Internet = Draft final submission cut-off by 17:00 PDT (24:00 UTC/GMT), upload = using IETF ID = Submission Tool.
March 11, 2009 Wednesday - Draft = Working Group agendas due by 17:00 PDT (24:00 UTC/GMT), upload = using IETF = Meeting Materials Management Tool.
March 13, 2009 Friday = - Early-Bird&nb= sp;registration and payment cut-off at 17:00 PDT (24:00 = UTC/GMT).
March 16, 2009 Monday - Revised Working Group agendas due = by 17:00 PDT (24:00 UTC/GMT), upload using IETF = Meeting Materials Management Tool.
March 16, 2009 Monday - = Registration cancellation cut-off at 17:00 PDT (24:00 UTC/GMT).
March = 20, 2009 Friday - Final Pre-Registration and Pre-Payment cut-off at = 17:00 PDT (24:00 UTC/GMT).
March 22-27, 2009 - 74th IETF Meeting in = San Francisco, CA, USA
April 24, 2009 Friday - Proceedings submission = cutoff date by 17:00 PDT (24:00 UTC/GMT), upload using IETF = Meeting Materials Management Tool.
May 13, 2009, Wednesday - = Proceedings submission corrections cutoff date by 17:00 PDT (24:00 = UTC/GMT), upload using IETF = Meeting Materials Management Tool.

**** Times are in US = Pacific Time and UTC/GMT ****

= --Apple-Mail-13-744918676-- From pal@cs.stanford.edu Sat Feb 14 02:21:58 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0C913A6B78; Sat, 14 Feb 2009 02:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3ZrEQBtbAAo; Sat, 14 Feb 2009 02:21:58 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 27C113A69F7; Sat, 14 Feb 2009 02:21:55 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1LYHer-0000x1-Uo; Sat, 14 Feb 2009 02:22:02 -0800 Message-Id: <81A825C6-463E-40FA-9D4A-DEBB413C7F00@cs.stanford.edu> From: Philip Levis To: Alexandru Petrescu In-Reply-To: <499590B6.3000305@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 13 Feb 2009 22:04:17 -0800 References: <49958529.5010306@gmail.com> <499590B6.3000305@gmail.com> X-Mailer: Apple Mail (2.930.3) X-Scan-Signature: 078eb853d78558c6c655f7b6c94b391a Cc: ROLL WG , roll-bounces@ietf.org, "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 10:21:59 -0000 On Feb 13, 2009, at 7:24 AM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> On Feb 13, 2009, at 3:35 PM, Alexandru Petrescu wrote: >>> Jerald - ok, PLC is important. It's related to routing and energy >>> transportation. >>> But. It doesn't sound as PLC devices having limited power, they =20 >>> sit on more power than they'd ever need. >> As I tried to explain before, still you want these device to consume >> as less energy as possible (e.g few dozens of mW) thus there are =20 >> constrained. If you have a house and want to do energy management you >> could not afford to have all these device consume 3W each. > > The problem here is _not_ to reduce the energy consumption in house. > > It is to have routing work on small naturally-low-power devices - if =20= > that is achieved at the cost of 3W consumption by high-power devices =20= > then so be it. > > It's difficult to embark on solving energy consumption at all =20 > possible levels. > > Alex Alex, Please listen to what the domain experts (e.g., Jerald) say, rather =20 than make blanket statements based on no experience in the domain. I =20 think it's safe to say that everyone here is very interested in =20 constructive advice, comments, and even debate, but contradicting =20 basic assumptions with no background knowledge hardly meets those =20 criteria. Phil= From alexandru.petrescu@gmail.com Sat Feb 14 10:06:01 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8EDC3A6C10; Sat, 14 Feb 2009 10:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rRXdha1molk; Sat, 14 Feb 2009 10:06:00 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 3D8E328C113; Sat, 14 Feb 2009 10:05:25 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 4C90DE081ED; Sat, 14 Feb 2009 19:05:27 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp6-g21.free.fr (Postfix) with ESMTP id 50246E081D1; Sat, 14 Feb 2009 19:05:24 +0100 (CET) Message-ID: <499707DA.4030908@gmail.com> Date: Sat, 14 Feb 2009 19:05:14 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Philip Levis References: <49958529.5010306@gmail.com> <499590B6.3000305@gmail.com> <81A825C6-463E-40FA-9D4A-DEBB413C7F00@cs.stanford.edu> In-Reply-To: <81A825C6-463E-40FA-9D4A-DEBB413C7F00@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090213-0, 13/02/2009), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG , roll-bounces@ietf.org, "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 18:06:02 -0000 Philip Levis a écrit : > > On Feb 13, 2009, at 7:24 AM, Alexandru Petrescu wrote: > >> JP Vasseur a écrit : >>> On Feb 13, 2009, at 3:35 PM, Alexandru Petrescu wrote: >>>> Jerald - ok, PLC is important. It's related to routing and energy >>>> transportation. >>>> But. It doesn't sound as PLC devices having limited power, they sit >>>> on more power than they'd ever need. >>> As I tried to explain before, still you want these device to consume >>> as less energy as possible (e.g few dozens of mW) thus there are >>> constrained. If you have a house and want to do energy management you >>> could not afford to have all these device consume 3W each. >> >> The problem here is _not_ to reduce the energy consumption in house. >> >> It is to have routing work on small naturally-low-power devices - if >> that is achieved at the cost of 3W consumption by high-power devices >> then so be it. >> >> It's difficult to embark on solving energy consumption at all possible >> levels. >> >> Alex > > > Alex, > > Please listen to what the domain experts (e.g., Jerald) say, rather than > make blanket statements based on no experience in the domain. I think > it's safe to say that everyone here is very interested in constructive > advice, comments, and even debate, but contradicting basic assumptions > with no background knowledge hardly meets those criteria. Philip - I long thought about PLC-low-power text in question in the Charter. I believe it to be contradictory. That is an oppinion - make of it what you wish. Alex From pal@cs.stanford.edu Sat Feb 14 12:30:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B655A3A68D7 for ; Sat, 14 Feb 2009 12:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqXJaVmYy70I for ; Sat, 14 Feb 2009 12:30:46 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 6A34D3A67D7 for ; Sat, 14 Feb 2009 12:30:46 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1LYRA3-00060d-22; Sat, 14 Feb 2009 12:30:54 -0800 Message-Id: <4B0FF584-FCCD-4CDB-B8DC-375A74B40663@cs.stanford.edu> From: Philip Levis To: JP Vasseur In-Reply-To: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 14 Feb 2009 12:30:45 -0800 References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> X-Mailer: Apple Mail (2.930.3) X-Scan-Signature: 0ecaf295db8a04c0f692789316a3d0cf Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 20:30:47 -0000 Comments/suggestions inline. Overall I think the charter is good. On Feb 11, 2009, at 12:08 AM, JP Vasseur wrote: > Low power and Lossy networks (LLNs) are typically composed of many > embedded devices with limited power, memory, and processing resources > interconnected by a variety of links, such as IEEE 802.15.4, > Bluetooth, > Low Power WiFi or other low power PLC (Powerline Communication) links. Low power and Lossy Networks (LLNs) are made up of many embedded devices with limited energy, memory, and processing. The are interconnected by a variety of link layers, including IEEE 802.15.4, Bluetooth, low power WiFi and low power PLC (PowerLine Communication). > 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. The challenges introduced by interconnecting non-interoperable LLNs through protocol translation gateways and proxies, as well as initial, non-standardized IP protocol stacks, demonstrate that LLNs greatly benefit from an end-to-send IP-based solution. > LLNs have specific characteristics: > - LLNs operate with a hard, very small bound on state, > - In most cases, LLN need to be optimized for energy saving, > - Typical traffic patterns are not simply unicast flows, > - In most cases, LLNs need to be effective with very small > packet sizes, > - LLN routing protocols have to be very careful when trading > off efficiency for generality; many LLN nodes do not have resources > to waste. Generally speaking, LLNs have at least five distinguishing characteristics: - They operate with a hard, very small bound on state. - In most cases, LLNs optimize for saving energy. - Typical traffic patterns are not simple unicast flows. - LLN protocols need to be effective with very small packet sizes. - LLN protocols have to be very careful trading off efficiency for generality; many LLN nodes do not have resources to waste. > > > These unique properties lead to unique routing requirements that may > not met by > existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For > example path selection must be designed to take into consideration the > specific power capabilities, attributes and functional characteristics > of the links and nodes in the network. These properties cause LLNs to have requirements that existing routing protocols, such as OSPF, IS-IS, AODV, and OLSR, do not meet. For example, path selection must at times consider the specific power capabilities, attributes, and functional characteristics of links and nodes in the network. > > > > > 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 home, healthcare, environmental monitoring, > urban sensor networks sensor networks, assets tracking, refrigeration. > The Working Group will only focus on routing solutions for a subset of > these. It will focus on industrial, connected home, building and urban > sensor networks and specify the set of routing requirements for > these scenarios. The scope of application domains for LLNs is large. Application domains include industrial monitoring, building automation (HVAC, lighting, access control, fire), connected homes, healthcare, environmental monitoring, urban sensor networks, assets tracking, and food safety monitoring. The Working Group focuses only on routing protocols for a subset of these: industrial automation, connected homes, building and urban sensor networks. The Working Group's work includes specifying the set of routing requirements for these domains. > The Working Group focuses only on IPv6 only 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 explore aspects of mobility within a single LLN > (if any) in the routing requirement creation. The Working Group's protocol work centers on the IPv6 routing architecture for the above application domains. This architecture will consider the operating environments of LLNs, such as high reliability in the presence of time-varying link loss characteristics, time- varying connectivity, low-power operation, very limited memory and CPU resources, and small link-layer MTUs. The architecture will consider networks comprising a very large number (several thousand) nodes. Finally, the architecture will consider the traffic patterns typical to these application domains. > The Working Group will pay particular attention to routing security > and > manageability (e.g., self 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 Working Group will also consider the application and operational requirements of LLNs. These considerations include routing security and manageability (e.g., self-configuration), the effects of routing decisions on transport protocols. Mechanisms that prevent an LLN from congestion collapse or that seek fairness between concurrent sessions are out of scope for the Working Group. The expectation is that these concerns will be handled by higher layers. > 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 protocols 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: In light of the application specific routing > requirements, the Working Group will either specify a new protocol > and/or will select an existing routing protocol (with the > appropriate extensions in cooperation with the relevant Working > Group). > > - Documentation of applicability statement of ROLL routing protocols. > > Goals and Milestones: > > Done Submit Routing requirements for Industrial applications to > the IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Connected Home networks > applications to the IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Building applications to the > IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Urban networks applications > to the IESG to be considered as an Informational RFC. > July 2009 Submit Routing metrics for LLNs document to the IESG to > be considered as a Proposed Standard. > * Feb 2009 Submit Protocol Survey to the IESG to be considered as > an Informational RFC. > April 2009 Submit Security Framework to the IESG to be considered > as an Informational RFC > May 2009 Submit the Routing for LLNs Architecture document to > the IESG as an Informational RFC. > July 2009 Submit first draft of ROLL routing protocol > specification as Proposed Standard. > Nov 2009 Submit first draft of the MIB module of the ROLL > routing protocol specification. > Dec 2009 Submit the ROLL routing protocol specification to the > IESG as Proposed Standard. > Jan 2010 Submit the MIB module of the ROLL routing protocol > specification to the IESG as Proposed Standard. > Jan 2010 Evaluate WG progress, recharter or close. > > PS: I marked * the Milestones that will be "This Week" and before > submitting to the IESG for re-chartering. From jvasseur@cisco.com Sat Feb 14 13:59:39 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AF773A6825 for ; Sat, 14 Feb 2009 13:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luUZXvJz0UDs for ; Sat, 14 Feb 2009 13:59:37 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2705D3A659C for ; Sat, 14 Feb 2009 13:59:36 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,207,1233532800"; d="scan'208";a="33799547" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 14 Feb 2009 21:59:42 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1ELxfp0010925; Sat, 14 Feb 2009 22:59:41 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1ELxfd5025576; Sat, 14 Feb 2009 21:59:41 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Feb 2009 22:59:41 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Feb 2009 22:59:40 +0100 Message-Id: <4105F397-1045-429C-BC57-6DAA0042F4C3@cisco.com> From: JP Vasseur To: Philip Levis In-Reply-To: <4B0FF584-FCCD-4CDB-B8DC-375A74B40663@cs.stanford.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 14 Feb 2009 22:59:39 +0100 References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> <4B0FF584-FCCD-4CDB-B8DC-375A74B40663@cs.stanford.edu> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 14 Feb 2009 21:59:40.0948 (UTC) FILETIME=[895A1540:01C98EEF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9298; t=1234648781; x=1235512781; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20re-chartering |Sender:=20; bh=BoZT0xIFAOIsPNO1q122GnqoOdzJuVG/xusFskY75A0=; b=mEHQfyvb6EeDWSE3K1FKYa8zmg4JtRwEdg7B9Sv2QixFHxVUrb6l06XiNr oswS6gRThI6i09WBBi65kq3NT+Ztyn780okizE0SQMpfWRcazZYEhat4gOEl 32KZT8hRll; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 21:59:39 -0000 Hi Phil, Thanks for the editorial comments - I see no disagreement on the content, good. JP. On Feb 14, 2009, at 9:30 PM, Philip Levis wrote: > Comments/suggestions inline. Overall I think the charter is good. > > On Feb 11, 2009, at 12:08 AM, JP Vasseur wrote: > >> Low power and Lossy networks (LLNs) are typically composed of many >> embedded devices with limited power, memory, and processing resources >> interconnected by a variety of links, such as IEEE 802.15.4, >> Bluetooth, >> Low Power WiFi or other low power PLC (Powerline Communication) >> links. > > Low power and Lossy Networks (LLNs) are made up of many embedded > devices with limited energy, memory, and processing. The are > interconnected by a variety of link layers, including IEEE 802.15.4, > Bluetooth, low power WiFi and low power PLC (PowerLine Communication). > > >> 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. > > The challenges introduced by interconnecting non-interoperable LLNs > through protocol translation gateways and proxies, as well as > initial, non-standardized IP protocol stacks, demonstrate that LLNs > greatly benefit from an end-to-send IP-based solution. > > >> LLNs have specific characteristics: >> - LLNs operate with a hard, very small bound on state, >> - In most cases, LLN need to be optimized for energy saving, >> - Typical traffic patterns are not simply unicast flows, >> - In most cases, LLNs need to be effective with very small >> packet sizes, >> - LLN routing protocols have to be very careful when trading >> off efficiency for generality; many LLN nodes do not have resources >> to waste. > > Generally speaking, LLNs have at least five distinguishing > characteristics: > > - They operate with a hard, very small bound on state. > - In most cases, LLNs optimize for saving energy. > - Typical traffic patterns are not simple unicast flows. > - LLN protocols need to be effective with very small packet sizes. > - LLN protocols have to be very careful trading off efficiency for > generality; many LLN nodes do not have resources to waste. > > >> >> >> These unique properties lead to unique routing requirements that >> may not met by >> existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For >> example path selection must be designed to take into consideration >> the >> specific power capabilities, attributes and functional >> characteristics >> of the links and nodes in the network. > > These properties cause LLNs to have requirements that existing > routing protocols, such as OSPF, IS-IS, AODV, and OLSR, do not meet. > For example, path selection must at times consider the specific > power capabilities, attributes, and functional characteristics of > links and nodes in the network. > > >> >> >> >> >> 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 home, healthcare, environmental monitoring, >> urban sensor networks sensor networks, assets tracking, >> refrigeration. >> The Working Group will only focus on routing solutions for a subset >> of >> these. It will focus on industrial, connected home, building and >> urban >> sensor networks and specify the set of routing requirements for >> these scenarios. > > The scope of application domains for LLNs is large. Application > domains include industrial monitoring, building automation (HVAC, > lighting, access control, fire), connected homes, healthcare, > environmental monitoring, urban sensor networks, assets tracking, > and food safety monitoring. The Working Group focuses only on > routing protocols for a subset of these: industrial automation, > connected homes, building and urban sensor networks. The Working > Group's work includes specifying the set of routing requirements for > these domains. > >> The Working Group focuses only on IPv6 only 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 explore aspects of mobility within a single >> LLN >> (if any) in the routing requirement creation. > > The Working Group's protocol work centers on the IPv6 routing > architecture for the above application domains. This architecture > will consider the operating environments of LLNs, such as high > reliability in the presence of time-varying link loss > characteristics, time-varying connectivity, low-power operation, > very limited memory and CPU resources, and small link-layer MTUs. > The architecture will consider networks comprising a very large > number (several thousand) nodes. Finally, the architecture will > consider the traffic patterns typical to these application domains. > > > >> The Working Group will pay particular attention to routing security >> and >> manageability (e.g., self 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 Working Group will also consider the application and operational > requirements of LLNs. These considerations > include routing security and manageability (e.g., self- > configuration), the effects of routing decisions on transport > protocols. Mechanisms that prevent an LLN from congestion collapse > or that seek fairness between concurrent sessions are out of scope > for the Working Group. The expectation is that these concerns will > be handled by higher layers. > >> 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 protocols 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: In light of the application specific routing >> requirements, the Working Group will either specify a new protocol >> and/or will select an existing routing protocol (with the >> appropriate extensions in cooperation with the relevant Working >> Group). >> >> - Documentation of applicability statement of ROLL routing protocols. >> >> Goals and Milestones: >> >> Done Submit Routing requirements for Industrial applications to >> the IESG to be considered as an Informational RFC. >> Done Submit Routing requirements for Connected Home networks >> applications to the IESG to be considered as an Informational RFC. >> Done Submit Routing requirements for Building applications to the >> IESG to be considered as an Informational RFC. >> Done Submit Routing requirements for Urban networks applications >> to the IESG to be considered as an Informational RFC. >> July 2009 Submit Routing metrics for LLNs document to the IESG >> to be considered as a Proposed Standard. >> * Feb 2009 Submit Protocol Survey to the IESG to be considered as >> an Informational RFC. >> April 2009 Submit Security Framework to the IESG to be considered >> as an Informational RFC >> May 2009 Submit the Routing for LLNs Architecture document to >> the IESG as an Informational RFC. >> July 2009 Submit first draft of ROLL routing protocol >> specification as Proposed Standard. >> Nov 2009 Submit first draft of the MIB module of the ROLL >> routing protocol specification. >> Dec 2009 Submit the ROLL routing protocol specification to the >> IESG as Proposed Standard. >> Jan 2010 Submit the MIB module of the ROLL routing protocol >> specification to the IESG as Proposed Standard. >> Jan 2010 Evaluate WG progress, recharter or close. >> >> PS: I marked * the Milestones that will be "This Week" and before >> submitting to the IESG for re-chartering. > From pal@cs.stanford.edu Sat Feb 14 14:07:44 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 840143A6981 for ; Sat, 14 Feb 2009 14:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URQeUPpcGtuz for ; Sat, 14 Feb 2009 14:07:43 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id DB7F53A6948 for ; Sat, 14 Feb 2009 14:07:43 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1LYSfv-0000Hh-1O; Sat, 14 Feb 2009 14:07:52 -0800 Message-Id: From: Philip Levis To: JP Vasseur In-Reply-To: <4105F397-1045-429C-BC57-6DAA0042F4C3@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 14 Feb 2009 14:07:51 -0800 References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> <4B0FF584-FCCD-4CDB-B8DC-375A74B40663@cs.stanford.edu> <4105F397-1045-429C-BC57-6DAA0042F4C3@cisco.com> X-Mailer: Apple Mail (2.930.3) X-Scan-Signature: c6b7461a7773f457175e025605fe13fe Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 22:07:44 -0000 On Feb 14, 2009, at 1:59 PM, JP Vasseur wrote: > Hi Phil, > > Thanks for the editorial comments - I see no disagreement on the > content, good. > > JP. Yes, no disagreement on content. Phil From jvasseur@cisco.com Sun Feb 15 03:02:58 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D4353A6AC9 for ; Sun, 15 Feb 2009 03:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5Pc6PdSaj0v for ; Sun, 15 Feb 2009 03:02:57 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DC3E13A6AC4 for ; Sun, 15 Feb 2009 03:02:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,210,1233532800"; d="scan'208";a="33814178" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 15 Feb 2009 11:03:02 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1FB32C3024222 for ; Sun, 15 Feb 2009 12:03:02 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1FB321S007068 for ; Sun, 15 Feb 2009 11:03:02 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Feb 2009 12:03:01 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Feb 2009 12:03:01 +0100 Message-Id: From: JP Vasseur To: ROLL WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 15 Feb 2009 12:03:00 +0100 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 15 Feb 2009 11:03:01.0839 (UTC) FILETIME=[F810E5F0:01C98F5C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=138; t=1234695782; x=1235559782; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Slot=20for=20the=20ROLL=20WG=20Meeting=20in=20S FO=20-=20IETF=2073 |Sender:=20; bh=ipPJIHuxznAtAOTlmp4vCidYAL1FZ2vJpTylJL6fsl4=; b=LOvMy1OERHa8SMJw+K2jNiYYxtsbVONhqL4VFaYX49vVs1uhJJME8txAQt nAaj97SyvWD2P7rFUUMWd+/s6pGBs36uM/Q3xsQS/yHstOslhqFmgqU5oeWK HgK+6uwi/P; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Roll] Slot for the ROLL WG Meeting in SFO - IETF 73 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 11:02:58 -0000 Dear all, Please let us know no later than end of February if you request a slot for the ROLL WG meeting in SFO. Thanks. JP. From alexandru.petrescu@gmail.com Sun Feb 15 05:17:08 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 669FE3A69D3 for ; Sun, 15 Feb 2009 05:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQotgADZ4-wu for ; Sun, 15 Feb 2009 05:17:07 -0800 (PST) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by core3.amsl.com (Postfix) with ESMTP id D69343A67D2 for ; Sun, 15 Feb 2009 05:17:05 -0800 (PST) Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id 67F02818160; Sun, 15 Feb 2009 14:17:08 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp3-g21.free.fr (Postfix) with ESMTP id 61CEB8180DA; Sun, 15 Feb 2009 14:17:05 +0100 (CET) Message-ID: <499815C5.9090002@gmail.com> Date: Sun, 15 Feb 2009 14:16:53 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Philip Levis References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> <4B0FF584-FCCD-4CDB-B8DC-375A74B40663@cs.stanford.edu> In-Reply-To: <4B0FF584-FCCD-4CDB-B8DC-375A74B40663@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090214-0, 14/02/2009), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 13:17:08 -0000 Philip Levis a écrit : > Comments/suggestions inline. Overall I think the charter is good. > > On Feb 11, 2009, at 12:08 AM, JP Vasseur wrote: > >> Low power and Lossy networks (LLNs) are typically composed of many >> embedded devices with limited power, memory, and processing >> resources interconnected by a variety of links, such as IEEE >> 802.15.4, Bluetooth, Low Power WiFi or other low power PLC >> (Powerline Communication) links. For clarification: would one point to a low-power PLC link, which is not the typical range 100Mbps 220V/Ethernet/wifi bridge? I wouldn't qualify this latter as low-power device neither lossy link. Alex > > Low power and Lossy Networks (LLNs) are made up of many embedded > devices with limited energy, memory, and processing. The are > interconnected by a variety of link layers, including IEEE 802.15.4, > Bluetooth, low power WiFi and low power PLC (PowerLine > Communication). > > >> 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. > > The challenges introduced by interconnecting non-interoperable LLNs > through protocol translation gateways and proxies, as well as > initial, non-standardized IP protocol stacks, demonstrate that LLNs > greatly benefit from an end-to-send IP-based solution. > > >> LLNs have specific characteristics: - LLNs operate with a >> hard, very small bound on state, - In most cases, LLN need to >> be optimized for energy saving, - Typical traffic patterns >> are not simply unicast flows, - In most cases, LLNs need to >> be effective with very small packet sizes, - LLN routing >> protocols have to be very careful when trading off efficiency for >> generality; many LLN nodes do not have resources to waste. > > Generally speaking, LLNs have at least five distinguishing > characteristics: > > - They operate with a hard, very small bound on state. - In most > cases, LLNs optimize for saving energy. - Typical traffic patterns > are not simple unicast flows. - LLN protocols need to be effective > with very small packet sizes. - LLN protocols have to be very careful > trading off efficiency for generality; many LLN nodes do not have > resources to waste. > > >> >> >> These unique properties lead to unique routing requirements that >> may not met by existing routing protocols, such as OSPF, IS-IS, >> AODV and OLSR. For example path selection must be designed to take >> into consideration the specific power capabilities, attributes and >> functional characteristics of the links and nodes in the network. > > These properties cause LLNs to have requirements that existing > routing protocols, such as OSPF, IS-IS, AODV, and OLSR, do not meet. > For example, path selection must at times consider the specific power > capabilities, attributes, and functional characteristics of links > and nodes in the network. > > >> >> >> >> >> 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 home, healthcare, environmental >> monitoring, urban sensor networks sensor networks, assets tracking, >> refrigeration. The Working Group will only focus on routing >> solutions for a subset of these. It will focus on industrial, >> connected home, building and urban sensor networks and specify the >> set of routing requirements for these scenarios. > > The scope of application domains for LLNs is large. Application > domains include industrial monitoring, building automation (HVAC, > lighting, access control, fire), connected homes, healthcare, > environmental monitoring, urban sensor networks, assets tracking, and > food safety monitoring. The Working Group focuses only on routing > protocols for a subset of these: industrial automation, connected > homes, building and urban sensor networks. The Working Group's work > includes specifying the set of routing requirements for these > domains. > >> The Working Group focuses only on IPv6 only 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 explore >> aspects of mobility within a single LLN (if any) in the routing >> requirement creation. > > The Working Group's protocol work centers on the IPv6 routing > architecture for the above application domains. This architecture > will consider the operating environments of LLNs, such as high > reliability in the presence of time-varying link loss > characteristics, time-varying connectivity, low-power operation, very > limited memory and CPU resources, and small link-layer MTUs. The > architecture will consider networks comprising a very large number > (several thousand) nodes. Finally, the architecture will consider the > traffic patterns typical to these application domains. > > > >> The Working Group will pay particular attention to routing security >> and manageability (e.g., self 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 Working Group will also consider the application and operational > requirements of LLNs. These considerations include routing security > and manageability (e.g., self-configuration), the effects of routing > decisions on transport protocols. Mechanisms that prevent an LLN from > congestion collapse or that seek fairness between concurrent sessions > are out of scope for the Working Group. The expectation is that these > concerns will be handled by higher layers. > >> 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 protocols 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: In light of the application specific routing >> requirements, the Working Group will either specify a new protocol >> and/or will select an existing routing protocol (with the >> appropriate extensions in cooperation with the relevant Working >> Group). >> >> - Documentation of applicability statement of ROLL routing >> protocols. >> >> Goals and Milestones: >> >> Done Submit Routing requirements for Industrial applications to >> the IESG to be considered as an Informational RFC. Done Submit >> Routing requirements for Connected Home networks applications to >> the IESG to be considered as an Informational RFC. Done Submit >> Routing requirements for Building applications to the IESG to be >> considered as an Informational RFC. Done Submit Routing >> requirements for Urban networks applications to the IESG to be >> considered as an Informational RFC. July 2009 Submit Routing >> metrics for LLNs document to the IESG to be considered as a >> Proposed Standard. * Feb 2009 Submit Protocol Survey to the IESG >> to be considered as an Informational RFC. April 2009 Submit >> Security Framework to the IESG to be considered as an Informational >> RFC May 2009 Submit the Routing for LLNs Architecture document >> to the IESG as an Informational RFC. July 2009 Submit first >> draft of ROLL routing protocol specification as Proposed Standard. >> Nov 2009 Submit first draft of the MIB module of the ROLL >> routing protocol specification. Dec 2009 Submit the ROLL >> routing protocol specification to the IESG as Proposed Standard. >> Jan 2010 Submit the MIB module of the ROLL routing protocol >> specification to the IESG as Proposed Standard. Jan 2010 >> Evaluate WG progress, recharter or close. >> >> PS: I marked * the Milestones that will be "This Week" and before >> submitting to the IESG for re-chartering. > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From root@core3.amsl.com Sun Feb 15 12:30:01 2009 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2CB043A6925; Sun, 15 Feb 2009 12:30:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090215203001.2CB043A6925@core3.amsl.com> Date: Sun, 15 Feb 2009 12:30:01 -0800 (PST) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-urban-routing-reqs-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 20:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Urban WSNs Routing Requirements in Low Power and Lossy Networks Author(s) : M. Dohler, et al. Filename : draft-ietf-roll-urban-routing-reqs-04.txt Pages : 21 Date : 2009-02-15 The application-specific routing requirements for Urban Low Power and Lossy Networks (U-LLNs) are presented in this document. In the near future, sensing and actuating nodes will be placed outdoors in urban environments so as to improve the people's living conditions as well as to monitor compliance with increasingly strict environmental laws. These field nodes are expected to measure and report a wide gamut of data, such as required in smart metering, waste disposal, meteorological, pollution and allergy reporting applications. The majority of these nodes is expected to communicate wirelessly over a variety of links such as IEEE 802.15.4, Low power IEEE 802.11, IEEE 802.15.1 (Bluetooth), which given the limited radio range and the large number of nodes requires the use of suitable routing protocols. The design of such protocols will be mainly impacted by the limited resources of the nodes (memory, processing power, battery, etc.) and the particularities of the outdoor urban application scenarios. As such, for a wireless Routing Over Low power and Lossy networks (ROLL) solution to be useful, the protocol(s) ought to be energy-efficient, scalable, and autonomous. This documents aims to specify a set of IPv6 routing requirements reflecting these and further U-LLNs tailored characteristics. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-urban-routing-reqs-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-urban-routing-reqs-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-15122009.I-D@ietf.org> --NextPart-- From tim.winter@ekasystems.com Sun Feb 15 12:39:13 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A76F3A696C for ; Sun, 15 Feb 2009 12:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fd2p3XU0yjXW for ; Sun, 15 Feb 2009 12:39:12 -0800 (PST) Received: from smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by core3.amsl.com (Postfix) with SMTP id 168E43A68E4 for ; Sun, 15 Feb 2009 12:39:12 -0800 (PST) Received: (qmail 42803 invoked from network); 15 Feb 2009 20:39:20 -0000 Received: from unknown (HELO zeke.ekasystems.com) (tim.winter@209.48.242.66 with plain) by smtp107.biz.mail.re2.yahoo.com with SMTP; 15 Feb 2009 20:39:20 -0000 X-YMail-OSG: jc2.ft8VM1mE5OcGXjap1CEvX_ZHibBOe.v9QRxYVrbQ.vLMnR_x6NwZnq.KOXr41yVwXQ_PE.uw9.CW35pntiz4m2cbagldz2Y9H4mc30yVuRYKpbq2v15stN3DhUuddN7vHL2mhpdF6rzPAyDA25yTsysz73HFWnZP_G_KpCuBF3f2BS4Eh5NCsov5ZkqJKD20cp1nX.WC8QchdR2vyQ.5733c X-Yahoo-Newman-Property: ymail-3 Message-ID: <49987D77.8030000@ekasystems.com> Date: Sun, 15 Feb 2009 15:39:19 -0500 From: Tim Winter User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: JP Vasseur , "David E. Culler" , ROLL WG References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> In-Reply-To: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 20:39:13 -0000 The proposed charter looks good to me. -Tim JP Vasseur wrote: > Dear WG, > > As indicated in a previous email, the protocol survey I-D will be send > for publication this week (after posting of the last revision > incorporating several useful comments). > > As promised please find below the new proposed charter to be submitted > to the IESG for approval. In the hope of getting quickly re-chartered > thanks to let us know if you have any comment by the ned of this week. > The new charter is pretty straightforward. > > Thanks to Dave Ward for his comments and guidance. > > Description of Working Group: > > Low power and Lossy networks (LLNs) are typically composed of many > embedded devices with limited power, memory, and processing resources > interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, > Low Power WiFi 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. LLNs have > specific characteristics: > - LLNs operate with a hard, very small bound on state, > - In most cases, LLN need to be optimized for energy saving, > - Typical traffic patterns are not simply unicast flows, > - In most cases, LLNs need to be effective with very small packet > sizes, > - LLN routing protocols have to be very careful when trading off > efficiency for generality; many LLN nodes do not have resources to waste. > > These unique properties lead to unique routing requirements that may not > met by > existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For > example path selection must be designed to take into consideration the > specific power capabilities, attributes and functional characteristics > of the links and nodes in the network. > > > > 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 home, healthcare, environmental monitoring, > urban sensor networks sensor networks, assets tracking, refrigeration. > The Working Group will only focus on routing solutions for a subset of > these. It will focus on industrial, connected home, building and urban > sensor networks and specify the set of routing requirements for > these scenarios. > > The Working Group focuses only on IPv6 only 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 explore aspects of mobility within a single LLN > (if any) in the routing requirement creation. > > The Working Group will pay particular attention to routing security and > manageability (e.g., self 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. > > > 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 protocols 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: In light of the application specific routing > requirements, the Working Group will either specify a new protocol > and/or will select an existing routing protocol (with the appropriate > extensions in cooperation with the relevant Working Group). > > - Documentation of applicability statement of ROLL routing protocols. > > Goals and Milestones: > > Done Submit Routing requirements for Industrial applications to the > IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Connected Home networks > applications to the IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Building applications to the IESG > to be considered as an Informational RFC. > Done Submit Routing requirements for Urban networks applications to > the IESG to be considered as an Informational RFC. > July 2009 Submit Routing metrics for LLNs document to the IESG to be > considered as a Proposed Standard. > * Feb 2009 Submit Protocol Survey to the IESG to be considered as an > Informational RFC. > April 2009 Submit Security Framework to the IESG to be considered as > an Informational RFC > May 2009 Submit the Routing for LLNs Architecture document to the > IESG as an Informational RFC. > July 2009 Submit first draft of ROLL routing protocol specification > as Proposed Standard. > Nov 2009 Submit first draft of the MIB module of the ROLL routing > protocol specification. > Dec 2009 Submit the ROLL routing protocol specification to the IESG > as Proposed Standard. > Jan 2010 Submit the MIB module of the ROLL routing protocol > specification to the IESG as Proposed Standard. > Jan 2010 Evaluate WG progress, recharter or close. > > PS: I marked * the Milestones that will be "This Week" and before > submitting to the IESG for re-chartering. > > > > Thanks. > > JP and David. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From gnawali@gmail.com Sun Feb 15 18:02:16 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E38B3A6B15 for ; Sun, 15 Feb 2009 18:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWNP208TsCWN for ; Sun, 15 Feb 2009 18:02:15 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 6A8BE3A6B13 for ; Sun, 15 Feb 2009 18:02:15 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so2263148yxm.49 for ; Sun, 15 Feb 2009 18:02:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1cdA6DotU30lSm7j3uTGzBg4TmgB5v0w3PyUMBsAqBw=; b=DGk6o7mx+TIiuLtCRstoAAof9op6sz8VSD2V8OpUUTmGk4Sw6o35uKzkyaQYHhLNq0 x4n9xvrVhlHT3Ma3Kn8/+AtRgBq7W1bW2ISXYDuPgCiBUIdJ8XWTizKZpnjP+0r9FThw Ut5N7G/qsSDuPZ3MFaH6xSq8NYBa2KBcQZIBM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DhaCnhU/M1/BkoLL/ThuGH3sn0U7zP2SFy1SMGbT2CfCEOpDnl+oWHH8hE1hsyx47M UcFw06IN0Gu0DBH+AVJ30Ga4BdtQ/EKFmM2UWhh5wQedKylLndXXz9G2tCcHoEstj8sK K44+ZsgNGGXVnN1j2zcIo9cmTGFKLQ7CYcXOI= MIME-Version: 1.0 Received: by 10.90.27.5 with SMTP id a5mr1270187aga.118.1234749743484; Sun, 15 Feb 2009 18:02:23 -0800 (PST) In-Reply-To: <4B0FF584-FCCD-4CDB-B8DC-375A74B40663@cs.stanford.edu> References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> <4B0FF584-FCCD-4CDB-B8DC-375A74B40663@cs.stanford.edu> Date: Sun, 15 Feb 2009 18:02:23 -0800 Message-ID: From: Omprakash Gnawali To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 02:02:16 -0000 Charter looks good. Two nits and one comment below. On Sat, Feb 14, 2009 at 12:30 PM, Philip Levis wrote: > Comments/suggestions inline. Overall I think the charter is good. > > On Feb 11, 2009, at 12:08 AM, JP Vasseur wrote: > >> Low power and Lossy networks (LLNs) are typically composed of many >> embedded devices with limited power, memory, and processing resources >> interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, >> Low Power WiFi or other low power PLC (Powerline Communication) links. > > Low power and Lossy Networks (LLNs) are made up of many embedded devices > with limited energy, memory, and processing. The are interconnected by a resources missing after processing. ... >> LLNs have specific characteristics: >> - LLNs operate with a hard, very small bound on state, >> - In most cases, LLN need to be optimized for energy saving, >> - Typical traffic patterns are not simply unicast flows, >> - In most cases, LLNs need to be effective with very small packet >> sizes, >> - LLN routing protocols have to be very careful when trading off >> efficiency for generality; many LLN nodes do not have resources to waste. > > Generally speaking, LLNs have at least five distinguishing characteristics: > > - They operate with a hard, very small bound on state. > - In most cases, LLNs optimize for saving energy. > - Typical traffic patterns are not simple unicast flows. We already say "Generally", so we can drop "In most cases" and "Typical" from the items on the list. > - LLN protocols need to be effective with very small packet sizes. Probably a few words missing after effective: effective at doing something. I can not think of what that something is unless we are talking about some type of efficiency. - om_p From ietf@thomasclausen.org Mon Feb 16 00:50:52 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EC553A6C2D for ; Mon, 16 Feb 2009 00:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2+jVshgHpXv for ; Mon, 16 Feb 2009 00:50:51 -0800 (PST) Received: from mho-01-bos.mailhop.org (mho-01-bos.mailhop.org [63.208.196.178]) by core3.amsl.com (Postfix) with ESMTP id 67D7A3A6C2C for ; Mon, 16 Feb 2009 00:50:51 -0800 (PST) Received: from sphinx.lix.polytechnique.fr ([129.104.11.1] helo=[192.168.112.180]) by mho-01-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LYzBr-000IQ9-IJ; Mon, 16 Feb 2009 08:50:59 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 129.104.11.1 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18uvxl0eXYNqImIf6sJBQyq Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2E9C8639-A971-490D-A1C4-129AB927013A@thomasclausen.org> Content-Transfer-Encoding: 7bit From: Thomas Heide Clausen Date: Mon, 16 Feb 2009 09:49:02 +0100 To: "J.P. Vasseur" , ROLL WG , "David E. Culler" X-Mailer: Apple Mail (2.753.1) Subject: [Roll] Regarding survey I-D X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 08:50:52 -0000 All, I've read the document in and have a couple of lingering comments that I'll be trying to type up asap. Unfortunately, other duties prevented me from doing so last week and over the weekend, accept my apologies for this delay. Thomas From ietf@thomasclausen.org Mon Feb 16 00:51:05 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F22883A6C31 for ; Mon, 16 Feb 2009 00:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFn3u+Yc0Wlb for ; Mon, 16 Feb 2009 00:51:02 -0800 (PST) Received: from mho-01-bos.mailhop.org (mho-01-bos.mailhop.org [63.208.196.178]) by core3.amsl.com (Postfix) with ESMTP id 6EBCD3A6C32 for ; Mon, 16 Feb 2009 00:51:02 -0800 (PST) Received: from sphinx.lix.polytechnique.fr ([129.104.11.1] helo=[192.168.112.180]) by mho-01-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LYzC3-000IQ9-8d; Mon, 16 Feb 2009 08:51:11 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 129.104.11.1 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+fUpfauUmCgl343aBXwHzO In-Reply-To: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: multipart/alternative; boundary=Apple-Mail-2-916401706 Message-Id: <7F8096B9-1691-44D2-9032-6383C6C765B3@thomasclausen.org> From: Thomas Heide Clausen Date: Mon, 16 Feb 2009 09:49:15 +0100 To: JP Vasseur X-Mailer: Apple Mail (2.753.1) Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 08:51:05 -0000 --Apple-Mail-2-916401706 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear JP, David, ROLL wg, (and, as I have a question to Alex, I Cc' him explicitly too) I've got a couple of comments to the charter below. I think it needs a bit of clarification in some areas, and also the relationship to current ROLL WG products needs to be clarified IMO. See below for details -- most of which I believe are questions that I raise that it should be fairly easy for a more experienced person to simply answer and propose a one-sentence clarification-edit to the charter to fix. On Feb 11, 2009, at 9:08 AM, JP Vasseur wrote: > Dear WG, > > As indicated in a previous email, the protocol survey I-D will be > send for publication this week (after posting of the last revision > incorporating several useful comments). > > As promised please find below the new proposed charter to be > submitted to the IESG for approval. In the hope of getting quickly > re-chartered thanks to let us know if you have any comment by the > ned of this week. The new charter is pretty straightforward. > > Thanks to Dave Ward for his comments and guidance. > > Description of Working Group: > > Low power and Lossy networks (LLNs) are typically composed of many > embedded devices with limited power, memory, and processing resources > interconnected by a variety of links, such as IEEE 802.15.4, > Bluetooth, > Low Power WiFi 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. LLNs > have specific characteristics: > - LLNs operate with a hard, very small bound on state, > - In most cases, LLN need to be optimized for energy saving, I am not sure that "in most cases" is entirely clear here. Does this mean that we can get away with designing an "energy hungry" routing protocol for ROLL, as long as we specify in which cases it'd apply? I'd be happier getting rid of "in most cases" and replacing "energy saving" with "energy conservation" or something similar. > - Typical traffic patterns are not simply unicast flows, This, I have a big question mark to as well. It applies equally to the survey I-D, but I'll comment on that I-D in another email. Essentially, as a protocol designer, I'd expect a wg charter to help me understand the constraints under which I'd be designing a protocol. Reading the above item teaches me that I shouldn't design for "simply unicast flows", but what does that mean? Could I disregard unicast entirely and just build a multicast protocol? Do I then need group mgmt? Or is simple "roll-wide broadcast" all that's needed? Or all of the above? None of the above? IOW, we need to be much more specific with what the traffic patterns then typically would be? > - In most cases, LLNs need to be effective with very small > packet sizes, I've gone back and forth over this, and it's also a comment that I think needs clarification in the survey I-D. First, I think that it'd be helpful to say something as to "how small". Second, to which extend are we looking at transport [and other] issues in ROLL. I can read this in different ways, here's my first impulse on that bullet point: o ROLL runs over LLs with an extremely restricted frame-size, so something akin to IP header compression is on the table [are we then in RTG?]. o Presumably, the "very small packet sizes" also applies for data. Is this, then, a generic IP-over-FOO problem? I can guess at what the intent would be, but we need to spell it out here. > - LLN routing protocols have to be very careful when trading > off efficiency for generality; many LLN nodes do not have resources > to waste. I can see where Alexandru's question come from at this point, when we were talking about power-lines and such. Essentially, what we're wanting to say [I think] is that "ROLL protocols MUST be able to run on routers with [very-strict-set-of- restrictions]" -- and that there then may be a few routers with "better than [very-strict-set-of-restrictions]" shouldn't be driving our design, and that such routers are present is purely incidental. IOW, I'd suggest rephrasing this slightly, to say "these are the requirements that ROLL protocols shall satisfy -- if a device does better than that, more power to it, but it's not our primary design target". Alex, would a rephrasing like this satisfy you? > These unique properties lead to unique routing requirements that > may not met by > existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For > example path selection must be designed to take into consideration the > specific power capabilities, attributes and functional characteristics > of the links and nodes in the network. Request for clarification (a question may or may not follow): is multi-metric QoS thereby an explicit design requirement? Also, it seems from the sentence construction that it is inferred that "OSPF, IS-IS, AODV and OLSR" do not have the capability to take "power capabilities, attributes and functional characteristics of the links and nodes in the network" into consideration. I'm not sure that that's the entire truth. Can this be clarified a notch? > The Working Group is focused on routing issues for LLN Alright, so routing issues only. Fair enough -- but what's the relationship then with the "very small packet sizes" bullet point above? Do we expect [other-wg] to resolve this issue, or is there routing-only-issues that need be brought forward? If so, which? > There is a wide scope of application areas for LLNs, including > industrial monitoring, building automation (HVAC, lighting, access > control, fire), connected home, healthcare, environmental monitoring, > urban sensor networks sensor networks, assets tracking, refrigeration. > The Working Group will only focus on routing solutions for a subset of > these. It will focus on industrial, connected home, building and urban > sensor networks and specify the set of routing requirements for > these scenarios. Question: does the above entail "new work", or is this in reference to the current requirement I-Ds? > The Working Group focuses only on IPv6 only routing architectural > framework for these application scenarios. Question: by "architectural framework", what exactly is to be understood? > 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 explore aspects of mobility within a single LLN > (if any) in the routing requirement creation. Does this entail a new "routing requirements" document being produced? > The Working Group will pay particular attention to routing security > and > manageability (e.g., self configuration) issues. It will also need to > consider the transport characteristic the routing protocol > messages will > experience. This goes back to my previous question: IP-over-foo or ? More broadly, how are the current ROLL products (survey I-D, rtg requirements) expected to be employed in all this? Finally, in summarizing the charter, ROLL aims at solving: o routing over wireless o scalability to several thousands of routers o QoS in wireless networks, including o formalization of wireless link metrics o security within 10 months, and to the level of proposed standard. The items are very interesting, but 10 months is also *very* short -- and the complexity of some of those is not trivial without making serious concessions in some areas. Let me cite from an email from Dave Ward (Feb. 3, 2009) On Feb 3, 2009, at 5:52 PM, David Ward wrote: > I expect "wild swings" of the design pattern of the protocol during > the first year of the design effort. I attempted to make this clear > at the mic in Minneapolis that the current trajectory is very > complex problem domain that hasn't born a lot of fruit but, that in > the design phase reducing the complexity must occur. Considering the complexity of the list of items above, I am much more in line with what Dave Ward writes, than with what the milestones suggest. Thomas > 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. > > > 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 protocols 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: In light of the application specific routing > requirements, the Working Group will either specify a new protocol > and/or will select an existing routing protocol (with the > appropriate extensions in cooperation with the relevant Working > Group). > > - Documentation of applicability statement of ROLL routing protocols. > > Goals and Milestones: > > Done Submit Routing requirements for Industrial applications to > the IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Connected Home networks > applications to the IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Building applications to the > IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Urban networks applications > to the IESG to be considered as an Informational RFC. > July 2009 Submit Routing metrics for LLNs document to the IESG > to be considered as a Proposed Standard. > * Feb 2009 Submit Protocol Survey to the IESG to be considered as > an Informational RFC. > April 2009 Submit Security Framework to the IESG to be considered > as an Informational RFC > May 2009 Submit the Routing for LLNs Architecture document to > the IESG as an Informational RFC. > July 2009 Submit first draft of ROLL routing protocol > specification as Proposed Standard. > Nov 2009 Submit first draft of the MIB module of the ROLL > routing protocol specification. > Dec 2009 Submit the ROLL routing protocol specification to the > IESG as Proposed Standard. > Jan 2010 Submit the MIB module of the ROLL routing protocol > specification to the IESG as Proposed Standard. > Jan 2010 Evaluate WG progress, recharter or close. > > PS: I marked * the Milestones that will be "This Week" and before > submitting to the IESG for re-chartering. > > > > Thanks. > > JP and David. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-2-916401706 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Dear JP, David, ROLL wg,

(and, as I have a question = to Alex, I Cc' him explicitly too)

I've got a couple = of comments to the charter below. I think it needs a bit of = clarification in some areas, and also the relationship to current ROLL = WG products needs to be clarified IMO. See below for details -- most of = which I believe are questions that I raise that it should be fairly easy = for a more experienced person to simply answer and propose a = one-sentence clarification-edit to the charter to = fix.

On Feb 11, 2009, at 9:08 AM, JP = Vasseur wrote:

Dear WG,

As = indicated in a previous email, the protocol survey I-D will be send for = publication this week (after posting of the last revision incorporating = several useful comments).

As promised please find below = the new proposed charter to be submitted to the IESG for approval. In = the hope of getting quickly re-chartered thanks to let us know if you = have any comment by the ned of this week. The new charter is pretty = straightforward.

Thanks to Dave Ward for his comments and = guidance.

Description of Working Group:

Low = power and Lossy networks (LLNs) are typically composed of many
embedded devices with limited power, memory, and = processing resources
interconnected by a variety = of links, such as IEEE 802.15.4, Bluetooth,
Low = Power WiFi or other low power PLC (Powerline Communication) links. LLNs = are transitioning to an end-to-end IP-based
=A0solution to avoid the problem = of non-interoperable networks
- =A0 =A0 =A0 LLNs operate with a = hard, very small bound on state,
- =A0 =A0 =A0 In most cases, LLN = need to be optimized for energy = saving,

I am not sure that "in most = cases" is entirely clear here. Does this mean that we can get away with = designing an "energy hungry" routing protocol for ROLL, as long as we = specify in which cases it'd apply? I'd be happier getting rid of "in = most cases" and replacing "energy saving" with "energy conservation" or = something similar.

- =A0 =A0 =A0 = Typical traffic patterns are not simply unicast = flows,

This, I have a big question mark = to as well. It applies equally to the survey I-D, but I'll comment on = that I-D in another email.

Essentially, as a = protocol designer, I'd expect a wg charter to help me understand the = constraints under which I'd be designing a protocol. Reading the above = item teaches me that I shouldn't design for "simply unicast flows", but = what does that mean? Could I disregard unicast entirely and just build a = multicast protocol? Do I then need group mgmt? Or is simple "roll-wide = broadcast" all that's needed? Or all of the above? None of the = above?

IOW, we need to be much more specific = with what the traffic patterns then typically would = be?

- =A0 =A0 =A0 = In most cases, LLNs need to be effective with very small packet = sizes,

I've gone back and forth = over this, and it's also a comment that I think needs clarification in = the survey I-D. First, I think that it'd be helpful to say something as = to "how small". Second, to which extend are we looking at transport [and = other] issues in ROLL.

I can read this in = different ways, here's my first impulse on that bullet = point:

o ROLL runs over LLs with an = extremely restricted frame-size, so something akin to=A0
= IP=A0header compression is on the table [are we then in = RTG?].

o Presumably, the "very small = packet sizes" also applies for data. Is this, then,
a = generic IP-over-FOO problem?

I can guess at = what the intent would be, but we need to spell it out = here.

- =A0 =A0 =A0 = LLN routing protocols have to be very careful when trading off = efficiency for generality; many LLN nodes do not have resources to = waste.

I can see where Alexandru's = question come from at this point, when we were talking about power-lines = and such.

Essentially, what we're wanting to = say [I think] is that "ROLL protocols MUST be able to run on routers = with [very-strict-set-of-restrictions]" -- and that there then may be a = few routers with "better than [very-strict-set-of-restrictions]" = shouldn't be driving our design, and that such routers are present is = purely incidental.

IOW, I'd suggest rephrasing = this slightly, to say "these are the requirements that ROLL protocols = shall satisfy -- if a device does better than that, more power to it, = but it's not our primary design target".

Alex, = would a rephrasing like this satisfy = you?

These unique properties lead = to unique routing requirements that may not met by
=A0existi= ng routing protocols, such as OSPF, IS-IS, AODV and OLSR. For
example path selection must be designed to take into = consideration the
specific power capabilities, = attributes and functional characteristics
of the = links and nodes in the network.

Request = for clarification (a question may or may not follow): is multi-metric = QoS thereby an explicit design = requirement?

Also, it seems from the sentence = construction that it is inferred that "OSPF, IS-IS, AODV and OLSR" do = not have the capability to take "power capabilities, attributes and = functional characteristics of the links and nodes in the network" into = consideration. I'm not sure that that's the entire truth. Can this be = clarified a notch?

The Working Group is focused = on routing issues for = LLN

Alright, so routing issues = only. Fair enough -- but what's the relationship then with the "very = small packet sizes" bullet point above? Do we expect [other-wg] to = resolve this issue, or is there routing-only-issues that need be brought = forward? If so, which?

There is a wide scope of application areas for LLNs, = including
=A0industrial monitoring, = building automation (HVAC, lighting, access
urban sensor networks sensor = networks, assets tracking, refrigeration.
The = Working Group will only focus on routing solutions for a subset = of
these. It will focus on industrial, connected = home, building and urban
=A0sensor networks and specify = the set of routing requirements for
=A0these = scenarios.

Question: does the above = entail "new work", or is this in reference to the current requirement = I-Ds?

The Working Group focuses only = on IPv6 only routing architectural
=A0framework for these = application scenarios.

Question: = by "architectural framework", what exactly is to be = understood?

The Framework will take into consideration = various
=A0aspects including high = reliability in the presence of time varying loss
=A0characteristics and = connectivity while permitting low-power operation
=A0with = very modest memory and CPU pressure in networks potentially
comprising a very large number (several thousands) = of nodes.
The Working Group will explore = aspects of mobility within a single LLN
(if any) = in the routing requirement = creation.

Does this entail a new = "routing requirements" document being = produced?

The Working Group will pay = particular attention to routing security and
manageability (e.g., self configuration) issues. It = will also need to
=A0consider the transport = characteristic the routing protocol messages will
=A0experience.

This goes back to my previous question: IP-over-foo or = ?


More broadly, how are the current = ROLL products (survey I-D, rtg requirements) expected to be employed in = all this?

Finally, in summarizing the charter, = ROLL aims at solving:

o=A0 routing = over wireless
o scalability to several thousands = of routers
o QoS in wireless networks, = including
o formalization of wireless link = metrics
o = security

within 10 months, and to = the level of proposed standard.

The items are = very interesting, but 10 months is also *very* short -- and the = complexity of some of those is not trivial without making serious = concessions in some areas.

Let me cite from an = email from Dave Ward (Feb. 3, 2009)

On Feb 3, = 2009, at 5:52 PM, David Ward wrote:
I expect "wild swings" of the design = pattern of the protocol during the first year of the design = effort.=A0I attempted to make this clear = at the mic in Minneapolis that the current trajectory is very complex = problem domain that hasn't born a lot of fruit but, that in the design = phase reducing the complexity must = occur.=A0

Consid= ering the complexity of the list of items above, I am much more in line = with what Dave Ward writes, than with what the milestones = suggest.

Thomas


Mechanisms that protect an LLN = from congestion collapse or
=A0that establish some degree of = fairness between concurrent communication
sessions = are out of scope of the Working Group. It is expected that
=A0upper-layer applications = utilizing LLNs define appropriate mechanisms.


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
=A0Layer 3 (Routing for LLN = Architecture) that addresses such issues as
whether = LLN routing protocols require a distributed and/or centralized
=A0path = computation models, whether additional hierarchy is necessary = and
how it is applied. Manageability = will be considered with each approach,
=A0along with various trade-offs = for maintaining low power operation,
=A0including the presence of = non-trivial loss and networks with a very
=A0large number of = nodes.


- = Produce a routing security framework for routing in LLNs.

- = Protocol work: In light of the application specific routing = requirements, the Working Group will either specify a new protocol = and/or will select an existing routing protocol (with the appropriate = extensions in cooperation with the relevant Working Group).

- = Documentation of applicability statement of ROLL routing = protocols.

Goals and Milestones:

Done =A0 Submit Routing requirements = for Industrial applications to the IESG to be considered as an = Informational RFC.
Done =A0 Submit=A0 Routing requirements for = Connected Home networks applications to the IESG to be considered as an = Informational RFC.
Done =A0 Submit Routing requirements = for Building applications to the IESG to be considered as an = Informational RFC.
Done =A0 Submit Routing requirements = for Urban networks applications to the IESG to be considered as an = Informational RFC.
July 2009=A0 =A0 Submit Routing metrics = for LLNs document to the IESG to be considered as a Proposed = Standard.
* Feb 2009 =A0 Submit Protocol Survey to the = IESG to be considered as an Informational RFC.
April 2009 =A0 = Submit Security Framework to the IESG to be considered as an = Informational RFC
May 2009 =A0 =A0 Submit the Routing for = LLNs Architecture document to the IESG as an Informational = RFC.
July 2009=A0 =A0 Submit first draft of = ROLL routing protocol specification as Proposed Standard.
Nov 2009 =A0 =A0= Submit first draft of the MIB module of the ROLL routing = protocol specification.
Dec 2009 = =A0 =A0 Submit the ROLL = routing protocol specification to the IESG as Proposed = Standard.
Jan 2010 =A0 =A0 Submit the MIB module of = the ROLL routing protocol specification to the IESG as Proposed = Standard.
Jan 2010 =A0 =A0 Evaluate WG progress, = recharter or close.
PS: I marked * the Milestones = that will be "This Week" and before submitting to the IESG for = re-chartering.




JP and David.
Roll mailing list
=

= --Apple-Mail-2-916401706-- From alexandru.petrescu@gmail.com Mon Feb 16 01:58:21 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8BD028C0FB for ; Mon, 16 Feb 2009 01:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQKll0r3qltb for ; Mon, 16 Feb 2009 01:58:21 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id D9F7228C0E5 for ; Mon, 16 Feb 2009 01:58:20 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1G9ugRT006076; Mon, 16 Feb 2009 10:56:42 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1G9wO8B023071; Mon, 16 Feb 2009 10:58:24 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n1G9wNc8011553; Mon, 16 Feb 2009 10:58:24 +0100 Message-ID: <499938BF.8030409@gmail.com> Date: Mon, 16 Feb 2009 10:58:23 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Thomas Heide Clausen References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> <7F8096B9-1691-44D2-9032-6383C6C765B3@thomasclausen.org> In-Reply-To: <7F8096B9-1691-44D2-9032-6383C6C765B3@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 09:58:21 -0000 Thomas Heide Clausen a écrit : [...] > I can see where Alexandru's question come from at this point, when we > were talking about power-lines and such. > > Essentially, what we're wanting to say [I think] is that "ROLL > protocols MUST be able to run on routers with > [very-strict-set-of-restrictions]" -- and that there then may be a > few routers with "better than [very-strict-set-of-restrictions]" > shouldn't be driving our design, and that such routers are present is > purely incidental. > > IOW, I'd suggest rephrasing this slightly, to say "these are the > requirements that ROLL protocols shall satisfy -- if a device does > better than that, more power to it, but it's not our primary design > target". This rephrasing sounds better to me. I agree to a clearcut distinction between constrained devices and generous devices (generous because they could do better if really there was a need). In this sense, your suggestion to explicitely state that generous devices are not the primary goal sounds good to me. It could crystalize the generic energy-consumption goals, distinguishing between: -routing protocols which should consume less power for their own working (exchange routing protocol packets with few headers, and are short, and less often) -routing protocols which would establish lowest-energy paths (subsequently to routing exchanges the application-level packets will follow paths with lowest energy) -and too generic goal of reducing energy consumption in a building - this could be the Energy Considerations section of every other IETF protocol. Alex From jvasseur@cisco.com Mon Feb 16 02:02:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C08A728C0FB for ; Mon, 16 Feb 2009 02:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UbkNv5UBu0L for ; Mon, 16 Feb 2009 02:02:24 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 20DAE28C0D9 for ; Mon, 16 Feb 2009 02:02:20 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,215,1233532800"; d="scan'208,217";a="33865693" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Feb 2009 10:02:29 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1GA2TvX004375; Mon, 16 Feb 2009 11:02:29 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1GA2TbW008294; Mon, 16 Feb 2009 10:02:29 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 11:02:29 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 11:02:27 +0100 Message-Id: <03CE3732-F1DC-44F4-9A2A-140FAD6CA531@cisco.com> From: JP Vasseur To: Thomas Heide Clausen In-Reply-To: <7F8096B9-1691-44D2-9032-6383C6C765B3@thomasclausen.org> Content-Type: multipart/alternative; boundary=Apple-Mail-29-920793175 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 16 Feb 2009 11:02:27 +0100 References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> <7F8096B9-1691-44D2-9032-6383C6C765B3@thomasclausen.org> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 16 Feb 2009 10:02:27.0931 (UTC) FILETIME=[AC804AB0:01C9901D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=49716; t=1234778549; x=1235642549; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20re-chartering |Sender:=20; bh=2XB0Jdk/1b2i3XSsT5a+h0YzsEnW+IFut1pRBJyBzQQ=; b=OhO+0yB2/njOmFuKquz+a8hv15HA83Zy7O+cfPF0N7LPIRL/sMyvNKS4yS zcjWDzSG39znq0apexhR0tYEUDgs+nY1La8tZhK2Mx3DN966VnVh2Gwq8iBR dpNm9FVnBf; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 10:02:26 -0000 --Apple-Mail-29-920793175 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Thomas, On Feb 16, 2009, at 9:49 AM, Thomas Heide Clausen wrote: > Dear JP, David, ROLL wg, > > (and, as I have a question to Alex, I Cc' him explicitly too) > > I've got a couple of comments to the charter below. I think it needs > a bit of clarification in some areas, and also the relationship to > current ROLL WG products needs to be clarified IMO. See below for > details -- most of which I believe are questions that I raise that > it should be fairly easy for a more experienced person to simply > answer and propose a one-sentence clarification-edit to the charter > to fix. > > On Feb 11, 2009, at 9:08 AM, JP Vasseur wrote: > >> Dear WG, >> >> As indicated in a previous email, the protocol survey I-D will be >> send for publication this week (after posting of the last revision >> incorporating several useful comments). >> >> As promised please find below the new proposed charter to be >> submitted to the IESG for approval. In the hope of getting quickly >> re-chartered thanks to let us know if you have any comment by the >> ned of this week. The new charter is pretty straightforward. >> >> Thanks to Dave Ward for his comments and guidance. >> >> Description of Working Group: >> >> Low power and Lossy networks (LLNs) are typically composed of many >> embedded devices with limited power, memory, and processing resources >> interconnected by a variety of links, such as IEEE 802.15.4, >> Bluetooth, >> Low Power WiFi 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. LLNs >> have specific characteristics: >> - LLNs operate with a hard, very small bound on state, >> - In most cases, LLN need to be optimized for energy saving, > > I am not sure that "in most cases" is entirely clear here. Does this > mean that we can get away with designing an "energy hungry" routing > protocol for ROLL, as long as we specify in which cases it'd apply? Right this means that "energy saving" can be a soft constraint as opposed to a hard constraint with battery operated devices. > I'd be happier getting rid of "in most cases" and replacing "energy > saving" with "energy conservation" or something similar. > OK changing "energy saving" for "energy conservation" >> - Typical traffic patterns are not simply unicast flows, > > This, I have a big question mark to as well. It applies equally to > the survey I-D, but I'll comment on that I-D in another email. > > Essentially, as a protocol designer, I'd expect a wg charter to help > me understand the constraints under which I'd be designing a > protocol. Reading the above item teaches me that I shouldn't design > for "simply unicast flows", but what does that mean? Could I > disregard unicast entirely and just build a multicast protocol? Do I > then need group mgmt? Or is simple "roll-wide broadcast" all that's > needed? Or all of the above? None of the above? > > IOW, we need to be much more specific with what the traffic patterns > then typically would be? We could be more specific on many items but we would end up with a very lengthy charter. These aspects are captured in the routing requirement IDs, which are the IDs where we specify the requirements that the protocol must satisfy. How about .... - Typically traffic patterns are not simply unicast flows (e.g. in some environments most if not all traffic can be point to multipoint) > >> - In most cases, LLNs need to be effective with very small >> packet sizes, > > I've gone back and forth over this, and it's also a comment that I > think needs clarification in the survey I-D. First, I think that > it'd be helpful to say something as to "how small". But we do not want to be PHY/MAC specific. Here we list a general LLN characteristic. > Second, to which extend are we looking at transport [and other] > issues in ROLL. > We do not. This is spelled out below in the charter. > I can read this in different ways, here's my first impulse on that > bullet point: > > o ROLL runs over LLs with an extremely restricted frame-size, so > something akin to > IP header compression is on the table [are we then in RTG?]. > > o Presumably, the "very small packet sizes" also applies for data. > Is this, then, > a generic IP-over-FOO problem? > > I can guess at what the intent would be, but we need to spell it out > here. The former of course ... and in "most cases" (e.g. 15.4). > >> - LLN routing protocols have to be very careful when trading >> off efficiency for generality; many LLN nodes do not have resources >> to waste. > > I can see where Alexandru's question come from at this point, when > we were talking about power-lines and such. > > Essentially, what we're wanting to say [I think] is that "ROLL > protocols MUST be able to run on routers with [very-strict-set-of- > restrictions]" -- and that there then may be a few routers with > "better than [very-strict-set-of-restrictions]" shouldn't be driving > our design, and that such routers are present is purely incidental. > > IOW, I'd suggest rephrasing this slightly, to say "these are the > requirements that ROLL protocols shall satisfy -- if a device does > better than that, more power to it, but it's not our primary design > target". > > Alex, would a rephrasing like this satisfy you? > >> These unique properties lead to unique routing requirements that >> may not met by >> existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For >> example path selection must be designed to take into consideration >> the >> specific power capabilities, attributes and functional >> characteristics >> of the links and nodes in the network. > > Request for clarification (a question may or may not follow): is > multi-metric QoS thereby an explicit design requirement? > That could be the case but again we cannot list all requirements in the charter. They are specified in the requirement documents. > Also, it seems from the sentence construction that it is inferred > that "OSPF, IS-IS, AODV and OLSR" do not have the capability to take > "power capabilities, attributes and functional characteristics of > the links and nodes in the network" into consideration. I'm not sure > that that's the entire truth. Can this be clarified a notch? We do say "existing". Not sure which clarification you want ? > >> The Working Group is focused on routing issues for LLN > > Alright, so routing issues only. Fair enough -- but what's the > relationship then with the "very small packet sizes" bullet point > above? Do we expect [other-wg] to resolve this issue, A good example being 6lowpan. > or is there routing-only-issues that need be brought forward? If so, > which? > This "a" characteristic since you asked to spell out a bit more precisely LLN's characteristics (and this was an excellent idea). An obvious consequence being that the routing protocol cannot afford to send to large frames (in some cases). Detailed requirements again are in application-specific routing requirements documents. >> There is a wide scope of application areas for LLNs, including >> industrial monitoring, building automation (HVAC, lighting, access >> control, fire), connected home, healthcare, environmental monitoring, >> urban sensor networks sensor networks, assets tracking, >> refrigeration. >> The Working Group will only focus on routing solutions for a subset >> of >> these. It will focus on industrial, connected home, building and >> urban >> sensor networks and specify the set of routing requirements for >> these scenarios. > > Question: does the above entail "new work", or is this in reference > to the current requirement I-Ds? Good catch, it should read: "It focuses on industrial, connected home, building and urban sensor networks and specify the set of routing requirements for these scenarios." > >> The Working Group focuses only on IPv6 only routing architectural >> framework for these application scenarios. > > Question: by "architectural framework", what exactly is to be > understood? > A routing architecture ID (pointed out in the WG item). >> 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 explore aspects of mobility within a single >> LLN >> (if any) in the routing requirement creation. > > Does this entail a new "routing requirements" document being produced? > Another good point. We can remove that last sentence. >> The Working Group will pay particular attention to routing security >> and >> manageability (e.g., self configuration) issues. It will also need to >> consider the transport characteristic the routing protocol >> messages will >> experience. > > This goes back to my previous question: IP-over-foo or ? > > > More broadly, how are the current ROLL products (survey I-D, rtg > requirements) expected to be employed in all this? Quite clear: 1) The survey was there to figure out whether *existing* protocol could meet the requirements. The answer is "no" 2) Requirements are used to produce the protocol (extensions or new). > > Finally, in summarizing the charter, ROLL aims at solving: > > o routing over wireless > o scalability to several thousands of routers > o QoS in wireless networks, including > o formalization of wireless link metrics > o security Not just wireless at discussed on the ML, not sure why you mention QoS in wireless network (at most we do QoS routing), ... > > > within 10 months, and to the level of proposed standard. > > The items are very interesting, but 10 months is also *very* short > -- and the complexity of some of those is not trivial without making > serious concessions in some areas. It is aggressive but should we end up extending an existing protocol does not take so much time. The good thing is that we spent a lot of time spelling out all requirements, which will ease the protocol design phase. We can always add a few months to the last milestone. > > Let me cite from an email from Dave Ward (Feb. 3, 2009) > > On Feb 3, 2009, at 5:52 PM, David Ward wrote: >> I expect "wild swings" of the design pattern of the protocol during >> the first year of the design effort. I attempted to make this clear >> at the mic in Minneapolis that the current trajectory is very >> complex problem domain that hasn't born a lot of fruit but, that in >> the design phase reducing the complexity must occur. > > > Considering the complexity of the list of items above, I am much > more in line with what Dave Ward writes, than with what the > milestones suggest. Thanks. JP. > > Thomas > > >> 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. >> >> >> 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 protocols 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: In light of the application specific routing >> requirements, the Working Group will either specify a new protocol >> and/or will select an existing routing protocol (with the >> appropriate extensions in cooperation with the relevant Working >> Group). >> >> - Documentation of applicability statement of ROLL routing protocols. >> >> Goals and Milestones: >> >> Done Submit Routing requirements for Industrial applications to >> the IESG to be considered as an Informational RFC. >> Done Submit Routing requirements for Connected Home networks >> applications to the IESG to be considered as an Informational RFC. >> Done Submit Routing requirements for Building applications to the >> IESG to be considered as an Informational RFC. >> Done Submit Routing requirements for Urban networks applications >> to the IESG to be considered as an Informational RFC. >> July 2009 Submit Routing metrics for LLNs document to the IESG >> to be considered as a Proposed Standard. >> * Feb 2009 Submit Protocol Survey to the IESG to be considered as >> an Informational RFC. >> April 2009 Submit Security Framework to the IESG to be considered >> as an Informational RFC >> May 2009 Submit the Routing for LLNs Architecture document to >> the IESG as an Informational RFC. >> July 2009 Submit first draft of ROLL routing protocol >> specification as Proposed Standard. >> Nov 2009 Submit first draft of the MIB module of the ROLL >> routing protocol specification. >> Dec 2009 Submit the ROLL routing protocol specification to the >> IESG as Proposed Standard. >> Jan 2010 Submit the MIB module of the ROLL routing protocol >> specification to the IESG as Proposed Standard. >> Jan 2010 Evaluate WG progress, recharter or close. >> >> PS: I marked * the Milestones that will be "This Week" and before >> submitting to the IESG for re-chartering. >> >> >> >> Thanks. >> >> JP and David. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > --Apple-Mail-29-920793175 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Thomas,

On = Feb 16, 2009, at 9:49 AM, Thomas Heide Clausen wrote:

Dear JP, David, ROLL = wg,

(and, as I have a question to Alex, I Cc' him = explicitly too)

I've got a couple of comments to the = charter below. I think it needs a bit of clarification in some areas, = and also the relationship to current ROLL WG products needs to be = clarified IMO. See below for details -- most of which I believe are = questions that I raise that it should be fairly easy for a more = experienced person to simply answer and propose a one-sentence = clarification-edit to the charter to = fix.

On Feb 11, 2009, at 9:08 AM, JP = Vasseur wrote:

Dear WG,

As = indicated in a previous email, the protocol survey I-D will be send for = publication this week (after posting of the last revision incorporating = several useful comments).

As promised please find below = the new proposed charter to be submitted to the IESG for approval. In = the hope of getting quickly re-chartered thanks to let us know if you = have any comment by the ned of this week. The new charter is pretty = straightforward.

Thanks to Dave Ward for his comments and = guidance.

Description of Working Group:

Low = power and Lossy networks (LLNs) are typically composed of many
embedded devices with limited power, memory, and = processing resources
interconnected by a variety = of links, such as IEEE 802.15.4, Bluetooth,
Low = Power WiFi 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
-       LLNs operate = with a hard, very small bound on state,
-       In most = cases, LLN need to be optimized for energy = saving,

I am not sure that "in most = cases" is entirely clear here. Does this mean that we can get away with = designing an "energy hungry" routing protocol for ROLL, as long as we = specify in which cases it'd apply? =

Right this = means that "energy saving" can be a soft constraint as opposed to a hard = constraint with battery operated devices.

I'd be = happier getting rid of "in most cases" and replacing "energy saving" = with "energy conservation" or something = similar.


OK changing "energy saving" for "energy = conservation"

-   =     Typical traffic patterns are not simply unicast = flows,

This, I have a big question mark = to as well. It applies equally to the survey I-D, but I'll comment on = that I-D in another email.

Essentially, as a = protocol designer, I'd expect a wg charter to help me understand the = constraints under which I'd be designing a protocol. Reading the above = item teaches me that I shouldn't design for "simply unicast flows", but = what does that mean? Could I disregard unicast entirely and just build a = multicast protocol? Do I then need group mgmt? Or is simple "roll-wide = broadcast" all that's needed? Or all of the above? None of the = above?

IOW, we need to be much more specific = with what the traffic patterns then typically would = be?

We could be = more specific on many items but we would end up with a = very lengthy charter. These aspects are captured in the = routing requirement IDs, which are the IDs where we specify the = requirements that the protocol must = satisfy.

How about = ....

- Typically traffic patterns are not = simply unicast flows (e.g. in some environments most if not = all traffic can be point to multipoint)

-   =     In most cases, LLNs need to be effective with very = small packet sizes,

I've gone back = and forth over this, and it's also a comment that I think needs = clarification in the survey I-D. First, I think that it'd be helpful to = say something as to "how small". =

But we do = not want to be PHY/MAC specific. Here we list a general = LLN characteristic. 

Second, to = which extend are we looking at transport [and other] issues in = ROLL.


We do not. This is spelled out below in the = charter.

I can read this in different = ways, here's my first impulse on that bullet = point:

o ROLL runs over LLs with an = extremely restricted frame-size, so something akin = to 
IP header = compression is on the table [are we then in = RTG?].

o Presumably, the "very small = packet sizes" also applies for data. Is this, then,
a = generic IP-over-FOO problem?

I can guess at = what the intent would be, but we need to spell it out = here.

The = former of course ... and in "most cases" (e.g. = 15.4).


-       LLN routing = protocols have to be very careful when trading off efficiency for = generality; many LLN nodes do not have resources to = waste.

I can see where Alexandru's = question come from at this point, when we were talking about power-lines = and such.

Essentially, what we're wanting to = say [I think] is that "ROLL protocols MUST be able to run on routers = with [very-strict-set-of-restrictions]" -- and that there then may be a = few routers with "better than [very-strict-set-of-restrictions]" = shouldn't be driving our design, and that such routers are present is = purely incidental.

IOW, I'd suggest rephrasing = this slightly, to say "these are the requirements that ROLL protocols = shall satisfy -- if a device does better than that, more power to it, = but it's not our primary design target".

Alex, = would a rephrasing like this satisfy = you?

These unique properties lead = to unique routing requirements that may not met by
 existing routing protocols, = such as OSPF, IS-IS, AODV and OLSR. For
example = path selection must be designed to take into consideration the
specific power capabilities, attributes and = functional characteristics
of the links = and nodes in the network.

Request for = clarification (a question may or may not follow): is multi-metric QoS = thereby an explicit design = requirement?


<= /div>
That could be the case but again we cannot list all = requirements in the charter. They are specified in the requirement = documents.

Also, it seems from the sentence = construction that it is inferred that "OSPF, IS-IS, AODV and OLSR" do = not have the capability to take "power capabilities, attributes and = functional characteristics of the links and nodes in the network" into = consideration. I'm not sure that that's the entire truth. Can this be = clarified a = notch?

We do say = "existing". Not sure which clarification you want ?

The Working Group is focused = on routing issues for = LLN

Alright, so routing issues = only. Fair enough -- but what's the relationship then with the "very = small packet sizes" bullet point above? Do we expect [other-wg] to = resolve this issue, =

A good example = being 6lowpan.

or is there routing-only-issues that = need be brought forward? If so, = which?


<= div>This "a" characteristic since you asked to spell out a bit = more precisely LLN's characteristics (and this was an = excellent idea). An obvious consequence being that the routing protocol = cannot afford to send to large frames (in some cases). Detailed = requirements again are in application-specific routing requirements = documents.
There is a wide scope of application areas for LLNs, = including
 industrial monitoring, = building automation (HVAC, lighting, access
urban sensor networks sensor = networks, assets tracking, refrigeration.
The = Working Group will only focus on routing solutions for a subset = of
these. It will focus on industrial, connected = home, building and urban
 sensor networks and specify = the set of routing requirements for
 these = scenarios.

Question: does the above = entail "new work", or is this in reference to the current requirement = I-Ds?

Good = catch, it should read: "It focuses on industrial, connected home, = building and urban sensor networks and specify the set of routing = requirements for these scenarios."

The Working Group focuses only = on IPv6 only routing architectural
 framework for these = application scenarios.

Question: = by "architectural framework", what exactly is to be = understood?

=
A routing architecture ID (pointed out in the WG = item).

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 explore aspects of mobility = within a single LLN
(if any) in the routing = requirement creation.

Does this entail = a new "routing requirements" document being = produced?


Another good point. We can remove that last = sentence.

The Working Group will pay = particular attention to routing security and
manageability (e.g., self configuration) issues. It = will also need to
 consider the transport = characteristic the routing protocol messages will
 experience.

This goes back to my previous question: IP-over-foo = or ?


More broadly, how are the = current ROLL products (survey I-D, rtg requirements) expected to be = employed in all = this?

Quite = clear:
1) The survey was there to figure out whether = *existing* protocol could meet the requirements. The answer is = "no"
2) Requirements are used to produce the protocol = (extensions or new).

= o  = routing over wireless
o scalability to several thousands = of routers
o QoS in wireless networks, = including
o formalization of wireless link = metrics
o = security

No= t just wireless at discussed on the ML, not sure why you mention QoS in = wireless network (at most we do QoS routing), ...


Let me cite from an = email from Dave Ward (Feb. 3, 2009)

On Feb 3, = 2009, at 5:52 PM, David Ward wrote:
I expect "wild swings" of the design = pattern of the protocol during the first year of the design = effort. I attempted to make this clear = at the mic in Minneapolis that the current trajectory is very complex = problem domain that hasn't born a lot of fruit but, that in the design = phase reducing the complexity must = occur. 

Con= sidering the complexity of the list of items above, I am much more in = line with what Dave Ward writes, than with what the milestones = suggest.

Thanks.

JP.

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.


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 protocols 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: In light of the application specific routing = requirements, the Working Group will either specify a new protocol = and/or will select an existing routing protocol (with the appropriate = extensions in cooperation with the relevant Working Group).

- = Documentation of applicability statement of ROLL routing = protocols.

Goals and Milestones:

Done   Submit Routing = requirements for Industrial applications to the IESG to be considered as = an Informational RFC.
Done   Submit  Routing requirements for = Connected Home networks applications to the IESG to be considered as an = Informational RFC.
Done   Submit Routing = requirements for Building applications to the IESG to be considered as = an Informational RFC.
Done   Submit Routing = requirements for Urban networks applications to the IESG to be = considered as an Informational RFC.
July = 2009    Submit = Routing metrics for LLNs document to the IESG to be considered as a = Proposed Standard.
* Feb 2009   Submit Protocol Survey to = the IESG to be considered as an Informational RFC.
April 2009   Submit Security Framework = to the IESG to be considered as an Informational RFC
May 2009   =   Submit the Routing for LLNs Architecture document to the = IESG as an Informational RFC.
July = 2009    Submit = first draft of ROLL routing protocol specification as Proposed = Standard.
Nov 2009     Submit first draft = of the MIB module of the ROLL routing protocol specification.
Dec 2009   =   Submit the ROLL routing protocol specification to the IESG = as Proposed Standard.
Jan 2010     Submit the MIB = module of the ROLL routing protocol specification to the IESG as = Proposed Standard.
Jan 2010     Evaluate WG = progress, recharter or close.

PS: I marked * the Milestones = that will be "This Week" and before submitting to the IESG for = re-chartering.




JP and David.
Roll mailing list
=


= --Apple-Mail-29-920793175-- From alexandru.petrescu@gmail.com Mon Feb 16 02:04:10 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F81528C0FB; Mon, 16 Feb 2009 02:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aZJAAtkykV0; Mon, 16 Feb 2009 02:04:09 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 8C1D928C0F1; Mon, 16 Feb 2009 02:04:09 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1GA49LB027083; Mon, 16 Feb 2009 11:04:09 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1GA49Nd031239; Mon, 16 Feb 2009 11:04:09 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n1GA48SV014361; Mon, 16 Feb 2009 11:04:09 +0100 Message-ID: <49993A18.1040500@gmail.com> Date: Mon, 16 Feb 2009 11:04:08 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: JP Vasseur References: <49958529.5010306@gmail.com> <89BA3B32-421E-4A24-B075-B5518E78FD35@cisco.com> <49958D92.5040503@gmail.com> <8157AC22-684F-4FA9-8240-AA481A404F22@cisco.com> In-Reply-To: <8157AC22-684F-4FA9-8240-AA481A404F22@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "roll-bounces@ietf.org" , "David E. Culler" , ROLL WG Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 10:04:10 -0000 JP Vasseur a écrit : > > On Feb 13, 2009, at 4:11 PM, Alexandru Petrescu wrote: > >> JP Vasseur a écrit : >>> Hi Lars, >>> On Feb 13, 2009, at 3:57 PM, Lars Eggert wrote: >>>> Hi, >>>> >>>> On 2009-2-13, at 16:40, JP Vasseur wrote: >>>>> On Feb 13, 2009, at 3:35 PM, Alexandru Petrescu wrote: >>>>>> Jerald - ok, PLC is important. It's related to routing and energy >>>>>> transportation. >>>>>> >>>>>> But. It doesn't sound as PLC devices having limited power, they sit >>>>>> on more power than they'd ever need. >>>>> >>>>> As I tried to explain before, still you want these device to consume >>>>> as less energy as possible (e.g few dozens of mW) >>>>> thus there are constrained. If you have a house and want to do energy >>>>> management you could not afford to have all >>>>> these device consume 3W each. >>>> >>>> I get the part about still wanting to have very low power >>>> consumption in PLC scenarios, but ROLL is currently chartered to >>>> look at routing for low-powered *and lossy* networks. >>>> >>> Well these low power PLC technologies and also loosy. >> >> Well it's obvious wired communications aren't as lossy as wireless >> communications. >> > > do not think so ... I could provide you many pointers if you will. Is this saying that wireless _and_ wired communications are lossy? In this sense all links are lossy, and all protocols designed for them have taken that into account. Alex From alexandru.petrescu@gmail.com Mon Feb 16 02:07:41 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75BBF28C0FA; Mon, 16 Feb 2009 02:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8LaT4k90mnm; Mon, 16 Feb 2009 02:07:40 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 6B7DB28C0F6; Mon, 16 Feb 2009 02:07:40 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1GA64RG015326; Mon, 16 Feb 2009 11:06:04 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1GA7j8j004271; Mon, 16 Feb 2009 11:07:46 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n1GA7jHK020700; Mon, 16 Feb 2009 11:07:45 +0100 Message-ID: <49993AF1.5000206@gmail.com> Date: Mon, 16 Feb 2009 11:07:45 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: JP Vasseur References: <49958529.5010306@gmail.com> <499590B6.3000305@gmail.com> <467AA005-8C2F-4505-8279-56179B7CAF85@cisco.com> In-Reply-To: <467AA005-8C2F-4505-8279-56179B7CAF85@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG , roll-bounces@ietf.org, "David E. Culler" Subject: Re: [Roll] PLC discussion X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 10:07:41 -0000 JP Vasseur a écrit : > changing the title ... since this is not about the charter > > On Feb 13, 2009, at 4:24 PM, Alexandru Petrescu wrote: > >> JP Vasseur a écrit : >>> On Feb 13, 2009, at 3:35 PM, Alexandru Petrescu wrote: >>>> Jerald - ok, PLC is important. It's related to routing and energy >>>> transportation. >>>> But. It doesn't sound as PLC devices having limited power, they sit >>>> on more power than they'd ever need. >>> As I tried to explain before, still you want these device to consume >>> as less energy as possible (e.g few dozens of mW) thus there are >>> constrained. If you have a house and want to do energy management you >>> could not afford to have all these device consume 3W each. >> >> The problem here is _not_ to reduce the energy consumption in house. > > Yes it is ... look at smart grid operation (DR, DSM, ...) Well yes, I agree, there are many activities trying to reduce energy consumption in household, server farm and more. The question is how to distinguish all these activities because not all could be addressed in a humble IETF WG. >> It is to have routing work on small naturally-low-power devices - > > Right and because we have constraints on energy consumption you end up > with constrained devices. I think there's a difference between devices which couldn't do better than what their AA battery allowed them to, and devices which could do better if they were energy-minded. Alex From jvasseur@cisco.com Mon Feb 16 02:07:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B43928C0FA; Mon, 16 Feb 2009 02:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1ME7KJY7ZAV; Mon, 16 Feb 2009 02:07:52 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7C77F28C0F1; Mon, 16 Feb 2009 02:07:51 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,215,1233532800"; d="scan'208";a="33866685" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Feb 2009 10:07:03 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1GA72U8006641; Mon, 16 Feb 2009 11:07:02 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1GA6WnB010439; Mon, 16 Feb 2009 10:07:02 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 11:07:02 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 11:07:00 +0100 Message-Id: <3833CB70-C16B-4C4F-B569-E8438BE1BD26@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <49993A18.1040500@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 16 Feb 2009 11:07:00 +0100 References: <49958529.5010306@gmail.com> <89BA3B32-421E-4A24-B075-B5518E78FD35@cisco.com> <49958D92.5040503@gmail.com> <8157AC22-684F-4FA9-8240-AA481A404F22@cisco.com> <49993A18.1040500@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 16 Feb 2009 10:07:00.0941 (UTC) FILETIME=[4F3A4FD0:01C9901E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1835; t=1234778823; x=1235642823; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20re-chartering |Sender:=20; bh=a/gZ2sKptji+8loCyC3N3Db0QKi5QgJ0q969CdJ+I5o=; b=sIos+CShCE5mA9nk6g8z56DyFf9Z8PhDe1BegI5UxIlp79qbHVt03gtVrA C8+FDM4UI2TSueSfGXtOxnYcieDqWd6NcAhMRUmf2Yv5cIU3SfUkdKAPR3Dk E5B2E66agm; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG , "David E. Culler" , "roll-bounces@ietf.org" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 10:07:53 -0000 On Feb 16, 2009, at 11:04 AM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> On Feb 13, 2009, at 4:11 PM, Alexandru Petrescu wrote: >>> JP Vasseur a =E9crit : >>>> Hi Lars, >>>> On Feb 13, 2009, at 3:57 PM, Lars Eggert wrote: >>>>> Hi, >>>>> >>>>> On 2009-2-13, at 16:40, JP Vasseur wrote: >>>>>> On Feb 13, 2009, at 3:35 PM, Alexandru Petrescu wrote: >>>>>>> Jerald - ok, PLC is important. It's related to routing and =20 >>>>>>> energy >>>>>>> transportation. >>>>>>> >>>>>>> But. It doesn't sound as PLC devices having limited power, =20 >>>>>>> they sit >>>>>>> on more power than they'd ever need. >>>>>> >>>>>> As I tried to explain before, still you want these device to =20 >>>>>> consume >>>>>> as less energy as possible (e.g few dozens of mW) >>>>>> thus there are constrained. If you have a house and want to do =20= >>>>>> energy >>>>>> management you could not afford to have all >>>>>> these device consume 3W each. >>>>> >>>>> I get the part about still wanting to have very low power =20 >>>>> consumption in PLC scenarios, but ROLL is currently chartered to =20= >>>>> look at routing for low-powered *and lossy* networks. >>>>> >>>> Well these low power PLC technologies and also loosy. >>> >>> Well it's obvious wired communications aren't as lossy as wireless =20= >>> communications. >>> >> do not think so ... I could provide you many pointers if you will. > > Is this saying that wireless _and_ wired communications are lossy? =20= > In this sense all links are lossy, and all protocols designed for =20 > them have taken that into account. Many people tried to provide you answer. We mean that LLNs can be made =20= of lossy wired links, yes. Which does not mean that all wired links =20 are lossy of course ... JP. > > > Alex > > From jvasseur@cisco.com Mon Feb 16 02:08:52 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6555828C0F6 for ; Mon, 16 Feb 2009 02:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sW1AnzIZbXyH for ; Mon, 16 Feb 2009 02:08:51 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id CC58C28C0F1 for ; Mon, 16 Feb 2009 02:08:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,215,1233532800"; d="scan'208";a="33866828" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 16 Feb 2009 10:08:00 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1GA805H025672; Mon, 16 Feb 2009 11:08:00 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1GA80Vv011043; Mon, 16 Feb 2009 10:08:00 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 11:08:00 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 11:07:59 +0100 Message-Id: <906CC3B7-E1D2-428A-BF1F-BDBB676DA088@cisco.com> From: JP Vasseur To: Alexandru Petrescu , Thomas Heide Clausen In-Reply-To: <499938BF.8030409@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 16 Feb 2009 11:07:59 +0100 References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> <7F8096B9-1691-44D2-9032-6383C6C765B3@thomasclausen.org> <499938BF.8030409@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 16 Feb 2009 10:07:59.0627 (UTC) FILETIME=[723515B0:01C9901E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1827; t=1234778880; x=1235642880; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20re-chartering |Sender:=20; bh=xZBrxgFvCL/c1tiMqMOE2vtxNbspPF2+UQW9mYYfgmI=; b=pozorWHa2FSwWEFQbe4KD3Oe7Ip06hSdTPTTK9mjNtMzEBkLnZtcs5+h3t IqwuK8JicnIRKZPipsFjjxcqrEvEu3JBDy0SkhGw+O0gq2lsSTOsV7LQ3cVm Wzq6DUtq4e; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 10:08:52 -0000 On Feb 16, 2009, at 10:58 AM, Alexandru Petrescu wrote: > Thomas Heide Clausen a =E9crit : > [...] >> I can see where Alexandru's question come from at this point, when we >> were talking about power-lines and such. >> Essentially, what we're wanting to say [I think] is that "ROLL =20 >> protocols MUST be able to run on routers with [very-strict-set-of-=20 >> restrictions]" -- and that there then may be a few routers with =20 >> "better than [very-strict-set-of-restrictions]" shouldn't be =20 >> driving our design, and that such routers are present is >> purely incidental. >> IOW, I'd suggest rephrasing this slightly, to say "these are the =20 >> requirements that ROLL protocols shall satisfy -- if a device does =20= >> better than that, more power to it, but it's not our primary design =20= >> target". > > This rephrasing sounds better to me. What is exactly the proposed rephrasing ? > I agree to a clearcut distinction > between constrained devices and generous devices (generous because =20 > they > could do better if really there was a need). In this sense, your > suggestion to explicitely state that generous devices are not the > primary goal sounds good to me. > > It could crystalize the generic energy-consumption goals, =20 > distinguishing > between: > -routing protocols which should consume less power for their own > working (exchange routing protocol packets with few headers, and are > short, and less often) > -routing protocols which would establish lowest-energy paths > (subsequently to routing exchanges the application-level packets > will follow paths with lowest energy) > -and too generic goal of reducing energy consumption in a building - > this could be the Energy Considerations section of every other IETF > protocol. > > Alex > From alexandru.petrescu@gmail.com Mon Feb 16 02:13:46 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2069328C0F7; Mon, 16 Feb 2009 02:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.058 X-Spam-Level: X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlKqqc6vwu8b; Mon, 16 Feb 2009 02:13:45 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 1EE7028C0F1; Mon, 16 Feb 2009 02:13:44 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1GADo1r000742; Mon, 16 Feb 2009 11:13:50 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1GADnqk015570; Mon, 16 Feb 2009 11:13:49 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n1GADnaZ023451; Mon, 16 Feb 2009 11:13:49 +0100 Message-ID: <49993C5D.8050700@gmail.com> Date: Mon, 16 Feb 2009 11:13:49 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Daniel Smolinski References: <49958529.5010306@gmail.com> <7BDC023EB136F0499F260228BE2991BC2C23D8@rte-rat-exch.RTE.ADWIN.RENESAS.COM> In-Reply-To: <7BDC023EB136F0499F260228BE2991BC2C23D8@rte-rat-exch.RTE.ADWIN.RENESAS.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll-bounces@ietf.org, "David E. Culler" , ROLL WG Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 10:13:46 -0000 Daniel Smolinski a écrit : > Hi all, > > Actually, from in the field experience, PLC can be quite a lossy > communication technology. We have seen many cases where influence > from appliances (e.g. microwave ovens) can cause disturbances on the > power line that makes communication impossible for some time. Also, > many PLC links are asymmetrical. That's good to know and other influences are related to the number of devices plugged into a same wall socket. But these are warnings posted on red stickers telling how to properly set up a PLC network. I'm not sure a layer-3 routing protocol should address these. > While I agree that the low-power requirement can be seen either way, > my experience tells me that PLC is definitely experiencing the same > problems as do wireless networks. It's true, wireless networks often seem non-deterministic in behaviour, as wireless links do often. It's also very important to build a deterministic behaviour wireless link-layer, with link-layer solutions. When that is achieved, a layer-3 routing protocol is able to better run on top of it. Alex From alexandru.petrescu@gmail.com Mon Feb 16 02:21:44 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E009F3A67C0; Mon, 16 Feb 2009 02:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOegCyy5EiEH; Mon, 16 Feb 2009 02:21:44 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id DC6253A6BFB; Mon, 16 Feb 2009 02:21:43 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1GAK7X0002212; Mon, 16 Feb 2009 11:20:07 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1GALm8i004924; Mon, 16 Feb 2009 11:21:48 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n1GALl5C026864; Mon, 16 Feb 2009 11:21:48 +0100 Message-ID: <49993E3B.70509@gmail.com> Date: Mon, 16 Feb 2009 11:21:47 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: JP Vasseur References: <49958529.5010306@gmail.com> <89BA3B32-421E-4A24-B075-B5518E78FD35@cisco.com> <49958D92.5040503@gmail.com> <8157AC22-684F-4FA9-8240-AA481A404F22@cisco.com> <49993A18.1040500@gmail.com> <3833CB70-C16B-4C4F-B569-E8438BE1BD26@cisco.com> In-Reply-To: <3833CB70-C16B-4C4F-B569-E8438BE1BD26@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "roll-bounces@ietf.org" , "David E. Culler" , ROLL WG Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 10:21:45 -0000 JP Vasseur a écrit : > > On Feb 16, 2009, at 11:04 AM, Alexandru Petrescu wrote: > >> JP Vasseur a écrit : >>> On Feb 13, 2009, at 4:11 PM, Alexandru Petrescu wrote: >>>> JP Vasseur a écrit : >>>>> Hi Lars, On Feb 13, 2009, at 3:57 PM, Lars Eggert wrote: >>>>>> Hi, >>>>>> >>>>>> On 2009-2-13, at 16:40, JP Vasseur wrote: >>>>>>> On Feb 13, 2009, at 3:35 PM, Alexandru Petrescu wrote: >>>>>>>> Jerald - ok, PLC is important. It's related to routing >>>>>>>> and energy transportation. >>>>>>>> >>>>>>>> But. It doesn't sound as PLC devices having limited >>>>>>>> power, they sit on more power than they'd ever need. >>>>>>> >>>>>>> As I tried to explain before, still you want these device >>>>>>> to consume as less energy as possible (e.g few dozens of >>>>>>> mW) thus there are constrained. If you have a house and >>>>>>> want to do energy management you could not afford to have >>>>>>> all these device consume 3W each. >>>>>> >>>>>> I get the part about still wanting to have very low power >>>>>> consumption in PLC scenarios, but ROLL is currently >>>>>> chartered to look at routing for low-powered *and lossy* >>>>>> networks. >>>>>> >>>>> Well these low power PLC technologies and also loosy. >>>> >>>> Well it's obvious wired communications aren't as lossy as >>>> wireless communications. >>>> >>> do not think so ... I could provide you many pointers if you >>> will. >> >> Is this saying that wireless _and_ wired communications are lossy? >> In this sense all links are lossy, and all protocols designed for >> them have taken that into account. > > Many people tried to provide you answer. We mean that LLNs can be > made of lossy wired links, yes. Which does not mean that all wired > links are lossy of course ... JP, To explain: if a link is lossy, frustratingly non-deterministic, it may very well be because it's not correctly set up. In this sense, this lossiness is not relevant to any routing protocol. Lossiness of PLC links could be avoided by setting them up properly, don't plug the microwave oven if the manufacturer says so. I think that lossiness aspect is fundamentally different than lossiness aspect of battery-powered and 300Kb bluetooth 10m range as stated by its manufacturer. Alex From eunah.ietf@gmail.com Mon Feb 16 02:28:52 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 501443A69A3; Mon, 16 Feb 2009 02:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z78qn4IDqA9u; Mon, 16 Feb 2009 02:28:50 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id 50BED3A6BFB; Mon, 16 Feb 2009 02:28:50 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1454085rvb.49 for ; Mon, 16 Feb 2009 02:28:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vQypir/5yCKIRPmBhZUW3UgAuJ9bkkJtV9Dl+9GsGps=; b=gCWc4OoRL1RKKcJuRsf1vGpZb1zxac3WWw0+MJimFVA4l3l5qeuGjGSIO3o4iaWval MNC2FTjBNZxW05PI6Ek/+OUOl5H2H291fd5SW2teiSeiRlrzNSmE6vH3IzsBLLYHthbm ZR9epIyx07JGJN4dbvmbwLH4vDGjgZ6UpwMWQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=iwiGNMZ9YjRptZZE80AX78KHagULhWqbzd47FiqIn6nB2HnLeVVNITVWAWEZk9KDz+ U4q8DanM2QAPevHKL4b2/CcFvddMW/jpc5iKvy/Ssm79AKTugOng+IUKABw1kDESYkz9 0Q4IvPKP/o3vT3dsvj4eUbkyys1qB/opFfqaU= MIME-Version: 1.0 Received: by 10.141.26.19 with SMTP id d19mr1204925rvj.184.1234780139359; Mon, 16 Feb 2009 02:28:59 -0800 (PST) In-Reply-To: <4992FD7F.8070408@gmail.com> References: <4992FD7F.8070408@gmail.com> Date: Mon, 16 Feb 2009 19:28:59 +0900 Message-ID: <77f1dba80902160228s4b25285ageb085c51c402fd40@mail.gmail.com> From: "Eunsook \"Eunah\" Kim" To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ROLL WG , 6lowpan@ietf.org Subject: Re: [Roll] Comments on draft-ietf-6lowpan-routing-requirements-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 10:28:52 -0000 Dear Alex, Thank again for your detail comments. As I told you before, it helps us to refine our draft. Some of your comments are about fundamental of 6LoWPAN, so I guess other 6LoWPANers may help me to give you some answers. Anyway, I put my thoughts in line. On Thu, Feb 12, 2009 at 1:31 AM, Alexandru Petrescu wrote: > [Where should I post this message, to 6LoWPAN or to ROLL list? Both?] > > Dear WG members, > > draft-ietf-6lowpan-routing-requirements-00 lists a Problem Statement, > some Scenarios and a set of Routing Requirements. Generally I find it a > well written document, with many meaningful details. > Thank you very much for your possitive comments. :) > There are very many parts of this document to which I silently agree, > even some parts I wholehartedly agree. I like the distinction > route-above mesh-under, and many other parts too. Thanks again. :) > > Some high-level questions: > -is there a requirement to connect a 6LoWPAN network to the Internet? Do you mean in terms of routing? Or a general view of 6LoWPAN? The birth of 6LoWPAN is to make the Low-power low rate network (based on IEEE 802.15.4) look like an IPv6 link. If you only meant routing, the reachability can be achieved by mesh routing (or mesh switching in your comment below) or route-over. I don't know if it answers your question. > -is the 6LoWPAN using addressing architecture and longest-prefix match > based routing as in the Internet? Alex, I think RFC 4944 may help your curiosity of 6lowpan fundamental. Although the header compression format is updating in 6lowpan now, you can find a basic needs of 6lowpan in the RFC. If I shortly explain, an IPv6 Interface Identifier is obtained from the 64-bit or 16-bit IEEE 802.15.4 address. The IPv6 link-local address for an IEEE 802.15.4 interface is formed by appending the Interface Identifier to a certain prefix (see Section 6 and Section 7 of RFC 4944). With regard to routing, I understand the answer is 'yes' in the case of route-over. Please kindly let me know if you already checked the RFC and your intention from the question was different from my answer. :) > -how many interfaces will a 15.4 device have potentially? > Well, currently, as I follow up, one interface only for a sensor node in 6LoWPAN. A gateway usually have more than one interface (e.g., 15.4 + 802.11 or others). > Following are detail questions and comments. I believe they're not as > important as the items mentioned above. > >> 1. Problem Statement > > Is this _the_ problem statement or should I better go read > draft-ietf-6lowpan-problem-08? They differ largely... First of all, just for your information, draft-ietf-6lowpan-problem-08 is now RFC 4919. The section 1, problem statement of our draft is focusing on routing in 6LoWPANs, and RFC 4919 states general problem of 6LoWPAN, including a brief requirement as you refered in the below. > >> The 6LoWPAN problem statement document ("6LoWPAN Problems and Goals" [3]) >> briefly mentions four requirements on routing protocols; >> >> (a) low overhead on data packets >> >> (b) low routing overhead > > > What is routing more generally? Is it the act a router performs when > presenting with a packet, searching in a routing table, maybe exploring > its ND structures, maybe sending ND messages and then emitting the packet? > > Or is it exchanging IP datagrams containing prefixes and metrics and > reachability information, such that nodes have a common view of the > network paths? I would say that it include all the functionalities needed for the selection of a path from source to destination. However, I should be careful use the term 'router' here. Although 6lowpan nodes may perform such routing functionality for the reachability, it's different from traditional term of 'router'. In route-over, they call 6lowpan nodes performing routing as 'routers' - One radio hop is a single IP link. However, in mesh-under, only one 6lowpan router exists in one 6lowpan (ER in Figure 2 of the draft) - Whole 6lowpan is One IPv6 link. To cover the both case, please understand in this way; 6LoWPAN node may perform such a 'routing-related functionalities'. > > I think this is worth discussing, in order to better target what the > work should follow this problem statement and reqs. > > Are the low overhead requirements put on the database construction > messages? Or on the individual act of forwarding a packet? I would say 'on both'. > >> On the other hand, the route-over approach relies on IP routing and >> therefore supports routing over possibly various types of interconnected >> links (see also Figure 1). > > At several places in the draft, when link 'types', device 'types' are > mentioned, I'm tempted to believe 6LoWPAN considers links other than > 802.15.4 links? Is it so? Should 6LoWPAN routing protocol work also > with aseptic point-to-point links? > Or are the 'types' limited within the relatively large scope of 802.3 > compatible MACs (I believe 802.15.4 and 802.16 to fit within). > > This is of paramount importance in setting the scope. > Oh, link 'type'. ;) Currently 6lowpan is clearly based on 802.15.4, although some talks that 6LoWPAN can run on top of other radios with similar characteristics. And, for route-over (as ROLL WG is working on), the benefit which have been insisted is that the routing mechanism is link-independent. Mesh-under of 6lowpan is 802.15.4 dependent. But I don't know what is 'aseptic' point to point links. >> The most significant consequence of mesh-under routing is that routing >> would be directly based on the IEEE 802.15.4 standard, > > Which 'routing' is directly based on 802.15.4 standard? The 'IP > routing' is based on that standard? This brings back to defining what > routing is. > Ah~ I think we should change the wording. I meant that the requirements of 6lowpan routing inherit the stringent characterisitcs of 802.15.4. I will change the text to make it clear. Thanks. :) > Maybe better call 'mesh-under routing' 'mesh-under switching'. > > IP routing and addressing may be fundamentally different than mesh-under > addressing and switching - in the way hosts get and maintain their > addresses and in the way routers/switches search their databases (exact > match vs longest-prefix). > Agreed. Either term is okay by me. Just due to the specific characteristics of 6lowpan configuration, multi-hop path selection can be achieved in mesh-under. I will ask others if mesh-under switching is better to be clarified. >> When a route-over protocol is built in the IPv6 layer, the Dispatch value >> can be chosen as one of the Dispatch patterns for 6LoWPAN, compressed or >> uncompressed IPv6, followed by the IPv6 header. > > > Sorry, I can't parse this. > > A route-over protocol would act both at IP layer and > application/transport layers. Depends what a routing protocol is. For > example ICMP Redirect, or NEMOv6 or ND act at IP layer, whereas RIPng is > over UDP. > > 'followed by'... when reading left to right or reverse? > When I read the text again, it can be confusing. I will try to rephrase it. 6LoPWAN provides compressed or uncompressed IPv6 header. It just wants to explain the relationship between 6lowpan header and routing header. You will get the information from RFC 4944. >> For route-over, a default route to the ER could be inserted into the >> routing system. > > In the routing system of the 6LoWPAN network? Or in the routing system > of the fixed Internet network? 6lowpan. I will also try to rephrase it to be clear. thanks. :) > >> IP-based low-power WPAN technology is still in its early stage of > > 'WPAN'? > wireless personal area network. 6lowpan = IPv6 over Low power WPAN. But, actually i think it's better to just use 6LoWPAN, to keep the consistancy of the document. I will change it. >> a. Network Properties: >> >> * Number of Devices, Density and Network Diameter: These parameters >> usually affect the routing state directly (e.g. the number of >> entries in a routing table or neighbor list). Especially in large >> and dense networks, policies must > > What is 'large' and 'dense'? Is it about physical dimensions? Or IP > dimensions? It is about physical dimensions. > > Density sounds as a physical characteristic (many devices in a small > area) whereas Diameter sounds as a pure IP term (max number of IP hops). > > The number of entries in the routing table mostly depends on the planned > addressing architecture. One can have a very high-diameter network with > a very hierarchical addressing structures, many default routes, and very > few entries in the routing tables (maybe only 1 per hop). > I fully agree with you. I will discuss woth co-authors and modify the text, since in the case of appropriate hierarchical addressing structures, what the text of the draft says may not be true. > Is the addressing architecture for 6LoWPAN networks planned? > > Is the addressing architecture following the Internet model? > can be both, i think. It's dependent on 6lowpan scenario. >> b. Node Parameters: > > How many interfaces does a 6LoWPAN node typically have? This is of > paramount importance deciding whether any type of repeating/bridging > needs to happen. In my view, currently one interface for 15.4, for normal 6lowpan nodes. > >> * Throughput: The maximum user data throughput of a bulk data >> transmission between a single sender and a single receiver through an >> unslotted IEEE 802.15.4 2.4 GHz channel in ideal conditions is as follows >> [19]: [...] >> >> In the case of 915 MHz band: > > Sorry, for my clarification: is 915MHz the width of band centered on > the 2.4GHz mentioned above? Or is it the central frequency (thus > replacing the "2.4GHz" mentioned above)? it is the central frequency. > >> [R02] 6LoWPAN routing protocols SHOULD cause minimal power consumption by >> the efficient use of control packets (e.g., minimize expensive multicast >> which cause broadcast to the entire LoWPAN) and by the efficient routing of >> data packets. > > YEs, but multicast may be more efficient than broadcast - is it > sufficient? I think it is sufficient to rely on multicast and avoid > unnecessary duplication such as in broadcast. > multicast may be more efficient. However, 802.15.4 does not support multicast. for 6lowpan's view, IP multicast is expensive in terms of energy usage for 6lowpan nodes. > 'Efficient routing of data packets' - is it also efficient search in the > routing table? That may be part of 'routing' too. > Good point. :) >> possibliy > > Nit: iy thanks. ;) > >> [R03] 6LoWPAN routing protocol control messages SHOULD not create >> fragmentation of physical layer (PHY) frames. > > Err... I think PHY frames aren't fragmented... not sure I understand > this requirement? > > Sounds as if one wants an UDP control packets to not be sent in several > pieces, because of overhead involved fragmenting/reassembling. > > Then make sure first IP doesn't fragment. > It means 6lowpan packet should not occur fragmentation. text will be modified to make it clear. thanks. >> Therefore, 6LoWPAN routing should not cause packets to exceed the IEEE >> 802.15.4 frame size [81bytes]. > > Is this a requirement on the mesh-under link-layer switching protocol? > Or on the 'route-above' protocol? If the latter - I think this > requirement is a violation of layer independence :-) > > It sounds very special to me to limit the size of the messages of an IP > routing protocol. > > Knowing that IP can fragment too. Yes, I know your argument. :) But it's 6lowpan specific requirement, and as I know many 6lowpaners are agreed on this one. I got a comment from one roll routing requirement author that this requirement can be considered in roll as well. I may make a chance to see you to explain some detail of 6lowpan before the meeting, if you are interested in? ;) > >> [R05] The design of routing protocols for 6LoWPANs must consider the >> end-to-end latency requirements of applications and IEEE 802.15.4 link >> latency characteristics. > > 'Routing'? Or 'Transport'? end-to-end is what Transport typically > takes care of, not routing. > > If Routing: which routing? The forwarding ahppening at a node? Or the > convergence time? The exchange of routing messages? > Erm.. maybe we should consider your comments more deeply. Carles, one of the authors suggested to remove 'end-to-end' from the text. The text meant all the mechanisms that are used to perform routing functions. >> Some routing protocols are aware of the hop count of a path. > > I think all of them are, no? The text is to explain that simple hop-count is not enough for 6lowpan. There exist Link quality based routing metrics than number of hops. > >> In homes, buildings, or infrastructure, some nodes will be installed >> with mains power. Such power-installed nodes MUST be > > If they have mains power - will they use Power-Line Communications? > Not necessarily. For communication with sensors/actuators, 802.15.4 radio communication is used, but supported by affluent power instead of small battery.. >> Building monitoring applications, for instance, require that the mobile >> devices SHOULD be capable of leaving (handing-off) from an old >> network joining onto a new network within 15 seconds [17]. > > Should such a mobile device change its IP address or is it free to > change it? > Actually, I don't aware such a case that 6lowpan nodes need to change the IP address yet. We just give the example of ROLL documents which are targeting specific applications, to explain some relavent work. >> [R13] 6LoWPAN routing protocol SHOULD support various traffic patterns; >> point-to-point, point-to-multipoint, and multipoint-to- point, while avoid >> excessive multicast traffic (broadcast in link layer) in 6LoWPAN. > > It's called multicast at link-layer too (802.3); thus it avoids > unnecessary packet duplication, thus it avoids duplication of > broadcasted packets and thus avoids excessive traffic. > > If we talk IPv6 and recent link layers then I mostly forget the term > 'broadcast' and use multicast instead. > As I explained before, we would like to avoid IP multicast. I will revise the text to make it clear as 'IP multicast'. >> 6LoWPAN routing protocols should be designed with the consideration of >> forwarding packets from/to multiple sources/destinations. > > Sorry, what do you mean? An IP packet with multiple src fields? > No, it means that some applications may have multiple sources that transmit data to one destination; or a single source may transmit data to several destination nodes; etc. >> Current WG drafts in the ROLL working group explain that the workload >> or traffic pattern of use cases for 6LoWPANs tend to be highly >> structured, unlike the any- to-any data transfers that dominate typical >> client and server workloads. > > Sorry, what do you mean by 'any-to-any' data transfers? Any > relationship to 'IP anycast'? No. but if IP anycast is used, it will be one way to implement any-to-any data transfer. > >> [R14] 6LoWPAN protocols SHOULD support secure delivery of control >> messages. A minimal security level can be achieved by utilizing AES- >> based mechanism provided by IEEE 802.15.4. > > Isn't AES superstrong and thus computation intensive and thus > energy intensive? > > Intuitively speaking, maybe SHA-1 is sufficient for reduced needs in > constrained environments. > The IEEE 802.15.4 specification mandates support of AES. So, it is given as an example of secure mechanism utilized from 802.15.4 features. >> [R16] For neighbor discovery, 6LoWPAN devices SHOULD avoid sending "Hello" >> messages. > > ND doesn't send Hello messages, but NS, NA, RS and RA. Ah~ Good point. we will make it clear for the revision. > >> [R18] If the routing protocol functionality includes enabling IP >> multicast, then it may want to employ coordinator roles, if any, as relay >> points of group-targeting messages instead of using link-layer >> multicast (broadcast). > > link-layer multicast no broadcast. I don't know if 'link-layer multicast' is a proper term when 802.15.4 does not provide multicast. > > Nit: 'MAC sub-layer' appears only once and in the figure they're > all 'layers'. > > Alex Thanks. we will change it. ;) Thank you very much to spend your time to review the documents. We will gather a bit more comments and will soon post the revision applying your comments. Your comments are always appreciated. :) Best Regards, -eunah > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Mon Feb 16 02:31:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79E253A6BFB; Mon, 16 Feb 2009 02:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlyavkGwoqPz; Mon, 16 Feb 2009 02:31:02 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 6D2083A69A3; Mon, 16 Feb 2009 02:31:02 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1GATMfF016166; Mon, 16 Feb 2009 11:29:22 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1GAV4Ob024399; Mon, 16 Feb 2009 11:31:04 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n1GAV4vF030669; Mon, 16 Feb 2009 11:31:04 +0100 Message-ID: <49994068.7040507@gmail.com> Date: Mon, 16 Feb 2009 11:31:04 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Jerald.P.Martocci@jci.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll-bounces@ietf.org, ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 10:31:03 -0000 Jerald.P.Martocci@jci.com a écrit : > > I think you're putting too much emphasis on the 'low-power' aspect of > ROLL. Just because the routing algorithms must support low-power > devices (i.e. sleeping nodes, battery power, energy harvested) doesn't > mean the network is composed only of those devices. In the commercial > building market, the only layer that will be truly 'low power' will be > the sensors. As soon as the sensor data hits the next layer (e.g. room > controller) this will always be a powered device. Why? Because its > main task will be to modulate the airflow into the building spaces. The > damper used to modulate the air will always need a powered actuator to > open/close the actuator. > > The point I am trying to make is that LLNs will be composed of a network > of devices that must seamlessly interact regardless of power source. The in-house network illustration makes sense to me. I tend to agree there's a distinction in links, regarding their power. I'm not sure how to understand this in the context of ROLL proposed Charter though. Its first paragraph clearly mixes PLC links with lower-energy links: > Low power and Lossy networks (LLNs) are typically composed of many > embedded devices with limited power, memory, and processing resources > interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, > Low Power WiFi 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. LLNs have specific characteristics: > - LLNs operate with a hard, very small bound on state, > - In most cases, LLN need to be optimized for energy saving, > - Typical traffic patterns are not simply unicast flows, > - In most cases, LLNs need to be effective with very small packet sizes, > - LLN routing protocols have to be very careful when trading off efficiency for generality; many LLN nodes do not have resources to waste. Alex From emmanuel.baccelli@gmail.com Mon Feb 16 02:37:48 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E7EF28C10D for ; Mon, 16 Feb 2009 02:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.736 X-Spam-Level: X-Spam-Status: No, score=-0.736 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFxRZoq8J3SU for ; Mon, 16 Feb 2009 02:37:46 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 9CF6E28C0F6 for ; Mon, 16 Feb 2009 02:37:45 -0800 (PST) Received: by bwz5 with SMTP id 5so2978780bwz.13 for ; Mon, 16 Feb 2009 02:37:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=4BGZNvTOJd+9ZnafMKFJB7P7rM/GcSo7/gHQG6E55Cg=; b=gaUUCMSN6IZfRSfKEZuUvXOLaFTcp2M+hJj9iz+FmEdMsCoYZQXEvmSjebgHqBALhf /dB21EcIoLUv0igoPoNqoItc8vk4K91cgm+F9L8rZfj4pl9qG3oUt9/kE9E7YVEnre+E QQVTJT3j1/MQiGIOETZm0AJ3H0Ly4DYF30FI8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=IhBi2OmOMXIIENbAbBndQIfFPGcOLmNcRhfxdjuP+XtZarxA5oP1R/QOjQPX8wpU/f pz/GAhmcpfPCFUV9rCXGy8z8vx5NmQzauy11xEGKW3GueBUMeetFYGfK6HCjMbtmsvHo X42fYj+zbI489f7Uw5qn5CxWy47EQlczEUZOM= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.103.52.7 with SMTP id e7mr1367975muk.52.1234780673076; Mon, 16 Feb 2009 02:37:53 -0800 (PST) In-Reply-To: <49994068.7040507@gmail.com> References: <49994068.7040507@gmail.com> Date: Mon, 16 Feb 2009 11:37:52 +0100 X-Google-Sender-Auth: fcb1bf51759afdf9 Message-ID: From: Emmanuel Baccelli To: ROLL WG Content-Type: multipart/alternative; boundary=0016364177e364ef6c046306c775 Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 10:37:48 -0000 --0016364177e364ef6c046306c775 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi JP, I have some comments about the strawman charter. Here they are, inline. regards, Emmanuel > > > Description of Working Group: > > Low power and Lossy networks (LLNs) are typically composed of many > embedded devices with limited power, memory, and processing resources > interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, > Low Power WiFi 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. LLNs have > specific characteristics: > - LLNs operate with a hard, very small bound on state, > - In most cases, LLN need to be optimized for energy saving, > - Typical traffic patterns are not simply unicast flows, In my mind, the charter needs to be more precise here: what is specific about the targeted traffic patterns? Protocol designers need to know this. > - In most cases, LLNs need to be effective with very small packet > sizes, This needs to be more precise too: at first sight, this seems rather a problem for layers below IP. Why is this a problem for ROLL? There should be at least a hint why. > > - LLN routing protocols have to be very careful when trading off > efficiency for generality; many LLN nodes do not have resources to waste. > > These unique properties lead to unique routing requirements that may not > met by > existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For > example path selection must be designed to take into consideration the > specific power capabilities, attributes and functional characteristics > of the links and nodes in the network. > > Moreover, the way path selection is expressed in the above, is reminiscent of the way QoS routing is evoked, with interesting NP-complete problems etc. i.e. yet another "world" of problems that seem to be in scope too, while ROLLs plate is already very full. I suggest being more precise about what is in scope within the wide domain of QoS routing. > > > 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 home, healthcare, environmental monitoring, > urban sensor networks sensor networks, assets tracking, refrigeration. > The Working Group will only focus on routing solutions for a subset of > these. It will focus on industrial, connected home, building and urban > sensor networks and specify the set of routing requirements for > these scenarios. At first sight there is a serious contradiction with the current charter here: what was the purpose of the WG documents so far, including requirement documents, if there needs to be another requirement document down the line? This is unclear. So the document should explain what is the difference between the current WG documents and this future document, in order to avoid confusing people. > > > The Working Group focuses only on IPv6 only 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 explore aspects of mobility within a single LLN > (if any) in the routing requirement creation. > Several thousands of nodes. Mobility. 10 months... Hmmm, this is extremely ambitious, to say the least. More generally, in my opinion, the charter should differentiate between short term achievable goals, and long term directions. And if the charter is to be "conservative" (as are more and more WG charters lately) it should list only short term, achievable goals. > > The Working Group will pay particular attention to routing security and > manageability (e.g., self 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. > If self-configuration is an aim too for ROLL (yet another vast domain, by the way), what is the relationship between this activity and the scope of AUTOCONF? The charter should be explicit about this difference. > > > Work Items: > > - Specification of routing metrics used in path calculation. This > includes static and dynamic link/node attributes required for routing in > LLNs. > > Metrics for wireless is a very interesting research topic... but a can of worm that has already stalled several IETF processes in the past. Again, 10 months seems unrealistic for that, and therefore I strongly suggest restricting the charter to an achievable list of short-term goals. > > > - Provide an architectural framework for routing and path selection at > Layer 3 (Routing for LLN Architecture) that addresses such issues as > whether LLN routing protocols 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. > > OK, so judging from the plural form used ("LLN routing protocols"), there are going to be several protocols. This is fine, but the charter must spell out - why multiple routing protocols? - what is the specificity of each routing protocol to be designed? > - Produce a routing security framework for routing in LLNs. > > - Protocol work: In light of the application specific routing requirements, > the Working Group will either specify a new protocol and/or will select an > existing routing protocol (with the appropriate extensions in cooperation > with the relevant Working Group). > > - Documentation of applicability statement of ROLL routing protocols. > > Goals and Milestones: > > Done Submit Routing requirements for Industrial applications to the IESG > to be considered as an Informational RFC. > Done Submit Routing requirements for Connected Home networks > applications to the IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Building applications to the IESG to > be considered as an Informational RFC. > Done Submit Routing requirements for Urban networks applications to the > IESG to be considered as an Informational RFC. > July 2009 Submit Routing metrics for LLNs document to the IESG to be > considered as a Proposed Standard. > * Feb 2009 Submit Protocol Survey to the IESG to be considered as an > Informational RFC. > April 2009 Submit Security Framework to the IESG to be considered as an > Informational RFC > May 2009 Submit the Routing for LLNs Architecture document to the IESG > as an Informational RFC. > July 2009 Submit first draft of ROLL routing protocol specification as > Proposed Standard. > Nov 2009 Submit first draft of the MIB module of the ROLL routing > protocol specification. > Dec 2009 Submit the ROLL routing protocol specification to the IESG as > Proposed Standard. > Here I get very confused by two things: - the date (10 months from now), which is awfully short - the singular form ("the ROLL routing protocol") which contradicts the plural form used earlier on in the charter. > > Jan 2010 Submit the MIB module of the ROLL routing protocol > specification to the IESG as Proposed Standard. > Jan 2010 Evaluate WG progress, recharter or close. > --0016364177e364ef6c046306c775 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi JP, 
I have some = comments about the strawman charter. Here they are, inline.
regar= ds,
Emmanuel
=


 


Description of Working Group:

Low power and Lossy networks (= LLNs) are typically composed of many
embedded devices with limited power= , memory, and processing resources
interconnected by a variety of links,= such as IEEE 802.15.4, Bluetooth,
Low Power WiFi 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 transl= ation gateways and proxies. LLNs have specific characteristics:
-       LLNs operate with a hard, very small bound on state,=
-       In most cases, LLN need to be optimized for ener= gy saving,
-       Typical traffic patterns are not simpl= y unicast flows,


In my mind, the charter needs to be more pr= ecise here: what is specific about the targeted traffic patterns? Protocol = designers need to know this.
 


-       In most cases, LLNs need to be effective with ve= ry small packet sizes,



<= /div>
This needs to be more precise too: at first sight, th= is seems rather a problem for layers below IP. Why is this a problem for RO= LL? There should be at least a hint why.

 

-       LLN routing protocols have to be very careful wh= en trading off efficiency for generality; many LLN nodes do not have resour= ces to waste.

These unique properties lead to unique routing require= ments that may not met by
 existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. Forexample path selection must be designed to take into consideration thespecific power capabilities, attributes and functional characteristics
= of the links and nodes in the network.



Moreover, the way path s= election is expressed in the above, is reminiscent of the way QoS routing i= s evoked, with interesting NP-complete problems etc. i.e. yet another "= ;world" of problems that seem to be in scope too, while ROLLs plate is= already very full. I suggest being more precise about what is in scope wit= hin the wide domain of QoS routing.


 


The Working Group is focused on routing issues for LLN

There= is a wide scope of application areas for LLNs, including
 industri= al monitoring, building automation (HVAC, lighting, access
control, fire= ), connected home, healthcare, environmental monitoring,
urban sensor networks sensor networks, assets tracking, refrigeration.
T= he Working Group will only focus on routing solutions for a subset of
th= ese. It will focus on industrial, connected home, building and urban
 sensor networks and specify the set of routing requirements for
&n= bsp;these scenarios.


=
At first sight there is a serious contradiction with the current chart= er here: what was the purpose of the WG documents so far, including require= ment documents, if there needs to be another requirement document down the = line? This is unclear. So the document should explain what is the differenc= e between the current WG documents and this future document, in order to av= oid confusing people.

 


The Working Group focuses only on IPv6 only routing architectural framework for these application scenarios. The Framework will take = into consideration various
 aspects including high reliability in t= he presence of time varying loss
 characteristics and connectivity while permitting low-power operation=
 with very modest memory and CPU pressure in networks potentially<= br>comprising a very large number (several thousands) of nodes.
The Work= ing Group will explore aspects of mobility within a single LLN
(if any) in the routing requirement creation.


Several thousands of nodes. Mobility. 10 = months... Hmmm, this is extremely ambitious, to say the least. More general= ly, in my opinion, the charter should differentiate between short term achi= evable goals, and long term directions. And if the charter is to be "c= onservative" (as are more and more WG charters lately) it should list = only short term, achievable goals.

 

The Working Group will pay particular attention to routing security and=
manageability (e.g., self 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 o= r
 that establish some degree of fairness between concurrent commun= ication
sessions are out of scope of the Working Group. It is expected t= hat
 upper-layer applications utilizing LLNs define appropriate mechanisms= .


If self-co= nfiguration is an aim too for ROLL (yet another vast domain, by the way), w= hat is the relationship between this activity and the scope of AUTOCONF? Th= e charter should be explicit about this difference. 

 


Work Items:

- Specification of routing metrics used in path = calculation. This
includes static and dynamic link/node attributes requi= red for routing in
LLNs.



Metrics for wireless is a very interesting research = topic... but a can of worm that has already stalled several IETF processes = in the past. Again, 10 months seems unrealistic for that, and therefore I s= trongly suggest restricting the charter to an achievable list of short-term= goals.

 


- Provide an architectural framework for routing and path selection= at
 Layer 3 (Routing for LLN Architecture) that addresses such iss= ues as
whether LLN routing protocols require a distributed and/or centra= lized
 path computation models, whether additional hierarchy is necessary an= d
how it is applied. Manageability will be considered with each approach= ,
 along with various trade-offs for maintaining low power operatio= n,
 including the presence of non-trivial loss and networks with a very large number of nodes.



=
OK, so judging from the plural form used ("LLN = routing protocols"), there are going to be several protocols. This is = fine, but the charter must spell out

- why multiple routing protocols?
- what is the specificity of e= ach routing protocol to be designed?

 



- Produce a rou= ting security framework for routing in LLNs.

- Protocol work: In lig= ht of the application specific routing requirements, the Working Group will= either specify a new protocol and/or will select an existing routing proto= col (with the appropriate extensions in cooperation with the relevant Worki= ng Group).

- Documentation of applicability statement of ROLL routing protocols.
Goals and Milestones:

Done   Submit Routing requirements = for Industrial applications to the IESG to be considered as an Informationa= l RFC.
Done   Submit  Routing requirements for Connected Home networks a= pplications to the IESG to be considered as an Informational RFC.
Done &= nbsp; Submit Routing requirements for Building applications to the IESG to = be considered as an Informational RFC.
Done   Submit Routing requirements for Urban networks applications to = the IESG to be considered as an Informational RFC.
July 2009   &nbs= p;Submit Routing metrics for LLNs document to the IESG to be considered as = a Proposed Standard.
* Feb 2009   Submit Protocol Survey to the IESG to be considered as an= Informational RFC.
April 2009   Submit Security Framework to the I= ESG to be considered as an Informational RFC
May 2009     Subm= it the Routing for LLNs Architecture document to the IESG as an Information= al RFC.
July 2009    Submit first draft of ROLL routing protocol specific= ation as Proposed Standard.
Nov 2009     Submit first draft of= the MIB module of the ROLL routing protocol specification.
Dec 2009 &nb= sp;   Submit the ROLL routing protocol specification to the IESG as Pr= oposed Standard.

Here I get very confused by two thin= gs:

<= /div>
- the date (10 months from now), which is awfully short
- the singular form ("the ROLL routing protocol") which contradic= ts the plural form used earlier on in the charter.


 
Jan 2010  =   Submit the MIB module of the ROLL routing protocol specification to= the IESG as Proposed Standard.
Jan 2010     Evaluate WG progr= ess, recharter or close.
 --0016364177e364ef6c046306c775-- From alexandru.petrescu@gmail.com Mon Feb 16 02:40:31 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB19928C0FF for ; Mon, 16 Feb 2009 02:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaKHxMnoM0LJ for ; Mon, 16 Feb 2009 02:40:31 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id AB7543A67D2 for ; Mon, 16 Feb 2009 02:40:30 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1GAeaG0023584; Mon, 16 Feb 2009 11:40:36 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1GAeZpY010848; Mon, 16 Feb 2009 11:40:35 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n1GAeZ5m028876; Mon, 16 Feb 2009 11:40:35 +0100 Message-ID: <499942A3.5020005@gmail.com> Date: Mon, 16 Feb 2009 11:40:35 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: JP Vasseur References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> <7F8096B9-1691-44D2-9032-6383C6C765B3@thomasclausen.org> <499938BF.8030409@gmail.com> <906CC3B7-E1D2-428A-BF1F-BDBB676DA088@cisco.com> In-Reply-To: <906CC3B7-E1D2-428A-BF1F-BDBB676DA088@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 10:40:31 -0000 JP Vasseur a écrit : > > On Feb 16, 2009, at 10:58 AM, Alexandru Petrescu wrote: > >> Thomas Heide Clausen a écrit : >> [...] >>> I can see where Alexandru's question come from at this point, when we >>> were talking about power-lines and such. >>> Essentially, what we're wanting to say [I think] is that "ROLL >>> protocols MUST be able to run on routers with >>> [very-strict-set-of-restrictions]" -- and that there then may be a >>> few routers with "better than [very-strict-set-of-restrictions]" >>> shouldn't be driving our design, and that such routers are present is >>> purely incidental. >>> IOW, I'd suggest rephrasing this slightly, to say "these are the >>> requirements that ROLL protocols shall satisfy -- if a device does >>> better than that, more power to it, but it's not our primary design >>> target". >> >> This rephrasing sounds better to me. > > What is exactly the proposed rephrasing ? If one agrees with a distinction in energy between PLC device and batter-powered devices. Then a clarifying suggestion could be the following. Instead of: > Low power and Lossy networks (LLNs) are typically composed of many > embedded devices with limited power, memory, and processing resources > interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, > Low Power WiFi 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. LLNs have specific characteristics: > - LLNs operate with a hard, very small bound on state, > - In most cases, LLN need to be optimized for energy saving, > - Typical traffic patterns are not simply unicast flows, > - In most cases, LLNs need to be effective with very small packet sizes, > - LLN routing protocols have to be very careful when trading off efficiency for generality; many LLN nodes do not have resources to waste. Suggested text: " Low power and Lossy networks (LLNs) are typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi or other low power links [remove: 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. LLNs have specific characteristics: - ... - They are securely connected to the Internet. - LLN devices and links are linked together with other devices and links, which are not energy-constrained and whose bandwidth/latency/range/emissionpower could be orders of magnitude better, e.g. PLC devices. " Would you agree with this PLC distinction and the explicit statement of Internet connectivity? Alex From ietf@thomasclausen.org Mon Feb 16 02:43:40 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D453E28C124 for ; Mon, 16 Feb 2009 02:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyXjOVr4-Dew for ; Mon, 16 Feb 2009 02:43:37 -0800 (PST) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id 9CA7828C11B for ; Mon, 16 Feb 2009 02:43:37 -0800 (PST) Received: from sphinx.lix.polytechnique.fr ([129.104.11.1] helo=[192.168.112.180]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LZ0x0-000A62-8m; Mon, 16 Feb 2009 10:43:47 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 129.104.11.1 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/Tm+rbOfVH8N1dBz6RH5hS In-Reply-To: <03CE3732-F1DC-44F4-9A2A-140FAD6CA531@cisco.com> References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> <7F8096B9-1691-44D2-9032-6383C6C765B3@thomasclausen.org> <03CE3732-F1DC-44F4-9A2A-140FAD6CA531@cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: multipart/alternative; boundary=Apple-Mail-4-923155212 Message-Id: From: Thomas Heide Clausen Date: Mon, 16 Feb 2009 11:41:49 +0100 To: JP Vasseur X-Mailer: Apple Mail (2.753.1) Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 10:43:40 -0000 --Apple-Mail-4-923155212 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed JP, I'll be brief.... On Feb 16, 2009, at 11:02 AM, JP Vasseur wrote: > Hi Thomas, > > On Feb 16, 2009, at 9:49 AM, Thomas Heide Clausen wrote: > >> Dear JP, David, ROLL wg, >> >> (and, as I have a question to Alex, I Cc' him explicitly too) >> >> I've got a couple of comments to the charter below. I think it >> needs a bit of clarification in some areas, and also the >> relationship to current ROLL WG products needs to be clarified >> IMO. See below for details -- most of which I believe are >> questions that I raise that it should be fairly easy for a more >> experienced person to simply answer and propose a one-sentence >> clarification-edit to the charter to fix. >> >> On Feb 11, 2009, at 9:08 AM, JP Vasseur wrote: >> >>> Dear WG, >>> >>> As indicated in a previous email, the protocol survey I-D will be >>> send for publication this week (after posting of the last >>> revision incorporating several useful comments). >>> >>> As promised please find below the new proposed charter to be >>> submitted to the IESG for approval. In the hope of getting >>> quickly re-chartered thanks to let us know if you have any >>> comment by the ned of this week. The new charter is pretty >>> straightforward. >>> >>> Thanks to Dave Ward for his comments and guidance. >>> >>> Description of Working Group: >>> >>> Low power and Lossy networks (LLNs) are typically composed of many >>> embedded devices with limited power, memory, and processing >>> resources >>> interconnected by a variety of links, such as IEEE 802.15.4, >>> Bluetooth, >>> Low Power WiFi 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. LLNs >>> have specific characteristics: >>> - LLNs operate with a hard, very small bound on state, >>> - In most cases, LLN need to be optimized for energy saving, >> >> I am not sure that "in most cases" is entirely clear here. Does >> this mean that we can get away with designing an "energy hungry" >> routing protocol for ROLL, as long as we specify in which cases >> it'd apply? > > Right this means that "energy saving" can be a soft constraint as > opposed to a hard constraint with battery operated devices. Right, but this is kind of my point: designing for "most cases" will also allow running on "better than most cases". In this case, designing for "hard energy constraints" will mean that the protocol also will run well on something with an embedded nuclear reactor ;) I'm wondering if it'd not be better to wrap all this up in a way similar to the below: LLNs have varied characteristics, below a list of "extreme" such -- obviously, if a given LLN has better-than-these characteristics, it'll still work fine, but a LLN routing protocol MUST still be able to function under these constraints: - Hard, small bound on state - Energy This'd make it clear to me. I think it'd also capture the suggestion I made to Alex' issue? >> I'd be happier getting rid of "in most cases" and replacing >> "energy saving" with "energy conservation" or something similar. >> > > OK changing "energy saving" for "energy conservation" > >>> - Typical traffic patterns are not simply unicast flows, >> >> This, I have a big question mark to as well. It applies equally to >> the survey I-D, but I'll comment on that I-D in another email. >> >> Essentially, as a protocol designer, I'd expect a wg charter to >> help me understand the constraints under which I'd be designing a >> protocol. Reading the above item teaches me that I shouldn't >> design for "simply unicast flows", but what does that mean? Could >> I disregard unicast entirely and just build a multicast protocol? >> Do I then need group mgmt? Or is simple "roll-wide broadcast" all >> that's needed? Or all of the above? None of the above? >> >> IOW, we need to be much more specific with what the traffic >> patterns then typically would be? > > We could be more specific on many items but we would end up with a > very lengthy charter. These aspects are captured in the routing > requirement IDs, which are the IDs where we specify the > requirements that the protocol must satisfy. > > How about .... > > - Typically traffic patterns are not simply unicast flows (e.g. in > some environments most if not all traffic can be point to multipoint) Much clearer, I think. [side-note/question/not-charter-as-such: does this mean that a ROLL protocol should be multicast-capable?] >>> - In most cases, LLNs need to be effective with very small >>> packet sizes, >> >> I've gone back and forth over this, and it's also a comment that I >> think needs clarification in the survey I-D. First, I think that >> it'd be helpful to say something as to "how small". > > But we do not want to be PHY/MAC specific. Here we list a general > LLN characteristic. > >> Second, to which extend are we looking at transport [and other] >> issues in ROLL. >> > > We do not. This is spelled out below in the charter. > >> I can read this in different ways, here's my first impulse on that >> bullet point: >> >> o ROLL runs over LLs with an extremely restricted frame-size, so >> something akin to >> IP header compression is on the table [are we then in RTG?]. >> >> o Presumably, the "very small packet sizes" also applies for >> data. Is this, then, >> a generic IP-over-FOO problem? >> >> I can guess at what the intent would be, but we need to spell it >> out here. > > The former of course ... and in "most cases" (e.g. 15.4). That's what I'd have suspected as well, although reading the charter gave me a slightly different impression. Trying to be constructive, how 'bout, then, some variation over the following: - In most cases, LLNs will be employed over L2 with extremely restricted frame-sizes, thus a routing protocol for LLNs should be specifically adapted for such? (I'm sure that it can be phrased better, but I think it'd be more unambiguous that way) >>> - LLN routing protocols have to be very careful when >>> trading off efficiency for generality; many LLN nodes do not have >>> resources to waste. >> >> I can see where Alexandru's question come from at this point, when >> we were talking about power-lines and such. >> >> Essentially, what we're wanting to say [I think] is that "ROLL >> protocols MUST be able to run on routers with [very-strict-set-of- >> restrictions]" -- and that there then may be a few routers with >> "better than [very-strict-set-of-restrictions]" shouldn't be >> driving our design, and that such routers are present is purely >> incidental. >> >> IOW, I'd suggest rephrasing this slightly, to say "these are the >> requirements that ROLL protocols shall satisfy -- if a device does >> better than that, more power to it, but it's not our primary >> design target". >> >> Alex, would a rephrasing like this satisfy you? As I suggested above, this would also satisfy my other comment. >> >>> These unique properties lead to unique routing requirements that >>> may not met by >>> existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For >>> example path selection must be designed to take into >>> consideration the >>> specific power capabilities, attributes and functional >>> characteristics >>> of the links and nodes in the network. >> >> Request for clarification (a question may or may not follow): is >> multi-metric QoS thereby an explicit design requirement? >> > > That could be the case but again we cannot list all requirements in > the charter. They are specified in the requirement documents. OK, you answered my question. > >> Also, it seems from the sentence construction that it is inferred >> that "OSPF, IS-IS, AODV and OLSR" do not have the capability to >> take "power capabilities, attributes and functional >> characteristics of the links and nodes in the network" into >> consideration. I'm not sure that that's the entire truth. Can this >> be clarified a notch? > > We do say "existing". Not sure which clarification you want ? Ok, I may not have been clear. OSPF, IS-IS, AODV and OLSR do all support QoS in some form or other, i.e. they are able to take these (power, attributes, ...) into account. It reads as if the charter is saying "no they don't". It may be that they don't do so in a desirable way (in which case, that should be analyzed and stated). >>> The Working Group is focused on routing issues for LLN >> >> Alright, so routing issues only. Fair enough -- but what's the >> relationship then with the "very small packet sizes" bullet point >> above? Do we expect [other-wg] to resolve this issue, > > A good example being 6lowpan. Would it make sense to reference that in the charter? "The ROLL wg will pay attention to other IETF work addressing topics within the ROLL space, e.g. 6lowpan, )". I've seen that done for other WG charters, and found it immensely helpful when diving into a new wg and trying to find foothold. > >> or is there routing-only-issues that need be brought forward? If >> so, which? >> > > This "a" characteristic since you asked to spell out a bit more > precisely LLN's characteristics (and this was an excellent idea). And, I think, that it was excellently taken on board as well, and I appreciate both the survey I-D and the charter for having done so. > An obvious consequence being that the routing protocol cannot > afford to send to large frames (in some cases). Detailed > requirements again are in application-specific routing requirements > documents. Yep, agreed. I think that the suggestion that I made above would just about cover this issue. I agree that we do not want to be too verbose here, so I think it'd be a small fix. > >>> There is a wide scope of application areas for LLNs, including >>> industrial monitoring, building automation (HVAC, lighting, access >>> control, fire), connected home, healthcare, environmental >>> monitoring, >>> urban sensor networks sensor networks, assets tracking, >>> refrigeration. >>> The Working Group will only focus on routing solutions for a >>> subset of >>> these. It will focus on industrial, connected home, building and >>> urban >>> sensor networks and specify the set of routing requirements for >>> these scenarios. >> >> Question: does the above entail "new work", or is this in >> reference to the current requirement I-Ds? > > Good catch, it should read: "It focuses on industrial, connected > home, building and urban sensor networks and specify the set of > routing requirements for these scenarios." Glad to not be entirely useless ;) >>> The Working Group focuses only on IPv6 only routing architectural >>> framework for these application scenarios. >> >> Question: by "architectural framework", what exactly is to be >> understood? > > A routing architecture ID (pointed out in the WG item). OK, I am not quite sure what that is, though? Maybe it's me being dense, do you have a reference to something akin to this, just for my personal education? >>> 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 explore aspects of mobility within a >>> single LLN >>> (if any) in the routing requirement creation. >> >> Does this entail a new "routing requirements" document being >> produced? >> > > Another good point. We can remove that last sentence. ;) >>> The Working Group will pay particular attention to routing >>> security and >>> manageability (e.g., self configuration) issues. It will also >>> need to >>> consider the transport characteristic the routing protocol >>> messages will >>> experience. >> >> This goes back to my previous question: IP-over-foo or ? >> >> >> More broadly, how are the current ROLL products (survey I-D, rtg >> requirements) expected to be employed in all this? > > Quite clear: > 1) The survey was there to figure out whether *existing* protocol > could meet the requirements. The answer is "no" > 2) Requirements are used to produce the protocol (extensions or new). I just wonder if those "findings" (or at least the documents containing those) need not get mention in the charter? >> Finally, in summarizing the charter, ROLL aims at solving: >> >> o routing over wireless >> o scalability to several thousands of routers >> o QoS in wireless networks, including >> o formalization of wireless link metrics >> o security > > Not just wireless at discussed on the ML, not sure why you mention > QoS in wireless network (at most we do QoS routing), ... Ok, remove "in wireless networks, including" from the list above, the rest of my comment still stands -- it seems very ambitious scheduling. Thomas >> within 10 months, and to the level of proposed standard. >> >> The items are very interesting, but 10 months is also *very* short >> -- and the complexity of some of those is not trivial without >> making serious concessions in some areas. > > It is aggressive but should we end up extending an existing > protocol does not take so much time. The good thing is that we > spent a lot of time spelling out all requirements, which will ease > the protocol design phase. We can always add a few months to the > last milestone. > > Let me cite from an email from Dave Ward (Feb. 3, 2009) >> >> On Feb 3, 2009, at 5:52 PM, David Ward wrote: >>> I expect "wild swings" of the design pattern of the protocol >>> during the first year of the design effort. I attempted to make >>> this clear at the mic in Minneapolis that the current trajectory >>> is very complex problem domain that hasn't born a lot of fruit >>> but, that in the design phase reducing the complexity must occur. >> >> >> Considering the complexity of the list of items above, I am much >> more in line with what Dave Ward writes, than with what the >> milestones suggest. > > > Thanks. > > JP. > >> >> Thomas >> >> >>> 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. >>> >>> >>> 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 protocols 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: In light of the application specific routing >>> requirements, the Working Group will either specify a new >>> protocol and/or will select an existing routing protocol (with >>> the appropriate extensions in cooperation with the relevant >>> Working Group). >>> >>> - Documentation of applicability statement of ROLL routing >>> protocols. >>> >>> Goals and Milestones: >>> >>> Done Submit Routing requirements for Industrial applications to >>> the IESG to be considered as an Informational RFC. >>> Done Submit Routing requirements for Connected Home networks >>> applications to the IESG to be considered as an Informational RFC. >>> Done Submit Routing requirements for Building applications to >>> the IESG to be considered as an Informational RFC. >>> Done Submit Routing requirements for Urban networks >>> applications to the IESG to be considered as an Informational RFC. >>> July 2009 Submit Routing metrics for LLNs document to the IESG >>> to be considered as a Proposed Standard. >>> * Feb 2009 Submit Protocol Survey to the IESG to be considered >>> as an Informational RFC. >>> April 2009 Submit Security Framework to the IESG to be >>> considered as an Informational RFC >>> May 2009 Submit the Routing for LLNs Architecture document to >>> the IESG as an Informational RFC. >>> July 2009 Submit first draft of ROLL routing protocol >>> specification as Proposed Standard. >>> Nov 2009 Submit first draft of the MIB module of the ROLL >>> routing protocol specification. >>> Dec 2009 Submit the ROLL routing protocol specification to >>> the IESG as Proposed Standard. >>> Jan 2010 Submit the MIB module of the ROLL routing protocol >>> specification to the IESG as Proposed Standard. >>> Jan 2010 Evaluate WG progress, recharter or close. >>> >>> PS: I marked * the Milestones that will be "This Week" and before >>> submitting to the IESG for re-chartering. >>> >>> >>> >>> Thanks. >>> >>> JP and David. >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> > --Apple-Mail-4-923155212 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 JP,

I'll be brief....

On Feb = 16, 2009, at 11:02 AM, JP Vasseur wrote:

Hi = Thomas,

On Feb 16, 2009, at 9:49 AM, Thomas Heide = Clausen wrote:

Dear JP, David, ROLL = wg,

(and, as I have a question to Alex, I Cc' him = explicitly too)

I've got a couple of comments to the = charter below. I think it needs a bit of clarification in some areas, = and also the relationship to current ROLL WG products needs to be = clarified IMO. See below for details -- most of which I believe are = questions that I raise that it should be fairly easy for a more = experienced person to simply answer and propose a one-sentence = clarification-edit to the charter to = fix.

On Feb 11, 2009, at 9:08 AM, JP = Vasseur wrote:

Dear WG,

As = indicated in a previous email, the protocol survey I-D will be send for = publication this week (after posting of the last revision incorporating = several useful comments).

As promised please find below = the new proposed charter to be submitted to the IESG for approval. In = the hope of getting quickly re-chartered thanks to let us know if you = have any comment by the ned of this week. The new charter is pretty = straightforward.

Thanks to Dave Ward for his comments and = guidance.

Description of Working Group:

Low = power and Lossy networks (LLNs) are typically composed of many
embedded devices with limited power, memory, and = processing resources
interconnected by a variety = of links, such as IEEE 802.15.4, Bluetooth,
Low = Power WiFi or other low power PLC (Powerline Communication) links. LLNs = are transitioning to an end-to-end IP-based
=A0solution to avoid the problem = of non-interoperable networks
- =A0 =A0 =A0 LLNs operate with a = hard, very small bound on state,
- =A0 =A0 =A0 In most cases, LLN = need to be optimized for energy = saving,

I am not sure that "in most = cases" is entirely clear here. Does this mean that we can get away with = designing an "energy hungry" routing protocol for ROLL, as long as we = specify in which cases it'd apply? =

Right this = means that "energy saving" can be a soft constraint as opposed to a hard = constraint with battery operated = devices.

Right, but this is = kind of my point: designing for "most cases" will also allow running on = "better than most cases". In this case, designing for "hard energy = constraints" will mean that the protocol also will run well on something = with an embedded nuclear reactor ;)

I'm = wondering if it'd not be better to wrap all this up in a way similar to = the below:

LLNs have varied characteristics, = below a list of "extreme" such -- obviously,=A0
if a = given LLN has better-than-these characteristics, it'll still work fine, = but a=A0
LLN routing protocol MUST still = be able to function under these = constraints:

- Hard, = small bound on state
- = Energy
<etc - rest of = list>

This'd make it clear to me. I think = it'd also capture the suggestion I made to Alex' = issue?

I'd be happier getting rid of "in = most cases" and replacing "energy saving" with "energy conservation" or = something = similar.


OK changing "energy saving" for "energy = conservation"

- =A0 =A0 =A0 = Typical traffic patterns are not simply unicast = flows,

This, I have a big question mark = to as well. It applies equally to the survey I-D, but I'll comment on = that I-D in another email.

Essentially, as a = protocol designer, I'd expect a wg charter to help me understand the = constraints under which I'd be designing a protocol. Reading the above = item teaches me that I shouldn't design for "simply unicast flows", but = what does that mean? Could I disregard unicast entirely and just build a = multicast protocol? Do I then need group mgmt? Or is simple "roll-wide = broadcast" all that's needed? Or all of the above? None of the = above?

IOW, we need to be much more specific = with what the traffic patterns then typically would = be?

We could be = more specific on many items but we would end up with a = very=A0lengthy=A0charter. These aspects are captured in the routing = requirement IDs, which are the IDs where we specify the requirements = that the protocol must satisfy.

How about = ....

- Typically traffic patterns are not = simply unicast flows (e.g. in some=A0environments=A0most if not all = traffic can be point = to=A0multipoint)

Much = clearer, I think. [side-note/question/not-charter-as-such: does this = mean that a ROLL protocol should be = multicast-capable?]


- =A0 =A0 =A0 = In most cases, LLNs need to be effective with very small packet = sizes,

I've gone back and forth = over this, and it's also a comment that I think needs clarification in = the survey I-D. First, I think that it'd be helpful to say something as = to "how small". =

But we do = not want to be PHY/MAC specific. Here we list a general = LLN=A0characteristic.=A0

Second, to = which extend are we looking at transport [and other] issues in = ROLL.


We do not. This is spelled out below in the = charter.

I can read this in different = ways, here's my first impulse on that bullet = point:

o ROLL runs over LLs with an = extremely restricted frame-size, so something akin to=A0
= IP=A0header compression is on the table [are we then in = RTG?].

o Presumably, the "very small = packet sizes" also applies for data. Is this, then,
a = generic IP-over-FOO problem?

I can guess at = what the intent would be, but we need to spell it out = here.

The = former of course ... and in "most cases" (e.g. = 15.4).

That's what I'd have = suspected as well, although reading the charter gave me a slightly = different impression. Trying to be constructive, how 'bout, then, some = variation over the following:

- In most = cases, LLNs will be employed over L2 with extremely restricted = frame-sizes,
thus a routing protocol = for LLNs should be specifically adapted for = such?

(I'm sure that it can be phrased = better, but I think it'd be more=A0unambiguous=A0that = way)

- =A0 =A0 =A0 = LLN routing protocols have to be very careful when trading off = efficiency for generality; many LLN nodes do not have resources to = waste.

I can see where Alexandru's = question come from at this point, when we were talking about power-lines = and such.

Essentially, what we're wanting to = say [I think] is that "ROLL protocols MUST be able to run on routers = with [very-strict-set-of-restrictions]" -- and that there then may be a = few routers with "better than [very-strict-set-of-restrictions]" = shouldn't be driving our design, and that such routers are present is = purely incidental.

IOW, I'd suggest rephrasing = this slightly, to say "these are the requirements that ROLL protocols = shall satisfy -- if a device does better than that, more power to it, = but it's not our primary design target".

Alex, = would a rephrasing like this satisfy = you?

As I suggested above, this would also satisfy my other = comment.

These unique properties lead = to unique routing requirements that may not met by
=A0existi= ng routing protocols, such as OSPF, IS-IS, AODV and OLSR. For
example path selection must be designed to take into = consideration the
specific power capabilities, = attributes and functional characteristics
of the = links and nodes in the network.

Request = for clarification (a question may or may not follow): is multi-metric = QoS thereby an explicit design = requirement?


<= /div>
That could be the case but again we cannot list all = requirements in the charter. They are specified in the requirement = documents.

OK, you answered = my question.


Also, it seems = from the sentence construction that it is inferred that "OSPF, IS-IS, = AODV and OLSR" do not have the capability to take "power capabilities, = attributes and functional characteristics of the links and nodes in the = network" into consideration. I'm not sure that that's the entire truth. = Can this be clarified a = notch?

We do say = "existing". Not sure which clarification you want = ?

Ok, I may not have = been clear. OSPF, IS-IS, AODV and OLSR do all support QoS in some form = or other, i.e. they are able to take these (power, attributes, ...) into = account. It reads as if the charter is saying "no they don't". It may be = that they don't do so in a=A0desirable=A0way (in which case, that should = be analyzed and stated).

The Working Group is focused = on routing issues for = LLN

Alright, so routing issues = only. Fair enough -- but what's the relationship then with the "very = small packet sizes" bullet point above? Do we expect [other-wg] to = resolve this issue, =

A good example = being 6lowpan.

Would it = make sense to reference that in the charter? "The ROLL wg will pay = attention to other IETF work addressing topics within the ROLL space, = e.g. 6lowpan, <complete-the-list>)". I've seen that done for other WG = charters, and found it immensely helpful when diving into a new wg and = trying to find foothold.


or is there = routing-only-issues that need be brought forward? If so, = which?


<= div>This "a"=A0characteristic=A0since you asked to spell out a bit more = precisely LLN's=A0characteristics=A0(and this was an excellent idea). =

And, I think, that it = was excellently taken on board as well, and I appreciate both the survey = I-D and the charter for having done so.

An obvious consequence being that the = routing protocol cannot afford to send to large frames (in some cases). = Detailed requirements again are in application-specific routing = requirements = documents.

Yep, = agreed. I think that the suggestion that I made above would just about = cover this issue. I agree that we do not want to be too verbose here, so = I think it'd be a small fix.


There is a wide scope of = application areas for LLNs, including
=A0industrial monitoring, = building automation (HVAC, lighting, access
urban sensor networks sensor = networks, assets tracking, refrigeration.
The = Working Group will only focus on routing solutions for a subset = of
these. It will focus on industrial, connected = home, building and urban
=A0sensor networks and specify = the set of routing requirements for
=A0these = scenarios.

Question: does the above = entail "new work", or is this in reference to the current requirement = I-Ds?

Good = catch, it should read: "It focuses on industrial, connected home, = building and urban=A0sensor networks and specify the set of routing = requirements for=A0these = scenarios."

Glad to not be = entirely useless ;)

The Working Group focuses only = on IPv6 only routing architectural
=A0framework for these = application scenarios.

Question: = by "architectural framework", what exactly is to be = understood?

= A routing architecture ID (pointed out in the WG = item).

OK, I am not = quite sure what that is, though? Maybe it's me being dense, do you have = a reference to something akin to this, just for my personal = education?

The = Framework will take into consideration various
=A0aspect= s including high reliability in the presence of time varying = loss
=A0characteristics and = connectivity while permitting low-power operation
=A0with = very modest memory and CPU pressure in networks potentially
comprising a very large number (several thousands) = of nodes.
The Working Group will explore = aspects of mobility within a single LLN
(if any) = in the routing requirement = creation.

Does this entail a new = "routing requirements" document being = produced?


Another good point. We can remove that last = sentence.

;)

The = Working Group will pay particular attention to routing security = and
manageability (e.g., self = configuration) issues. It will also need to
=A0consider the transport = characteristic the routing protocol messages will
=A0experience.

This goes back to my previous question: IP-over-foo or = ?


More broadly, how are the current = ROLL products (survey I-D, rtg requirements) expected to be employed in = all this?

Quite = clear:
1) The survey was there to figure out whether = *existing* protocol could meet the requirements. The answer is = "no"
2) Requirements are used to produce the protocol = (extensions or new).

I = just wonder if those "findings" (or at least the documents containing = those) need not get mention in the charter?=A0

Finally, in summarizing the = charter, ROLL aims at solving:

o=A0 routing = over wireless
o scalability to several thousands = of routers
o QoS in wireless networks, = including
o formalization of wireless link = metrics
o = security

No= t just wireless at discussed on the ML, not sure why you mention QoS in = wireless network (at most we do QoS routing), = ...

Ok, remove "in = wireless networks, including" from the list above, the rest of my = comment still stands -- it seems very ambitious = scheduling.


Thomas

<= /div>

Let = me cite from an email from Dave Ward (Feb. 3, = 2009)

On Feb 3, 2009, at = 5:52 PM, David Ward wrote:
I expect "wild swings" of the design pattern of the protocol = during the first year of the design effort.=A0I = attempted to make this clear at the mic in Minneapolis that the current = trajectory is very complex problem domain that hasn't born a lot of = fruit but, that in the design phase reducing the complexity must = occur.=A0

Consid= ering the complexity of the list of items above, I am much more in line = with what Dave Ward writes, than with what the milestones = suggest.


Thanks.

JP.
Mechanisms that protect an LLN = from congestion collapse or
=A0that establish some degree of = fairness between concurrent communication
sessions = are out of scope of the Working Group. It is expected that
=A0upper-layer applications = utilizing LLNs define appropriate mechanisms.


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
=A0Layer 3 (Routing for LLN = Architecture) that addresses such issues as
whether = LLN routing protocols require a distributed and/or centralized
=A0path = computation models, whether additional hierarchy is necessary = and
how it is applied. Manageability = will be considered with each approach,
=A0along with various trade-offs = for maintaining low power operation,
=A0including the presence of = non-trivial loss and networks with a very
=A0large number of = nodes.


- = Produce a routing security framework for routing in LLNs.

- = Protocol work: In light of the application specific routing = requirements, the Working Group will either specify a new protocol = and/or will select an existing routing protocol (with the appropriate = extensions in cooperation with the relevant Working Group).

- = Documentation of applicability statement of ROLL routing = protocols.

Goals and Milestones:

Done =A0 Submit Routing requirements = for Industrial applications to the IESG to be considered as an = Informational RFC.
Done =A0 Submit=A0 Routing requirements for = Connected Home networks applications to the IESG to be considered as an = Informational RFC.
Done =A0 Submit Routing requirements = for Building applications to the IESG to be considered as an = Informational RFC.
Done =A0 Submit Routing requirements = for Urban networks applications to the IESG to be considered as an = Informational RFC.
July 2009=A0 =A0 Submit Routing metrics = for LLNs document to the IESG to be considered as a Proposed = Standard.
* Feb 2009 =A0 Submit Protocol Survey to the = IESG to be considered as an Informational RFC.
April 2009 =A0 = Submit Security Framework to the IESG to be considered as an = Informational RFC
May 2009 =A0 =A0 Submit the Routing for = LLNs Architecture document to the IESG as an Informational = RFC.
July 2009=A0 =A0 Submit first draft of = ROLL routing protocol specification as Proposed Standard.
Nov 2009 =A0 =A0= Submit first draft of the MIB module of the ROLL routing = protocol specification.
Dec 2009 = =A0 =A0 Submit the ROLL = routing protocol specification to the IESG as Proposed = Standard.
Jan 2010 =A0 =A0 Submit the MIB module of = the ROLL routing protocol specification to the IESG as Proposed = Standard.
Jan 2010 =A0 =A0 Evaluate WG progress, = recharter or close.
PS: I marked * the Milestones = that will be "This Week" and before submitting to the IESG for = re-chartering.




JP and David.
Roll mailing list
=



= --Apple-Mail-4-923155212-- From alexandru.petrescu@gmail.com Mon Feb 16 02:51:02 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F22A828C118 for ; Mon, 16 Feb 2009 02:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-no+l5Ke8GA for ; Mon, 16 Feb 2009 02:51:02 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id A824828C10D for ; Mon, 16 Feb 2009 02:51:01 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1GAnJFU011639; Mon, 16 Feb 2009 11:49:19 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1GAp0R8029323; Mon, 16 Feb 2009 11:51:00 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n1GAp0Wt032496; Mon, 16 Feb 2009 11:51:00 +0100 Message-ID: <49994514.3070200@gmail.com> Date: Mon, 16 Feb 2009 11:51:00 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Thomas Heide Clausen References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> <7F8096B9-1691-44D2-9032-6383C6C765B3@thomasclausen.org> <03CE3732-F1DC-44F4-9A2A-140FAD6CA531@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] unicast and multicast traffic patterns (was: ROLL re-chartering) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 10:51:03 -0000 Thomas Heide Clausen a écrit : [...] >>> IOW, we need to be much more specific with what the traffic patterns >>> then typically would be? >> >> We could be more specific on many items but we would end up with a >> very lengthy charter. These aspects are captured in the routing >> requirement IDs, which are the IDs where we specify the requirements >> that the protocol must satisfy. >> >> How about .... >> >> - Typically traffic patterns are not simply unicast flows (e.g. in >> some environments most if not all traffic can be point to multipoint) > > Much clearer, I think. On this particular point, me to I agree, it becomes clearer. If the terms unicast and multicast were used explicitely then it would make sense to me. Typically traffic patterns are not simply unicast flows but also multicast. Alex From jvasseur@cisco.com Mon Feb 16 02:56:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06FB23A67FF for ; Mon, 16 Feb 2009 02:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.978 X-Spam-Level: X-Spam-Status: No, score=-9.978 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIeC9qxCeI5F for ; Mon, 16 Feb 2009 02:56:47 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id AD7D03A67D2 for ; Mon, 16 Feb 2009 02:56:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,215,1233532800"; d="scan'208,217";a="33875476" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 16 Feb 2009 10:56:53 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1GAuris013366; Mon, 16 Feb 2009 11:56:53 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1GAurIl003018; Mon, 16 Feb 2009 10:56:53 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 11:56:52 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 11:56:51 +0100 Message-Id: From: JP Vasseur To: Emmanuel Baccelli In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-35-924057470 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 16 Feb 2009 11:56:51 +0100 References: <49994068.7040507@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 16 Feb 2009 10:56:52.0060 (UTC) FILETIME=[4612D9C0:01C99025] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=30621; t=1234781813; x=1235645813; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20re-chartering |Sender:=20; bh=WmQ2hYvZ3M9f3n7Im94nEg5iqQCIKK5loO8o24P3PAc=; b=fJVeGV0AkblYBytY/7OdyOdpwzDG3HITxw7wzh2ALbiDvMxoLkz7sRSbJa XtaP1HLH6TszhRTiHYPNklf76y+VFet6GQR/iB5RQk2/uCJgfAHPwM1v7i7V HNFUGyQX2D; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 10:56:49 -0000 --Apple-Mail-35-924057470 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Emmanuel, Thanks for your comments - see in line. On Feb 16, 2009, at 11:37 AM, Emmanuel Baccelli wrote: > Hi JP, > I have some comments about the strawman charter. Here they are, > inline. > regards, > Emmanuel > > > > > > Description of Working Group: > > Low power and Lossy networks (LLNs) are typically composed of many > embedded devices with limited power, memory, and processing resources > interconnected by a variety of links, such as IEEE 802.15.4, > Bluetooth, > Low Power WiFi 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. LLNs > have specific characteristics: > - LLNs operate with a hard, very small bound on state, > - In most cases, LLN need to be optimized for energy saving, > - Typical traffic patterns are not simply unicast flows, > > > In my mind, the charter needs to be more precise here: what is > specific about the targeted traffic patterns? Protocol designers > need to know this. What I proposed to Thomas was: "- Typically traffic patterns are not simply unicast flows (e.g. in some environments most if not all traffic can be point to multipoint)" Do you like this better ? If we want to go one step further, one should refer to the requirement. > > > > - In most cases, LLNs need to be effective with very small > packet sizes, > > > > This needs to be more precise too: at first sight, this seems rather > a problem for layers below IP. Why is this a problem for ROLL? There > should be at least a hint why. > See my reply to Thomas and let me know. > > > - LLN routing protocols have to be very careful when trading > off efficiency for generality; many LLN nodes do not have resources > to waste. > > These unique properties lead to unique routing requirements that may > not met by > existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For > example path selection must be designed to take into consideration the > specific power capabilities, attributes and functional characteristics > of the links and nodes in the network. > > > > Moreover, the way path selection is expressed in the above, is > reminiscent of the way QoS routing is evoked, with interesting NP- > complete problems etc. i.e. yet another "world" of problems that > seem to be in scope too, while ROLLs plate is already very full. I > suggest being more precise about what is in scope within the wide > domain of QoS routing. Where do you see "Qos routing ?". Remember, the goal of the charter is not to express all specific requirements. There are for routing requirements documents for that purpose. > > > > > > 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 home, healthcare, environmental monitoring, > urban sensor networks sensor networks, assets tracking, refrigeration. > The Working Group will only focus on routing solutions for a subset of > these. It will focus on industrial, connected home, building and urban > sensor networks and specify the set of routing requirements for > these scenarios. > > > At first sight there is a serious contradiction with the current > charter here: what was the purpose of the WG documents so far, > including requirement documents, if there needs to be another > requirement document down the line? This is unclear. You are right, this has been corrected ("will only focus" should read "only focuses") - Fixed. > So the document should explain what is the difference between the > current WG documents and this future document, in order to avoid > confusing people. > > > > > The Working Group focuses only on IPv6 only 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 explore aspects of mobility within a single LLN > (if any) in the routing requirement creation. > > > Several thousands of nodes. Mobility. 10 months... Yes again the last sentence has been removed. > Hmmm, this is extremely ambitious, to say the least. More generally, > in my opinion, the charter should differentiate between short term > achievable goals, and long term directions. And if the charter is to > be "conservative" (as are more and more WG charters lately) it > should list only short term, achievable goals. Do yo know why we think that it is achievable ? Because such routing protocols (non IP) are being deployed today. That said, as proposed, let's add a few months to the milestone. > > > > The Working Group will pay particular attention to routing security > and > manageability (e.g., self 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. > > > If self-configuration is an aim too for ROLL (yet another vast > domain, by the way), what is the relationship between this activity > and the scope of AUTOCONF? The charter should be explicit about this > difference. It is all spelled out in the requirement documents though, with dedicated "Manageability" section, as experimented in other WGs such as the PCE WG. But you are right that we should be a bit more precise here. How about ? OLD: The Working Group will pay particular attention to routing security and manageability (e.g., self configuration) issues. NEW: The Working Group will pay particular attention to routing security and manageability (e.g., minimal routing configuration) issues. > > > > > Work Items: > > - Specification of routing metrics used in path calculation. This > includes static and dynamic link/node attributes required for > routing in > LLNs. > > > > Metrics for wireless is a very interesting research topic... but a > can of worm that has already stalled several IETF processes in the > past. Again, 10 months seems unrealistic for that, and therefore I > strongly suggest restricting the charter to an achievable list of > short-term goals. Note that we have been discussing this item for a long time and the existing (non WG document) is progressing well. New revision soon. The idea is to define a few useful metrics for the L3 (for link and node) and again we already had a good consensus on which metrics, ... Still far from being finalized but on its way. > > > > > - Provide an architectural framework for routing and path selection at > Layer 3 (Routing for LLN Architecture) that addresses such issues as > whether LLN routing protocols 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. > > > > OK, so judging from the plural form used ("LLN routing protocols"), > there are going to be several protocols. This is fine, but the > charter must spell out No ... as discussed on this list we do *not* know yet. Certainly not one per application, ideally one, may be two. Both David and I answered to this question on the list. > > - why multiple routing protocols? > - what is the specificity of each routing protocol to be designed? > > > > > > - Produce a routing security framework for routing in LLNs. > > - Protocol work: In light of the application specific routing > requirements, the Working Group will either specify a new protocol > and/or will select an existing routing protocol (with the > appropriate extensions in cooperation with the relevant Working > Group). > > - Documentation of applicability statement of ROLL routing protocols. > > Goals and Milestones: > > Done Submit Routing requirements for Industrial applications to > the IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Connected Home networks > applications to the IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Building applications to the > IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Urban networks applications > to the IESG to be considered as an Informational RFC. > July 2009 Submit Routing metrics for LLNs document to the IESG to > be considered as a Proposed Standard. > * Feb 2009 Submit Protocol Survey to the IESG to be considered as > an Informational RFC. > April 2009 Submit Security Framework to the IESG to be considered > as an Informational RFC > May 2009 Submit the Routing for LLNs Architecture document to > the IESG as an Informational RFC. > July 2009 Submit first draft of ROLL routing protocol > specification as Proposed Standard. > Nov 2009 Submit first draft of the MIB module of the ROLL > routing protocol specification. > Dec 2009 Submit the ROLL routing protocol specification to the > IESG as Proposed Standard. > > Here I get very confused by two things: > > - the date (10 months from now), which is awfully short > - the singular form ("the ROLL routing protocol") which contradicts > the plural form used earlier on in the charter. > > We will change for Feb 2010. We do not know whether there will be one or more. Thanks. JP. > > > Jan 2010 Submit the MIB module of the ROLL routing protocol > specification to the IESG as Proposed Standard. > Jan 2010 Evaluate WG progress, recharter or close. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-35-924057470 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Emmanuel,

Thanks for your comments - see in = line.

On Feb 16, 2009, at 11:37 AM, Emmanuel = Baccelli wrote:

Hi = JP, 
I have some comments about the strawman charter. = Here they are, inline.
regards,
Emmanuel


Description of Working Group:

Low = power and Lossy networks (LLNs) are typically composed of = many
embedded devices with limited power, memory, and processing = resources
interconnected by a variety of links, such as IEEE = 802.15.4, Bluetooth,
Low Power WiFi 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. = LLNs have specific characteristics:
-       LLNs = operate with a hard, very small bound on state,
-     =   In most cases, LLN need to be optimized for energy saving,
- =       Typical traffic patterns are not simply unicast = flows,


In my = mind, the charter needs to be more precise here: what is specific about = the targeted traffic patterns? Protocol designers need to know = this.

What I proposed to = Thomas was:

"- Typically traffic patterns are = not simply unicast flows (e.g. in some environments most if = not all traffic can be point = to multipoint)"

Do you like this better = ? If we want to go one step further, one should refer to the = requirement.

 


-       In most cases, LLNs = need to be effective with very small packet = sizes,



This needs to be more precise too: at first sight, this seems = rather a problem for layers below IP. Why is this a problem for ROLL? = There should be at least a hint why.
 

-       LLN routing protocols = have to be very careful when trading off efficiency for generality; many = LLN nodes do not have resources to waste.

These unique properties = lead to unique routing requirements that may not met by
=  existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. = For
example path selection must be designed to take into = consideration the
specific power capabilities, attributes and = functional characteristics
of the links and nodes in the network.
=


Moreover, = the way path selection is expressed in the above, is reminiscent of the = way QoS routing is evoked, with interesting NP-complete problems etc. = i.e. yet another "world" of problems that seem to be in scope too, while = ROLLs plate is already very full. I suggest being more precise about = what is in scope within the wide domain of QoS = routing.

Where do you see = "Qos routing ?". 

Remember, the goal of = the charter is not to express all specific requirements. There are for = routing requirements documents for that purpose.



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 home, healthcare, environmental monitoring,
urban = sensor networks sensor networks, assets tracking, refrigeration.
The = Working Group will only focus on routing solutions for a subset = of
these. It will focus on industrial, connected home, building and = urban
 sensor networks and specify the set of routing = requirements for
 these = scenarios.


At = first sight there is a serious contradiction with the current charter = here: what was the purpose of the WG documents so far, including = requirement documents, if there needs to be another requirement document = down the line? This is unclear. =

You are right, this has = been corrected ("will only focus" should read "only focuses") - = Fixed.

So the document should = explain what is the difference between the current WG documents and this = future document, in order to avoid confusing people.

 


The Working Group focuses only on IPv6 = only 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 explore aspects = of mobility within a single LLN
(if any) in the routing requirement = creation.


S= everal thousands of nodes. Mobility. 10 months... =

Yes again the last = sentence has been removed.


Do yo know why we = think that it is achievable ? Because such routing protocols (non IP) = are being deployed today.
That said, as proposed, let's add a = few months to the milestone.


 

The Working Group will pay particular = attention to routing security and
manageability (e.g., self = 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.


If self-configuration is an aim too for ROLL (yet another vast domain, = by the way), what is the relationship between this activity and the = scope of AUTOCONF? The charter should be explicit about this = difference. 

It is all = spelled out in the requirement documents though, with dedicated = "Manageability" section, as experimented in other WGs such as the PCE = WG. But you are right that we should be a bit more precise = here.

How about ?
OLD:

The Working Group will pay particular attention to = routing security and manageability (e.g., self configuration) = issues.

NEW: 
The Working = Group will pay particular attention to routing security = and manageability (e.g., minimal routing configuration) = issues.




Work = Items:

- Specification of routing metrics used in path = calculation. This
includes static and dynamic link/node attributes = required for routing = in
LLNs.



=
Metrics for wireless is a very interesting = research topic... but a can of worm that has already stalled several = IETF processes in the past. Again, 10 months seems unrealistic for that, = and therefore I strongly suggest restricting the charter to an = achievable list of short-term = goals.

Note that we have = been discussing this item for a long time and the existing (non WG = document) is progressing well. New revision soon. The idea is to define = a few useful metrics for the L3 (for link and node) and again we already = had a good consensus on which metrics, ... Still far from being = finalized but on its way.


 


- Provide an architectural framework for = routing and path selection at
 Layer 3 (Routing for LLN = Architecture) that addresses such issues as
whether LLN routing = protocols 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.



= OK, so judging from the plural form used ("LLN routing protocols"), = there are going to be several protocols. This is fine, but the charter = must spell out

No ... as = discussed on this list we do *not* know yet. Certainly not one per = application, ideally one, may be two. Both David and I answered to this = question on the list.


- = why multiple routing protocols?
- what is the specificity of = each routing protocol to be designed?
=

 



- Produce a routing security framework for routing in = LLNs.

- Protocol work: In light of the application specific = routing requirements, the Working Group will either specify a new = protocol and/or will select an existing routing protocol (with the = appropriate extensions in cooperation with the relevant Working = Group).

- Documentation of applicability statement of ROLL = routing protocols.

Goals and Milestones:

Done   = Submit Routing requirements for Industrial applications to the IESG to = be considered as an Informational RFC.
Done   Submit =  Routing requirements for Connected Home networks applications to = the IESG to be considered as an Informational RFC.
Done   Submit = Routing requirements for Building applications to the IESG to be = considered as an Informational RFC.
Done   Submit Routing = requirements for Urban networks applications to the IESG to be = considered as an Informational RFC.
July 2009    Submit = Routing metrics for LLNs document to the IESG to be considered as a = Proposed Standard.
* Feb 2009   Submit Protocol Survey to the = IESG to be considered as an Informational RFC.
April 2009   = Submit Security Framework to the IESG to be considered as an = Informational RFC
May 2009     Submit the Routing for LLNs = Architecture document to the IESG as an Informational RFC.
July 2009 =    Submit first draft of ROLL routing protocol specification = as Proposed Standard.
Nov 2009     Submit first draft of = the MIB module of the ROLL routing protocol specification.
Dec 2009 =     Submit the ROLL routing protocol specification to the IESG = as Proposed Standard.

Here = I get very confused by two things:

- the date (10 = months from now), which is awfully short
- the singular form = ("the ROLL routing protocol") which contradicts the plural form used = earlier on in the charter.



<= div>We will change for Feb 2010.
We do not know whether there = will be one or = more.

Thanks.

JP.
<= br>
 

Jan 2010   =   Submit the MIB module of the ROLL routing protocol specification = to the IESG as Proposed Standard.
Jan 2010     Evaluate WG = progress, recharter or close.
 = _______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-35-924057470-- From jvasseur@cisco.com Mon Feb 16 02:57:13 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6214D3A6405 for ; Mon, 16 Feb 2009 02:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.571 X-Spam-Level: X-Spam-Status: No, score=-10.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kE2TjXZlEzxg for ; Mon, 16 Feb 2009 02:57:12 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D86843A67D2 for ; Mon, 16 Feb 2009 02:57:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,215,1233532800"; d="scan'208";a="33875537" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 16 Feb 2009 10:57:16 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1GAvGO9013527; Mon, 16 Feb 2009 11:57:16 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1GAvGOf003181; Mon, 16 Feb 2009 10:57:16 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 11:57:16 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 11:57:15 +0100 Message-Id: <4129B9F7-0294-4A4D-B72E-316B8AD1B801@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <49994514.3070200@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 16 Feb 2009 11:57:15 +0100 References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> <7F8096B9-1691-44D2-9032-6383C6C765B3@thomasclausen.org> <03CE3732-F1DC-44F4-9A2A-140FAD6CA531@cisco.com> <49994514.3070200@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 16 Feb 2009 10:57:15.0824 (UTC) FILETIME=[543CF300:01C99025] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=996; t=1234781836; x=1235645836; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20unicast=20and=20multicast=20traffic=20p atterns=20(was=3A=20=20[Roll]=20ROLL=20re-chartering) |Sender:=20; bh=PLcaWomQrGsh6pSbg5o+s5/WoTRt+UY107ksvNPPYnU=; b=JTq+LVX8VpEdrZhleH7vZU5cGYiDrnsid2BeTYz+9KLqWGgmyzpLV0LwIk tc93dQhhbX6aD9db9xVaJAySBIHXawd618RQkis1TbjYufJfTWczPZKRvpKB 84gecsG+oZ; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] unicast and multicast traffic patterns (was: ROLL re-chartering) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 10:57:13 -0000 OK. On Feb 16, 2009, at 11:51 AM, Alexandru Petrescu wrote: > Thomas Heide Clausen a =E9crit : > [...] >>>> IOW, we need to be much more specific with what the traffic =20 >>>> patterns then typically would be? >>> >>> We could be more specific on many items but we would end up with a =20= >>> very lengthy charter. These aspects are captured in the routing =20 >>> requirement IDs, which are the IDs where we specify the =20 >>> requirements that the protocol must satisfy. >>> >>> How about .... >>> >>> - Typically traffic patterns are not simply unicast flows (e.g. in =20= >>> some environments most if not all traffic can be point to =20 >>> multipoint) >> Much clearer, I think. > > On this particular point, me to I agree, it becomes clearer. If the =20= > terms unicast and multicast were used explicitely then it would make =20= > sense to me. > > Typically traffic patterns are not simply unicast flows but also =20 > multicast. > > Alex > > From chris.dearlove@baesystems.com Mon Feb 16 03:05:44 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE0AD3A67D2 for ; Mon, 16 Feb 2009 03:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoSHAMNzTDEb for ; Mon, 16 Feb 2009 03:05:44 -0800 (PST) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id B7B6A3A6A2A for ; Mon, 16 Feb 2009 03:05:43 -0800 (PST) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n1GB5pC0005264 for ; Mon, 16 Feb 2009 11:05:51 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n1GB5pmf002387 for ; Mon, 16 Feb 2009 11:05:51 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 16 Feb 2009 11:05:36 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 16 Feb 2009 11:05:50 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99026.849EE04B" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 16 Feb 2009 11:05:47 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] ROLL re-chartering Thread-Index: AcmQJU0t1+Bk5TPaTfO6MT0aZH+2rQAAL1hA References: <49994068.7040507@gmail.com> From: "Dearlove, Christopher (UK)" To: "JP Vasseur" X-OriginalArrivalTime: 16 Feb 2009 11:05:50.0819 (UTC) FILETIME=[8732F330:01C99026] Cc: ROLL WG Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 11:05:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99026.849EE04B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There have been a number of agreed changes in response to emails from various people. Could we have a revised draft with what the current state is please. (I want to review, and it would seem sensible not to possibly comment on something already changed.) =20 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** ------_=_NextPart_001_01C99026.849EE04B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
There have been a number of agreed changes in= response to=20 emails
from various people. Could we have a revised draft= with=20 what the
current state is please. (I want to review, and it= would=20 seem sensible
not to possibly comment on something= already=20 changed.)
 
****************************************************************= ****
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

------_=_NextPart_001_01C99026.849EE04B-- From Daniel.Smolinski@renesas.com Mon Feb 16 03:14:34 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6EBD3A6848 for ; Mon, 16 Feb 2009 03:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84DTFirAyYuu for ; Mon, 16 Feb 2009 03:14:34 -0800 (PST) Received: from mail02.idc.renesas.com (mail.renesas.com [202.234.163.13]) by core3.amsl.com (Postfix) with ESMTP id 82C413A67E4 for ; Mon, 16 Feb 2009 03:14:34 -0800 (PST) X-AuditID: ac140385-0000000b000002de-36-49994a38622f Received: from guardian01.idc.renesas.com ([172.20.8.200]) by mail02.idc.renesas.com (sendmail) with ESMTP id n1GBCuJq029459 for ; Mon, 16 Feb 2009 20:12:56 +0900 (JST) Received: (from root@localhost) by guardian01.idc.renesas.com with id n1GBCtYL000077 for roll@ietf.org; Mon, 16 Feb 2009 20:12:55 +0900 (JST) Received: from mta04.idc.renesas.com (localhost [127.0.0.1]) by mta04.idc.renesas.com with ESMTP id n1GBCsNP029327 for ; Mon, 16 Feb 2009 20:12:54 +0900 (JST) Received: from mail pickup service by rte-idc-bh1.RTE.ADWIN.RENESAS.COM with Microsoft SMTPSVC; Mon, 16 Feb 2009 11:12:49 +0000 Importance: normal Priority: normal Received: from rte-rat-exch.RTE.ADWIN.RENESAS.COM ([172.28.128.38]) by rte-idc-bh1.RTE.ADWIN.RENESAS.COM with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 Feb 2009 11:12:48 +0000 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.504 Date: Mon, 16 Feb 2009 12:12:47 +0100 Message-ID: <7BDC023EB136F0499F260228BE2991BC2E9994@rte-rat-exch.RTE.ADWIN.RENESAS.COM> In-Reply-To: <49993E3B.70509@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] ROLL re-chartering thread-index: AcmQIGfRzy3UKNdKT2y8QqTaat24HQABXLAw References: <49958529.5010306@gmail.com><89BA3B32-421E-4A24-B075-B5518E78FD35@cisco.com><49958D92.5040503@gmail.com><8157AC22-684F-4FA9-8240-AA481A404F22@cisco.com><49993A18.1040500@gmail.com><3833CB70-C16B-4C4F-B569-E8438BE1BD26@cisco.com> <49993E3B.70509@gmail.com> From: "Daniel Smolinski" To: "Alexandru Petrescu" , "JP Vasseur" X-OriginalArrivalTime: 16 Feb 2009 11:12:48.0965 (UTC) FILETIME=[806EF750:01C99027] X-Brightmail-Tracker: AAAAAA== Cc: roll-bounces@ietf.org, ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 11:14:34 -0000 Hi Alex, to me, lossy means that link communication can fail because of natural influences to the transmission media. It makes no difference if a = wireless link fails because some item temporarily blocks the path (or all paths) = or if a powerline link fails if the line impedance or noise spectrum = changes for some time. > Lossiness of PLC links could be avoided by setting them up properly, > don't plug the microwave oven if the manufacturer says so. I don't think that this is a valid solution to disturbances in the powerline. The PLC technology itself must be able to handle these = issues, either by the robustness of the PHY layer, link layer mechanisms or a combination of both. But, so should any technology, and if it fails due = to influences from the outside, it is lossy and this needs to be considered = in the routing. Daniel -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: Montag, 16. Februar 2009 11:22 To: JP Vasseur Cc: roll-bounces@ietf.org; David E. Culler; ROLL WG Subject: Re: [Roll] ROLL re-chartering JP Vasseur a =E9crit : >=20 > On Feb 16, 2009, at 11:04 AM, Alexandru Petrescu wrote: >=20 >> JP Vasseur a =E9crit : >>> On Feb 13, 2009, at 4:11 PM, Alexandru Petrescu wrote: >>>> JP Vasseur a =E9crit : >>>>> Hi Lars, On Feb 13, 2009, at 3:57 PM, Lars Eggert wrote: >>>>>> Hi, >>>>>>=20 >>>>>> On 2009-2-13, at 16:40, JP Vasseur wrote: >>>>>>> On Feb 13, 2009, at 3:35 PM, Alexandru Petrescu wrote: >>>>>>>> Jerald - ok, PLC is important. It's related to routing >>>>>>>> and energy transportation. >>>>>>>>=20 >>>>>>>> But. It doesn't sound as PLC devices having limited >>>>>>>> power, they sit on more power than they'd ever need. >>>>>>>=20 >>>>>>> As I tried to explain before, still you want these device >>>>>>> to consume as less energy as possible (e.g few dozens of >>>>>>> mW) thus there are constrained. If you have a house and >>>>>>> want to do energy management you could not afford to have >>>>>>> all these device consume 3W each. >>>>>>=20 >>>>>> I get the part about still wanting to have very low power=20 >>>>>> consumption in PLC scenarios, but ROLL is currently >>>>>> chartered to look at routing for low-powered *and lossy* >>>>>> networks. >>>>>>=20 >>>>> Well these low power PLC technologies and also loosy. >>>>=20 >>>> Well it's obvious wired communications aren't as lossy as >>>> wireless communications. >>>>=20 >>> do not think so ... I could provide you many pointers if you >>> will. >>=20 >> Is this saying that wireless _and_ wired communications are lossy? >> In this sense all links are lossy, and all protocols designed for >> them have taken that into account. >=20 > Many people tried to provide you answer. We mean that LLNs can be > made of lossy wired links, yes. Which does not mean that all wired > links are lossy of course ... JP, To explain: if a link is lossy, frustratingly non-deterministic, it may very well be because it's not correctly set up. In this sense, this lossiness is not relevant to any routing protocol. Lossiness of PLC links could be avoided by setting them up properly, don't plug the microwave oven if the manufacturer says so. I think that lossiness aspect is fundamentally different than lossiness aspect of battery-powered and 300Kb bluetooth 10m range as stated by its manufacturer. Alex _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll Renesas Technology Europe GmbH Sitz: Ratingen, Amtsgericht Duesseldorf, HRB 44903 Geschaeftsfuehrer: Peter Mies, Tsutomu Miki, Matthew Trowbridge, Holger = Zielke From jvasseur@cisco.com Mon Feb 16 03:19:59 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74E883A6B44 for ; Mon, 16 Feb 2009 03:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.571 X-Spam-Level: X-Spam-Status: No, score=-10.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVvVMcJ6YN7C for ; Mon, 16 Feb 2009 03:19:56 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E37433A6C08 for ; Mon, 16 Feb 2009 03:19:53 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,215,1233532800"; d="scan'208,217";a="33879108" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 16 Feb 2009 11:20:02 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1GBK2Nc021910; Mon, 16 Feb 2009 12:20:02 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1GBK1oI012250; Mon, 16 Feb 2009 11:20:01 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 12:19:56 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 12:19:54 +0100 Message-Id: From: JP Vasseur To: Thomas Heide Clausen In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-36-925439360 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 16 Feb 2009 12:19:53 +0100 References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> <7F8096B9-1691-44D2-9032-6383C6C765B3@thomasclausen.org> <03CE3732-F1DC-44F4-9A2A-140FAD6CA531@cisco.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 16 Feb 2009 11:19:55.0047 (UTC) FILETIME=[7E65EB70:01C99028] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=71268; t=1234783202; x=1235647202; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20re-chartering |Sender:=20; bh=2VyLy36p2MGcOJpouLXLSFaCvvXK/xrAXgr8PPt47Is=; b=sU0pB5Dg3WFqs7Y03tQfubDLkSZzfLtNlQWltyGJmU4DhG2OdUhuJtngGO 2OwDvLY4HHZGsyyQlwA/XYPw9TXJFy2I7l+2hKB0+ZGBSzwothe4RNAjh0jZ 4++m9KdQJf; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 11:19:59 -0000 --Apple-Mail-36-925439360 Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Thomas, We are converging ... :-) See further proposed changes below and let me know if that addressed your remaining concerns. On Feb 16, 2009, at 11:41 AM, Thomas Heide Clausen wrote: > JP, > > I'll be brief.... > > On Feb 16, 2009, at 11:02 AM, JP Vasseur wrote: > >> Hi Thomas, >> >> On Feb 16, 2009, at 9:49 AM, Thomas Heide Clausen wrote: >> >>> Dear JP, David, ROLL wg, >>> >>> (and, as I have a question to Alex, I Cc' him explicitly too) >>> >>> I've got a couple of comments to the charter below. I think it >>> needs a bit of clarification in some areas, and also the >>> relationship to current ROLL WG products needs to be clarified >>> IMO. See below for details -- most of which I believe are >>> questions that I raise that it should be fairly easy for a more >>> experienced person to simply answer and propose a one-sentence >>> clarification-edit to the charter to fix. >>> >>> On Feb 11, 2009, at 9:08 AM, JP Vasseur wrote: >>> >>>> Dear WG, >>>> >>>> As indicated in a previous email, the protocol survey I-D will be >>>> send for publication this week (after posting of the last >>>> revision incorporating several useful comments). >>>> >>>> As promised please find below the new proposed charter to be >>>> submitted to the IESG for approval. In the hope of getting >>>> quickly re-chartered thanks to let us know if you have any >>>> comment by the ned of this week. The new charter is pretty >>>> straightforward. >>>> >>>> Thanks to Dave Ward for his comments and guidance. >>>> >>>> Description of Working Group: >>>> >>>> Low power and Lossy networks (LLNs) are typically composed of many >>>> embedded devices with limited power, memory, and processing >>>> resources >>>> interconnected by a variety of links, such as IEEE 802.15.4, >>>> Bluetooth, >>>> Low Power WiFi 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. LLNs >>>> have specific characteristics: >>>> - LLNs operate with a hard, very small bound on state, >>>> - In most cases, LLN need to be optimized for energy saving, >>> >>> I am not sure that "in most cases" is entirely clear here. Does >>> this mean that we can get away with designing an "energy hungry" >>> routing protocol for ROLL, as long as we specify in which cases >>> it'd apply? >> >> Right this means that "energy saving" can be a soft constraint as >> opposed to a hard constraint with battery operated devices. > > Right, but this is kind of my point: designing for "most cases" will > also allow running on "better than most cases". In this case, > designing for "hard energy constraints" will mean that the protocol > also will run well on something with an embedded nuclear reactor ;) > > I'm wondering if it'd not be better to wrap all this up in a way > similar to the below: > > LLNs have varied characteristics, below a list of "extreme" such -- > obviously, > if a given LLN has better-than-these characteristics, it'll still > work fine, but a > LLN routing protocol MUST still be able to function under these > constraints: > > - Hard, small bound on state > - Energy > > > This'd make it clear to me. I think it'd also capture the suggestion > I made to Alex' issue? > >>> I'd be happier getting rid of "in most cases" and replacing >>> "energy saving" with "energy conservation" or something similar. >>> >> >> OK changing "energy saving" for "energy conservation" >> >>>> - Typical traffic patterns are not simply unicast flows, >>> >>> This, I have a big question mark to as well. It applies equally to >>> the survey I-D, but I'll comment on that I-D in another email. >>> >>> Essentially, as a protocol designer, I'd expect a wg charter to >>> help me understand the constraints under which I'd be designing a >>> protocol. Reading the above item teaches me that I shouldn't >>> design for "simply unicast flows", but what does that mean? Could >>> I disregard unicast entirely and just build a multicast protocol? >>> Do I then need group mgmt? Or is simple "roll-wide broadcast" all >>> that's needed? Or all of the above? None of the above? >>> >>> IOW, we need to be much more specific with what the traffic >>> patterns then typically would be? >> >> We could be more specific on many items but we would end up with a >> very lengthy charter. These aspects are captured in the routing >> requirement IDs, which are the IDs where we specify the >> requirements that the protocol must satisfy. >> >> How about .... >> >> - Typically traffic patterns are not simply unicast flows (e.g. in >> some environments most if not all traffic can be point to multipoint) > > Much clearer, I think. OK Changed. > [side-note/question/not-charter-as-such: does this mean that a ROLL > protocol should be multicast-capable?] > I'll leave this for a different thread ;-) > >>>> - In most cases, LLNs need to be effective with very small >>>> packet sizes, >>> >>> I've gone back and forth over this, and it's also a comment that I >>> think needs clarification in the survey I-D. First, I think that >>> it'd be helpful to say something as to "how small". >> >> But we do not want to be PHY/MAC specific. Here we list a general >> LLN characteristic. >> >>> Second, to which extend are we looking at transport [and other] >>> issues in ROLL. >>> >> >> We do not. This is spelled out below in the charter. >> >>> I can read this in different ways, here's my first impulse on that >>> bullet point: >>> >>> o ROLL runs over LLs with an extremely restricted frame-size, so >>> something akin to >>> IP header compression is on the table [are we then in RTG?]. >>> >>> o Presumably, the "very small packet sizes" also applies for >>> data. Is this, then, >>> a generic IP-over-FOO problem? >>> >>> I can guess at what the intent would be, but we need to spell it >>> out here. >> >> The former of course ... and in "most cases" (e.g. 15.4). > > That's what I'd have suspected as well, although reading the charter > gave me a slightly different impression. Trying to be constructive, > how 'bout, then, some variation over the following: > > - In most cases, LLNs will be employed over L2 with extremely > restricted frame-sizes, > thus a routing protocol for LLNs should be specifically adapted > for such? > > (I'm sure that it can be phrased better, but I think it'd be more > unambiguous that way) > If that helps clarifying I'm all for it: NEW: "In most cases, LLNs will be employed over L2 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. >>> >>> I can see where Alexandru's question come from at this point, when >>> we were talking about power-lines and such. >>> >>> Essentially, what we're wanting to say [I think] is that "ROLL >>> protocols MUST be able to run on routers with [very-strict-set-of- >>> restrictions]" -- and that there then may be a few routers with >>> "better than [very-strict-set-of-restrictions]" shouldn't be >>> driving our design, and that such routers are present is purely >>> incidental. >>> >>> IOW, I'd suggest rephrasing this slightly, to say "these are the >>> requirements that ROLL protocols shall satisfy -- if a device does >>> better than that, more power to it, but it's not our primary >>> design target". >>> >>> Alex, would a rephrasing like this satisfy you? > > As I suggested above, this would also satisfy my other comment. OK. > >>> >>>> These unique properties lead to unique routing requirements that >>>> may not met by >>>> existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. >>>> For >>>> example path selection must be designed to take into >>>> consideration the >>>> specific power capabilities, attributes and functional >>>> characteristics >>>> of the links and nodes in the network. >>> >>> Request for clarification (a question may or may not follow): is >>> multi-metric QoS thereby an explicit design requirement? >>> >> >> That could be the case but again we cannot list all requirements in >> the charter. They are specified in the requirement documents. > > OK, you answered my question. > >> >>> Also, it seems from the sentence construction that it is inferred >>> that "OSPF, IS-IS, AODV and OLSR" do not have the capability to >>> take "power capabilities, attributes and functional >>> characteristics of the links and nodes in the network" into >>> consideration. I'm not sure that that's the entire truth. Can this >>> be clarified a notch? >> >> We do say "existing". Not sure which clarification you want ? > > Ok, I may not have been clear. OSPF, IS-IS, AODV and OLSR do all > support QoS in some form or other, i.e. they are able to take these > (power, attributes, ...) into account. It reads as if the charter is > saying "no they don't". It may be that they don't do so in a > desirable way (in which case, that should be analyzed and stated). Ah I see what you mean now: Proposal: OLD: These specific properties cause LLNs to have specific routing requirements that existing routing protocols, such as OSPF, IS-IS, AODV, and OLSR, do not meet. For example, path selection must at times consider the specific power capabilities, attributes, and functional characteristics of links and nodes in the network. NEW These specific properties cause LLNs to have specific routing requirements that existing routing protocols, such as OSPF, IS-IS, AODV, and OLSR, do not meet. Simply delete the last sentence, which may be confusing I agree. Deleted: For example, path selection must at times consider the specific power capabilities, attributes, and functional characteristics of links and nodes in the network. > >>>> The Working Group is focused on routing issues for LLN >>> >>> Alright, so routing issues only. Fair enough -- but what's the >>> relationship then with the "very small packet sizes" bullet point >>> above? Do we expect [other-wg] to resolve this issue, >> >> A good example being 6lowpan. > > Would it make sense to reference that in the charter? "The ROLL wg > will pay attention to other IETF work addressing topics within the > ROLL space, e.g. 6lowpan, )". I've seen that done > for other WG charters, and found it immensely helpful when diving > into a new wg and trying to find foothold. The only issue is that I do not want to create inter-dependencies between WGs. Today 6lowpan is exclusively focusing on 15.4, this may change ... > >> >>> or is there routing-only-issues that need be brought forward? If >>> so, which? >>> >> >> This "a" characteristic since you asked to spell out a bit more >> precisely LLN's characteristics (and this was an excellent idea). > > And, I think, that it was excellently taken on board as well, and I > appreciate both the survey I-D and the charter for having done so. > >> An obvious consequence being that the routing protocol cannot >> afford to send to large frames (in some cases). Detailed >> requirements again are in application-specific routing requirements >> documents. > > Yep, agreed. I think that the suggestion that I made above would > just about cover this issue. I agree that we do not want to be too > verbose here, so I think it'd be a small fix. OK. > >> >>>> There is a wide scope of application areas for LLNs, including >>>> industrial monitoring, building automation (HVAC, lighting, access >>>> control, fire), connected home, healthcare, environmental >>>> monitoring, >>>> urban sensor networks sensor networks, assets tracking, >>>> refrigeration. >>>> The Working Group will only focus on routing solutions for a >>>> subset of >>>> these. It will focus on industrial, connected home, building and >>>> urban >>>> sensor networks and specify the set of routing requirements for >>>> these scenarios. >>> >>> Question: does the above entail "new work", or is this in >>> reference to the current requirement I-Ds? >> >> Good catch, it should read: "It focuses on industrial, connected >> home, building and urban sensor networks and specify the set of >> routing requirements for these scenarios." > > Glad to not be entirely useless ;) ;-) Hey I never implied any such thing ;-)) > >>>> The Working Group focuses only on IPv6 only routing architectural >>>> framework for these application scenarios. >>> >>> Question: by "architectural framework", what exactly is to be >>> understood? >> >> A routing architecture ID (pointed out in the WG item). > > OK, I am not quite sure what that is, though? Maybe it's me being > dense, do you have a reference to something akin to this, just for > my personal education? Sure, RFC4655 or RFC3945 > >>>> 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 explore aspects of mobility within a >>>> single LLN >>>> (if any) in the routing requirement creation. >>> >>> Does this entail a new "routing requirements" document being >>> produced? >>> >> >> Another good point. We can remove that last sentence. > > ;) > >>>> The Working Group will pay particular attention to routing >>>> security and >>>> manageability (e.g., self configuration) issues. It will also >>>> need to >>>> consider the transport characteristic the routing protocol >>>> messages will >>>> experience. >>> >>> This goes back to my previous question: IP-over-foo or ? >>> >>> >>> More broadly, how are the current ROLL products (survey I-D, rtg >>> requirements) expected to be employed in all this? >> >> Quite clear: >> 1) The survey was there to figure out whether *existing* protocol >> could meet the requirements. The answer is "no" >> 2) Requirements are used to produce the protocol (extensions or new). > > I just wonder if those "findings" (or at least the documents > containing those) need not get mention in the charter? Good suggestion. How about: OLD: These specific properties cause LLNs to have specific routing requirements that existing routing protocols, such as OSPF, IS-IS, AODV, and OLSR, do not meet. For example, path selection must at times consider the specific power capabilities, attributes, and functional characteristics of links and nodes in the network. NEW These specific properties cause LLNs to have specific routing requirements. As shown in a protocol survey existing routing protocols (in their current form) such as OSPF, IS-IS, AODV, and OLSR, do not meet these specific routing requirements. And then .. OLD: ... It will focus on industrial, connected home, building and urban sensor networks and specify the set of routing requirements for these scenarios ... NEW: The Working Group focuses on industrial, connected home, building and urban sensor networks and has specified the set of routing requirements for these scenarios. These application-specific routing requirement documents will be used for protocol design. > >>> Finally, in summarizing the charter, ROLL aims at solving: >>> >>> o routing over wireless >>> o scalability to several thousands of routers >>> o QoS in wireless networks, including >>> o formalization of wireless link metrics >>> o security >> >> Not just wireless at discussed on the ML, not sure why you mention >> QoS in wireless network (at most we do QoS routing), ... > > Ok, remove "in wireless networks, including" from the list above, > the rest of my comment still stands -- it seems very ambitious > scheduling. We have pushed the time line to Feb 09. Thanks for the help. JP. > > > Thomas > >>> within 10 months, and to the level of proposed standard. >>> >>> The items are very interesting, but 10 months is also *very* short >>> -- and the complexity of some of those is not trivial without >>> making serious concessions in some areas. >> >> It is aggressive but should we end up extending an existing >> protocol does not take so much time. The good thing is that we >> spent a lot of time spelling out all requirements, which will ease >> the protocol design phase. We can always add a few months to the >> last milestone. >> >> Let me cite from an email from Dave Ward (Feb. 3, 2009) >>> >>> On Feb 3, 2009, at 5:52 PM, David Ward wrote: >>>> I expect "wild swings" of the design pattern of the protocol >>>> during the first year of the design effort. I attempted to make >>>> this clear at the mic in Minneapolis that the current trajectory >>>> is very complex problem domain that hasn't born a lot of fruit >>>> but, that in the design phase reducing the complexity must occur. >>> >>> >>> Considering the complexity of the list of items above, I am much >>> more in line with what Dave Ward writes, than with what the >>> milestones suggest. >> >> >> Thanks. >> >> JP. >> >>> >>> Thomas >>> >>> >>>> 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. >>>> >>>> >>>> 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 protocols 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: In light of the application specific routing >>>> requirements, the Working Group will either specify a new >>>> protocol and/or will select an existing routing protocol (with >>>> the appropriate extensions in cooperation with the relevant >>>> Working Group). >>>> >>>> - Documentation of applicability statement of ROLL routing >>>> protocols. >>>> >>>> Goals and Milestones: >>>> >>>> Done Submit Routing requirements for Industrial applications to >>>> the IESG to be considered as an Informational RFC. >>>> Done Submit Routing requirements for Connected Home networks >>>> applications to the IESG to be considered as an Informational RFC. >>>> Done Submit Routing requirements for Building applications to >>>> the IESG to be considered as an Informational RFC. >>>> Done Submit Routing requirements for Urban networks >>>> applications to the IESG to be considered as an Informational RFC. >>>> July 2009 Submit Routing metrics for LLNs document to the IESG >>>> to be considered as a Proposed Standard. >>>> * Feb 2009 Submit Protocol Survey to the IESG to be considered >>>> as an Informational RFC. >>>> April 2009 Submit Security Framework to the IESG to be >>>> considered as an Informational RFC >>>> May 2009 Submit the Routing for LLNs Architecture document to >>>> the IESG as an Informational RFC. >>>> July 2009 Submit first draft of ROLL routing protocol >>>> specification as Proposed Standard. >>>> Nov 2009 Submit first draft of the MIB module of the ROLL >>>> routing protocol specification. >>>> Dec 2009 Submit the ROLL routing protocol specification to >>>> the IESG as Proposed Standard. >>>> Jan 2010 Submit the MIB module of the ROLL routing protocol >>>> specification to the IESG as Proposed Standard. >>>> Jan 2010 Evaluate WG progress, recharter or close. >>>> >>>> PS: I marked * the Milestones that will be "This Week" and before >>>> submitting to the IESG for re-chartering. >>>> >>>> >>>> >>>> Thanks. >>>> >>>> JP and David. >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>> >> > --Apple-Mail-36-925439360 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi = Thomas,

We are converging ... :-) See further = proposed changes below and let me know if that addressed = your remaining concerns.

On Feb 16, = 2009, at 11:41 AM, Thomas Heide Clausen wrote:

JP,

I'll be = brief....

On Feb 16, 2009, at 11:02 AM, JP = Vasseur wrote:

Hi Thomas,

On Feb 16, 2009, at 9:49 AM, = Thomas Heide Clausen wrote:

Dear JP, David, ROLL = wg,

(and, as I have a question to Alex, I Cc' him = explicitly too)

I've got a couple of comments to the = charter below. I think it needs a bit of clarification in some areas, = and also the relationship to current ROLL WG products needs to be = clarified IMO. See below for details -- most of which I believe are = questions that I raise that it should be fairly easy for a more = experienced person to simply answer and propose a one-sentence = clarification-edit to the charter to = fix.

On Feb 11, 2009, at 9:08 AM, JP = Vasseur wrote:

Dear WG,

As = indicated in a previous email, the protocol survey I-D will be send for = publication this week (after posting of the last revision incorporating = several useful comments).

As promised please find below = the new proposed charter to be submitted to the IESG for approval. In = the hope of getting quickly re-chartered thanks to let us know if you = have any comment by the ned of this week. The new charter is pretty = straightforward.

Thanks to Dave Ward for his comments and = guidance.

Description of Working Group:

Low = power and Lossy networks (LLNs) are typically composed of many
embedded devices with limited power, memory, and = processing resources
interconnected by a variety = of links, such as IEEE 802.15.4, Bluetooth,
Low = Power WiFi 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
-       LLNs operate = with a hard, very small bound on state,
-       In most = cases, LLN need to be optimized for energy = saving,

I am not sure that "in most = cases" is entirely clear here. Does this mean that we can get away with = designing an "energy hungry" routing protocol for ROLL, as long as we = specify in which cases it'd apply? =

Right this = means that "energy saving" can be a soft constraint as opposed to a hard = constraint with battery operated = devices.

Right, but this is = kind of my point: designing for "most cases" will also allow running on = "better than most cases". In this case, designing for "hard energy = constraints" will mean that the protocol also will run well on something = with an embedded nuclear reactor ;)

I'm = wondering if it'd not be better to wrap all this up in a way similar to = the below:

LLNs have varied characteristics, = below a list of "extreme" such -- obviously, 
if a = given LLN has better-than-these characteristics, it'll still work fine, = but a 
LLN routing protocol MUST still = be able to function under these = constraints:

- Hard, = small bound on state
- = Energy
<etc - rest of = list>

This'd make it clear to me. I think = it'd also capture the suggestion I made to Alex' = issue?

I'd be happier getting rid of "in = most cases" and replacing "energy saving" with "energy conservation" or = something = similar.


OK changing "energy saving" for "energy = conservation"

-   =     Typical traffic patterns are not simply unicast = flows,

This, I have a big question mark = to as well. It applies equally to the survey I-D, but I'll comment on = that I-D in another email.

Essentially, as a = protocol designer, I'd expect a wg charter to help me understand the = constraints under which I'd be designing a protocol. Reading the above = item teaches me that I shouldn't design for "simply unicast flows", but = what does that mean? Could I disregard unicast entirely and just build a = multicast protocol? Do I then need group mgmt? Or is simple "roll-wide = broadcast" all that's needed? Or all of the above? None of the = above?

IOW, we need to be much more specific = with what the traffic patterns then typically would = be?

We could be = more specific on many items but we would end up with a = very lengthy charter. These aspects are captured in the = routing requirement IDs, which are the IDs where we specify the = requirements that the protocol must = satisfy.

How about = ....

- Typically traffic patterns are not = simply unicast flows (e.g. in some environments most if not = all traffic can be point = to multipoint)

Much = clearer, I think.

OK = Changed.

[side-note/question/not-charter-as-such: = does this mean that a ROLL protocol should be = multicast-capable?]


=
I'll leave this for a different thread = ;-)


-   =     In most cases, LLNs need to be effective with very = small packet sizes,

I've gone back = and forth over this, and it's also a comment that I think needs = clarification in the survey I-D. First, I think that it'd be helpful to = say something as to "how small". =

But we do = not want to be PHY/MAC specific. Here we list a general = LLN characteristic. 

Second, to = which extend are we looking at transport [and other] issues in = ROLL.


We do not. This is spelled out below in the = charter.

I can read this in different = ways, here's my first impulse on that bullet = point:

o ROLL runs over LLs with an = extremely restricted frame-size, so something akin = to 
IP header = compression is on the table [are we then in = RTG?].

o Presumably, the "very small = packet sizes" also applies for data. Is this, then,
a = generic IP-over-FOO problem?

I can guess at = what the intent would be, but we need to spell it out = here.

The = former of course ... and in "most cases" (e.g. = 15.4).

That's what I'd have = suspected as well, although reading the charter gave me a slightly = different impression. Trying to be constructive, how 'bout, then, some = variation over the following:

- In most = cases, LLNs will be employed over L2 with extremely restricted = frame-sizes,
thus a routing protocol = for LLNs should be specifically adapted for = such?

(I'm sure that it can be phrased = better, but I think it'd be more unambiguous that = way)


If = that helps clarifying I'm all for = it:

NEW:

"In most = cases, LLNs will be employed over L2 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.

I can see = where Alexandru's question come from at this point, when we were talking = about power-lines and such.

Essentially, what = we're wanting to say [I think] is that "ROLL protocols MUST be able to = run on routers with [very-strict-set-of-restrictions]" -- and that there = then may be a few routers with "better than = [very-strict-set-of-restrictions]" shouldn't be driving our design, and = that such routers are present is purely = incidental.

IOW, I'd suggest rephrasing this = slightly, to say "these are the requirements that ROLL protocols shall = satisfy -- if a device does better than that, more power to it, but it's = not our primary design target".

Alex, would a = rephrasing like this satisfy = you?

As I suggested above, this would also satisfy my other = comment.

OK.

These unique properties lead = to unique routing requirements that may not met by
 existing routing protocols, = such as OSPF, IS-IS, AODV and OLSR. For
example = path selection must be designed to take into consideration the
specific power capabilities, attributes and = functional characteristics
of the links = and nodes in the network.

Request for = clarification (a question may or may not follow): is multi-metric QoS = thereby an explicit design = requirement?


<= /div>
That could be the case but again we cannot list all = requirements in the charter. They are specified in the requirement = documents.

OK, you answered = my question.


Also, it seems = from the sentence construction that it is inferred that "OSPF, IS-IS, = AODV and OLSR" do not have the capability to take "power capabilities, = attributes and functional characteristics of the links and nodes in the = network" into consideration. I'm not sure that that's the entire truth. = Can this be clarified a = notch?

We do say = "existing". Not sure which clarification you want = ?

Ok, I may not have = been clear. OSPF, IS-IS, AODV and OLSR do all support QoS in some form = or other, i.e. they are able to take these (power, attributes, ...) into = account. It reads as if the charter is saying "no they don't". It may be = that they don't do so in a desirable way (in which case, that = should be analyzed and = stated).

Ah I = see what you mean = now:

Proposal:

OLD:
NEW

These specific = properties cause LLNs to have specific routing requirements that existing routing protocols, such as OSPF, IS-IS, AODV, and OLSR, do not = meet. 

Simply delete the = last sentence, which may be confusing I agree.

Deleted: For = example, path selection must at times consider the specific power capabilities, = attributes, and functional characteristics of links and nodes in the = network.

 =

The Working Group is focused = on routing issues for = LLN

Alright, so routing issues = only. Fair enough -- but what's the relationship then with the "very = small packet sizes" bullet point above? Do we expect [other-wg] to = resolve this issue, =

A good example = being 6lowpan.

Would it = make sense to reference that in the charter? "The ROLL wg will pay = attention to other IETF work addressing topics within the ROLL space, = e.g. 6lowpan, <complete-the-list>)". I've seen that done for other WG = charters, and found it immensely helpful when diving into a new wg and = trying to find = foothold.

The only = issue is that I do not want to create inter-dependencies between WGs. = Today 6lowpan is exclusively focusing on 15.4, this may change = ...



or is there = routing-only-issues that need be brought forward? If so, = which?


<= div>This "a" characteristic since you asked to spell out a bit = more precisely LLN's characteristics (and this was an = excellent idea).

And, = I think, that it was excellently taken on board as well, and I = appreciate both the survey I-D and the charter for having done = so.

An obvious = consequence being that the routing protocol cannot afford to send to = large frames (in some cases). Detailed requirements again are in = application-specific routing requirements = documents.

Yep, = agreed. I think that the suggestion that I made above would just about = cover this issue. I agree that we do not want to be too verbose here, so = I think it'd be a small = fix.

OK.

=

There is = a wide scope of application areas for LLNs, including
 industrial monitoring, = building automation (HVAC, lighting, access
urban sensor networks sensor = networks, assets tracking, refrigeration.
The = Working Group will only focus on routing solutions for a subset = of
these. It will focus on industrial, connected = home, building and urban
 sensor networks and specify = the set of routing requirements for
 these = scenarios.

Question: does the above = entail "new work", or is this in reference to the current requirement = I-Ds?

Good = catch, it should read: "It focuses on industrial, connected home, = building and urban sensor networks and specify the set of routing = requirements for these = scenarios."

Glad to not be = entirely useless = ;)

;-) Hey I never = implied any such thing ;-))


The Working Group focuses only = on IPv6 only routing architectural
 framework for these = application scenarios.

Question: = by "architectural framework", what exactly is to be = understood?

= A routing architecture ID (pointed out in the WG = item).

OK, I am not = quite sure what that is, though? Maybe it's me being dense, do you have = a reference to something akin to this, just for my personal = education?


Sure, RFC4655 or RFC3945


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 explore aspects of mobility = within a single LLN
(if any) in the routing = requirement creation.

Does this entail = a new "routing requirements" document being = produced?


Another good point. We can remove that last = sentence.

;)

The = Working Group will pay particular attention to routing security = and
manageability (e.g., self = configuration) issues. It will also need to
 consider the transport = characteristic the routing protocol messages will
 experience.

This goes back to my previous question: IP-over-foo = or ?


More broadly, how are the = current ROLL products (survey I-D, rtg requirements) expected to be = employed in all = this?

Quite = clear:
1) The survey was there to figure out whether = *existing* protocol could meet the requirements. The answer is = "no"
2) Requirements are used to produce the protocol = (extensions or new).

I = just wonder if those "findings" (or at least the documents containing = those) need not get mention in the = charter? 

Goo= d suggestion. How = about:

OLD:
These specific = properties cause LLNs to have specific routing requirements that = existing routing protocols, such as OSPF, IS-IS, AODV, and OLSR, do not = meet. For example, path selection must at times consider the specific = power capabilities, attributes, and functional characteristics of links = and nodes in the network.

These = specific properties cause LLNs to have specific routing requirements. As = shown in a protocol survey existing routing protocols (in their current = form) such as OSPF, IS-IS, AODV, and OLSR, do not meet these specific = routing requirements.


And then = ..

OLD:

... It will focus = on industrial, connected home, building and urban=E2=80=A8 sensor = networks and specify the set of routing requirements for=E2=80=A8 these scenarios = ...

NEW:

The Working Group = focuses on industrial, connected home, building and urban=E2=80=A8 sensor = networks and has specified the set of routing requirements for=E2=80=A8 = these scenarios. These application-specific routing requirement documents will be used for protocol = design.




o  routing = over wireless
o scalability to several thousands = of routers
o QoS in wireless networks, = including
o formalization of wireless link = metrics
o = security

No= t just wireless at discussed on the ML, not sure why you mention QoS in = wireless network (at most we do QoS routing), = ...

Ok, remove "in = wireless networks, including" from the list above, the rest of my = comment still stands -- it seems very ambitious = scheduling.

We = have pushed the time line to Feb 09.

Thanks for = the help.

JP.


Let = me cite from an email from Dave Ward (Feb. 3, = 2009)

On Feb 3, 2009, at = 5:52 PM, David Ward wrote:
I expect "wild swings" of the design pattern of the protocol = during the first year of the design effort. I = attempted to make this clear at the mic in Minneapolis that the current = trajectory is very complex problem domain that hasn't born a lot of = fruit but, that in the design phase reducing the complexity must = occur. 

Con= sidering the complexity of the list of items above, I am much more in = line with what Dave Ward writes, than with what the milestones = suggest.


Thanks.

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


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 protocols 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: In light of the application specific routing = requirements, the Working Group will either specify a new protocol = and/or will select an existing routing protocol (with the appropriate = extensions in cooperation with the relevant Working Group).

- = Documentation of applicability statement of ROLL routing = protocols.

Goals and Milestones:

Done   Submit Routing = requirements for Industrial applications to the IESG to be considered as = an Informational RFC.
Done   Submit  Routing requirements for = Connected Home networks applications to the IESG to be considered as an = Informational RFC.
Done   Submit Routing = requirements for Building applications to the IESG to be considered as = an Informational RFC.
Done   Submit Routing = requirements for Urban networks applications to the IESG to be = considered as an Informational RFC.
July = 2009    Submit = Routing metrics for LLNs document to the IESG to be considered as a = Proposed Standard.
* Feb 2009   Submit Protocol Survey to = the IESG to be considered as an Informational RFC.
April 2009   Submit Security Framework = to the IESG to be considered as an Informational RFC
May 2009   =   Submit the Routing for LLNs Architecture document to the = IESG as an Informational RFC.
July = 2009    Submit = first draft of ROLL routing protocol specification as Proposed = Standard.
Nov 2009     Submit first draft = of the MIB module of the ROLL routing protocol specification.
Dec 2009   =   Submit the ROLL routing protocol specification to the IESG = as Proposed Standard.
Jan 2010     Submit the MIB = module of the ROLL routing protocol specification to the IESG as = Proposed Standard.
Jan 2010     Evaluate WG = progress, recharter or close.

PS: I marked * the Milestones = that will be "This Week" and before submitting to the IESG for = re-chartering.




JP and David.
Roll mailing list
=




<= /html>= --Apple-Mail-36-925439360-- From jvasseur@cisco.com Mon Feb 16 03:24:59 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14E813A68D2 for ; Mon, 16 Feb 2009 03:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.573 X-Spam-Level: X-Spam-Status: No, score=-10.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaEFWs81xnZj for ; Mon, 16 Feb 2009 03:24:58 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7617B3A6A8F for ; Mon, 16 Feb 2009 03:24:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,216,1233532800"; d="scan'208";a="33879860" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Feb 2009 11:25:06 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1GBP69B005244; Mon, 16 Feb 2009 12:25:06 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1GBP6X3014200; Mon, 16 Feb 2009 11:25:06 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 12:25:06 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 12:25:05 +0100 Message-Id: <3C213BBC-117D-4C59-BDAF-198382C7A8CE@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <499942A3.5020005@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 16 Feb 2009 12:25:04 +0100 References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> <7F8096B9-1691-44D2-9032-6383C6C765B3@thomasclausen.org> <499938BF.8030409@gmail.com> <906CC3B7-E1D2-428A-BF1F-BDBB676DA088@cisco.com> <499942A3.5020005@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 16 Feb 2009 11:25:05.0524 (UTC) FILETIME=[3774F340:01C99029] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3614; t=1234783506; x=1235647506; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20re-chartering |Sender:=20; bh=KKNNPyfGvGMGXfKO3pS7xUX62KN/unesZRPx0/WhQT0=; b=pLQkPwV/2ky2bPRWyXvMHDaIpkJlHbcBxqN0WxlxYA5v1T33Y9HC1ILoVP H/e2WigTG24oFJNlyP101cXgUvcPtwQ/XjpOQT3wKTbJ/l2dB48GflgAxO58 HTS87wV+31; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 11:24:59 -0000 On Feb 16, 2009, at 11:40 AM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> On Feb 16, 2009, at 10:58 AM, Alexandru Petrescu wrote: >>> Thomas Heide Clausen a =E9crit : >>> [...] >>>> I can see where Alexandru's question come from at this point, =20 >>>> when we >>>> were talking about power-lines and such. >>>> Essentially, what we're wanting to say [I think] is that "ROLL =20 >>>> protocols MUST be able to run on routers with [very-strict-set-of-=20= >>>> restrictions]" -- and that there then may be a few routers with =20 >>>> "better than [very-strict-set-of-restrictions]" shouldn't be =20 >>>> driving our design, and that such routers are present is >>>> purely incidental. >>>> IOW, I'd suggest rephrasing this slightly, to say "these are the =20= >>>> requirements that ROLL protocols shall satisfy -- if a device =20 >>>> does better than that, more power to it, but it's not our primary =20= >>>> design target". >>> >>> This rephrasing sounds better to me. >> What is exactly the proposed rephrasing ? > > If one agrees with a distinction in energy between PLC device and =20 > batter-powered devices. > > Then a clarifying suggestion could be the following. > > Instead of: >> Low power and Lossy networks (LLNs) are typically composed of many >> embedded devices with limited power, memory, and processing resources >> interconnected by a variety of links, such as IEEE 802.15.4, =20 >> Bluetooth, >> Low Power WiFi or other low power PLC (Powerline Communication) =20 >> 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. LLNs =20 >> have specific characteristics: >> - LLNs operate with a hard, very small bound on state, >> - In most cases, LLN need to be optimized for energy saving, >> - Typical traffic patterns are not simply unicast flows, >> - In most cases, LLNs need to be effective with very small =20 >> packet sizes, >> - LLN routing protocols have to be very careful when trading =20= >> off efficiency for generality; many LLN nodes do not have resources =20= >> to waste. > > Suggested text: > " > Low power and Lossy networks (LLNs) are typically composed of many > embedded devices with limited power, memory, and processing resources > interconnected by a variety of links, such as IEEE 802.15.4, =20 > Bluetooth, > Low Power WiFi or other low power links [remove: PLC (Powerline =20 > Communication) links]. LLNs are transitioning to an end-to-end IP-=20 > based > solution to avoid the problem of non-interoperable networks > interconnected by protocol translation gateways and proxies. LLNs =20 > have specific characteristics: > - ... > - They are securely connected to the Internet. > > - LLN devices and links are linked together with other > devices and links, which are not energy-constrained and whose > bandwidth/latency/range/emissionpower could be orders of > magnitude better, e.g. PLC devices. > " > > Would you agree with this PLC distinction and the explicit statement =20= > of Internet connectivity? > Sorry but not sure what you mean ... 1) On Internet connectivity, some LLNs may not be connected to the =20 Internet at all (not typical I agree). 2) The changes you propose above for PLC are very ambiguous ... I saw =20= that someone replied to you on this and helped you understand a bit =20 better the PLC issue. Thanks. JP. > Alex > > From emmanuel.baccelli@gmail.com Mon Feb 16 03:59:23 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 071723A6801 for ; Mon, 16 Feb 2009 03:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.356 X-Spam-Level: X-Spam-Status: No, score=-1.356 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3-RMuszrk0L for ; Mon, 16 Feb 2009 03:59:22 -0800 (PST) Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by core3.amsl.com (Postfix) with ESMTP id C14C03A683D for ; Mon, 16 Feb 2009 03:59:21 -0800 (PST) Received: by fxm13 with SMTP id 13so5675609fxm.13 for ; Mon, 16 Feb 2009 03:59:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=8O+qT0mwzCEAiS5W9WRbsuC559YThLPJT6875C2zKRk=; b=XfUtFAUZqxTl8TR2kCwtPwIDZw4ZPA8srpj7X5cZYTzB1rNXsvqSopFdc6HCF+t3Oj 03BrTfusSPePzthvMZdAPyrgM622xCuKHFyXTLPb20nzAuEB1/LoUZyVWTP6L/zrjuxd 0BME0UvY5XVyJyEbVLarmEmbw446QLjhITTg0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=brJ2thQwuCqErR1xg0sYUhkRhZXa/KW9WLYq50oYEODzdJDhq0+otrnlamnFcKFqkA oAjt2yrtjYvwuT8MAGaFhS4gtIS3/5n0fOzVQqGzEqp66rDgrSrBfgh4yIj3h09f1VCv avzhNUm8DWWUnes93fI14mHKPo+WM4AEed1c4= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.103.252.17 with SMTP id e17mr2853296mus.14.1234785570190; Mon, 16 Feb 2009 03:59:30 -0800 (PST) In-Reply-To: References: <49994068.7040507@gmail.com> Date: Mon, 16 Feb 2009 12:59:30 +0100 X-Google-Sender-Auth: 46e127d05a7990e8 Message-ID: From: Emmanuel Baccelli To: roll@ietf.org Content-Type: multipart/alternative; boundary=001636417ed548f73a046307ebb8 Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 11:59:23 -0000 --001636417ed548f73a046307ebb8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I agree with Chris. I'll comment further on the revision.Emmanuel On Mon, Feb 16, 2009 at 12:05 PM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > There have been a number of agreed changes in response to emails > from various people. Could we have a revised draft with what the > current state is please. (I want to review, and it would seem sensible > not to possibly comment on something already changed.) > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --001636417ed548f73a046307ebb8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree with Chris. I'll comment further on the revision.
Emmanuel<= br>
On Mon, Feb 16, 2009 at 12:05 PM, Dearlov= e, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
There have been a number of agreed changes in response to=20 emails
from various people. Could we have a revised draft with=20 what the
current state is please. (I want to review, and it would=20 seem sensible
not to possibly comment on something already=20 changed.)
 
*********= ***********************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************


__________________________= _____________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll


--001636417ed548f73a046307ebb8-- From emmanuel.baccelli@gmail.com Mon Feb 16 04:09:30 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 262B63A68FC for ; Mon, 16 Feb 2009 04:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mayvqfbAB8ir for ; Mon, 16 Feb 2009 04:09:29 -0800 (PST) Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by core3.amsl.com (Postfix) with ESMTP id F08CA3A68C2 for ; Mon, 16 Feb 2009 04:09:28 -0800 (PST) Received: by fxm13 with SMTP id 13so5689893fxm.13 for ; Mon, 16 Feb 2009 04:09:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=ee5PJvFjm14+JdwZtPlrcugtH1KeXAcW5xqPSGHyNBM=; b=vfP9BrhuR7mYVDIy8OQEW1mvK3mnPbIoK3d55PCYWE4s1LnvVYO1TcyXVFwTsqK2iq OG7q56SZVU+61W4TPzGbKZSW84bPWHjmAi4xm35y9pq6bnbOmx49AEtxUce5BLMEQdP7 Lp4BdmjmeGVWETEh6KJid3C8dBRABktaW1PvY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=AxAZ9r7/yJ9c97oRhSMUVVf7z15fvUlretp+Y7yXwrlI5SgewOD3an+tscLCKdduUf 9C+w/DawuJ538aGO3dD8QJk0Z3nQtQgoplCGrJo7DBQSEq5b/IR/UzW39njstXa46LMq wK6vSGlY0q9dD4CPtgo3IQtdkQdaVNIR9SLqA= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.103.243.9 with SMTP id v9mr666638mur.91.1234786177084; Mon, 16 Feb 2009 04:09:37 -0800 (PST) In-Reply-To: References: <49994068.7040507@gmail.com> Date: Mon, 16 Feb 2009 13:09:36 +0100 X-Google-Sender-Auth: 94c752bd1d3ace0c Message-ID: From: Emmanuel Baccelli To: ROLL WG Content-Type: multipart/alternative; boundary=0016369205b1756ce70463080ff4 Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 12:09:30 -0000 --0016369205b1756ce70463080ff4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have one comment in the mean-time, though: >> >> There is a wide scope of application areas for LLNs, including >> industrial monitoring, building automation (HVAC, lighting, access >> control, fire), connected home, healthcare, environmental monitoring, >> urban sensor networks sensor networks, assets tracking, refrigeration. >> The Working Group will only focus on routing solutions for a subset of >> these. It will focus on industrial, connected home, building and urban >> sensor networks and specify the set of routing requirements for >> these scenarios. > > > > At first sight there is a serious contradiction with the current charter > here: what was the purpose of the WG documents so far, including requirement > documents, if there needs to be another requirement document down the line? > This is unclear. > > > You are right, this has been corrected ("will only focus" should read "only > focuses") - Fixed. > > So the document should explain what is the difference between the current > WG documents and this future document, in order to avoid confusing people. > > JP, did you see my above comment? I'm not sure you answered the question about why we do need another requirement document? cheers Emmanuel --0016369205b1756ce70463080ff4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have one comment in the mean-time, though: 



There is a wide scope of application areas for LLNs, including
&= nbsp;industrial monitoring, building automation (HVAC, lighting, access
= control, fire), connected home, healthcare, environmental monitoring,
u= rban sensor networks sensor networks, assets tracking, refrigeration.
The Working Group will only focus on routing solutions for a subset of
t= hese. It will focus on industrial, connected home, building and urban
&= nbsp;sensor networks and specify the set of routing requirements for
&nb= sp;these scenarios.


At first sight there is a se= rious contradiction with the current charter here: what was the purpose of = the WG documents so far, including requirement documents, if there needs to= be another requirement document down the line? This is unclear.

You are right, this has been = corrected ("will only focus" should read "only focuses"= ) - Fixed.

So the document should explain what is the difference between the current W= G documents and this future document, in order to avoid confusing people.
X-Mailer: Apple Mail (2.753.1) Cc: ROLL WG Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 12:10:34 -0000 --Apple-Mail-8-928372607 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed +1 I am starting to loose track (although we seem to be on a constructive track ;) ) On Feb 16, 2009, at 12:05 PM, Dearlove, Christopher (UK) wrote: > There have been a number of agreed changes in response to emails > from various people. Could we have a revised draft with what the > current state is please. (I want to review, and it would seem sensible > not to possibly comment on something already changed.) > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-8-928372607 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 +1

I am starting to loose track (although we seem to = be on a constructive track ;) )


On Feb = 16, 2009, at 12:05 PM, Dearlove, Christopher (UK) wrote:

There have been a number of = agreed changes in response to emails
from various people. Could we have a = revised draft with what the
current state is please. (I want to review, = and it would seem sensible
not to possibly=A0comment on=A0something = already changed.)
=A0
=
********************************************************= ************
This email and any attachments are confidential to the = intended
recipient and may also be privileged. If you are not the = intended
recipient please delete it from your system and notify the = sender.
You should not copy it or use it for any purpose nor = disclose or
distribute its contents to any other person.
= ********************************************************************
=
Roll mailing list
=

= --Apple-Mail-8-928372607-- From jvasseur@cisco.com Mon Feb 16 04:24:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84E2E3A6960 for ; Mon, 16 Feb 2009 04:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.574 X-Spam-Level: X-Spam-Status: No, score=-10.574 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nhXPym58+tN for ; Mon, 16 Feb 2009 04:24:48 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D0C213A67A8 for ; Mon, 16 Feb 2009 04:24:19 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,216,1233532800"; d="scan'208,217";a="33888756" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 16 Feb 2009 12:24:28 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1GCOSOF012843; Mon, 16 Feb 2009 13:24:28 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1GCOSx5007990; Mon, 16 Feb 2009 12:24:28 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 13:24:27 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 13:24:26 +0100 Message-Id: From: JP Vasseur To: Emmanuel Baccelli In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-40-929312299 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 16 Feb 2009 13:24:26 +0100 References: <49994068.7040507@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 16 Feb 2009 12:24:26.0953 (UTC) FILETIME=[823BE390:01C99031] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6937; t=1234787068; x=1235651068; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20re-chartering |Sender:=20; bh=9gm9Lqaoos8jviWbjhP3SKnrIr/gsB9manl/LeOCADs=; b=hMOAgT5wkVn6RGE9xnuO2tcFggTaFehGWP8fvAgglbh6n9+mfzPOobRgmW RszGWYJ6ZUUxppipEGipqi+BwtuEPWJgfNOC28REKAfLkPvrDVO8DS7etgsj 3jWbsl5AZN; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 12:24:49 -0000 --Apple-Mail-40-929312299 Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Emmanuel, On Feb 16, 2009, at 1:09 PM, Emmanuel Baccelli wrote: > I have one comment in the mean-time, though: > >> >> >> There is a wide scope of application areas for LLNs, including >> industrial monitoring, building automation (HVAC, lighting, access >> control, fire), connected home, healthcare, environmental monitoring, >> urban sensor networks sensor networks, assets tracking, >> refrigeration. >> The Working Group will only focus on routing solutions for a subset >> of >> these. It will focus on industrial, connected home, building and >> urban >> sensor networks and specify the set of routing requirements for >> these scenarios. >> >> >> At first sight there is a serious contradiction with the current >> charter here: what was the purpose of the WG documents so far, >> including requirement documents, if there needs to be another >> requirement document down the line? This is unclear. > > You are right, this has been corrected ("will only focus" should > read "only focuses") - Fixed. > >> So the document should explain what is the difference between the >> current WG documents and this future document, in order to avoid >> confusing people. >> > > > JP, did you see my above comment? I'm not sure you answered the > question about why we do need another requirement document? There will not be any new requirement in fact. I think that the confusion is coming from the fact that the old text used to say "The Working group will ... " thus I have updated for "The Working Group focusses ....". Here is the new text. 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), assets 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. Does that clarify ? Thanks. JP. > > cheers > > Emmanuel > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-40-929312299 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi = Emmanuel,

On Feb 16, 2009, at 1:09 PM, Emmanuel = Baccelli wrote:

I have one comment in the mean-time, = though: 

=


There is a wide = scope of application areas for LLNs, including
 industrial = monitoring, building automation (HVAC, lighting, access
control, = fire), connected home, healthcare, environmental monitoring,
urban = sensor networks sensor networks, assets tracking, refrigeration.
The = Working Group will only focus on routing solutions for a subset = of
these. It will focus on industrial, connected home, building and = urban
 sensor networks and specify the set of routing = requirements for
 these scenarios.
=


At first sight there is a = serious contradiction with the current charter here: what was the = purpose of the WG documents so far, including requirement documents, if = there needs to be another requirement document down the line? This is = unclear.

You are = right, this has been corrected ("will only focus" should read "only = focuses") - Fixed.

So the = document should explain what is the difference between the current WG = documents and this future document, in order to avoid confusing = people.
=


JP, did you see my above = comment? I'm not sure you answered the question about why we do need = another requirement = document?

There will not be = any new requirement in fact. I think that the confusion is coming from = the fact that the old text used to say "The Working group will ... " = thus I have updated for "The Working Group focusses ....". Here is the = new text.

There is a wide = scope of application areas for LLNs, including=E2=80=A8 industrial monitoring, = building automation (HVAC, lighting, access =E2=80=A8control, fire), connected = homes, healthcare, environmental monitoring, =E2=80=A8urban sensor networks = (e.g. Smart Grid), assets tracking. =E2=80=A8The Working Group focuses on routing solutions = for a subset of =E2=80=A8these: industrial, connected home, building and urban=E2=80=A8= sensor networks for which routing requirements have been specified. = These application-specific routing requirement documents will be used for = protocol design.


Does that clarify = ?

Thanks.

JP.

<= blockquote type=3D"cite">
=

cheers

Emmanuel 
_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-40-929312299-- From jvasseur@cisco.com Mon Feb 16 04:25:02 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0E213A688B for ; Mon, 16 Feb 2009 04:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.575 X-Spam-Level: X-Spam-Status: No, score=-10.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vDV2zK6w1vS for ; Mon, 16 Feb 2009 04:25:01 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D4E263A67A8 for ; Mon, 16 Feb 2009 04:25:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,216,1233532800"; d="scan'208,217";a="33888842" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Feb 2009 12:25:09 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1GCP9CA027006; Mon, 16 Feb 2009 13:25:09 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1GCP9o9008233; Mon, 16 Feb 2009 12:25:09 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 13:25:09 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 13:25:08 +0100 Message-Id: From: JP Vasseur To: Thomas Heide Clausen In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-41-929354508 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 16 Feb 2009 13:25:08 +0100 References: <49994068.7040507@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 16 Feb 2009 12:25:08.0951 (UTC) FILETIME=[9B444670:01C99031] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4571; t=1234787109; x=1235651109; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20re-chartering |Sender:=20; bh=Z1uIcBTwO0Z3enuys3+M8p81PwslKjCw9PLJ4PmbOg0=; b=b8lnCiUiYLj5/lJn+PiZEDpbmGDFBf9NtPsmsOs5wB2Vr30erFWW8xh5LH jiuj+TCZkwBkOmw77vRpCV4otpTaYfyZjkdSNwme9kJ6XyzfQsMLHX9ZUJby 8EIxR8LHsV; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 12:25:03 -0000 --Apple-Mail-41-929354508 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit waiting for an ACK from Thomas on the last thread before sending out the new revision. On Feb 16, 2009, at 1:08 PM, Thomas Heide Clausen wrote: > +1 > > I am starting to loose track (although we seem to be on a > constructive track ;) ) > > > On Feb 16, 2009, at 12:05 PM, Dearlove, Christopher (UK) wrote: > >> There have been a number of agreed changes in response to emails >> from various people. Could we have a revised draft with what the >> current state is please. (I want to review, and it would seem >> sensible >> not to possibly comment on something already changed.) >> >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > --Apple-Mail-41-929354508 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable waiting for an ACK from Thomas = on the last thread before sending out the new = revision.

On Feb 16, 2009, at 1:08 PM, Thomas Heide = Clausen wrote:

+1

I = am starting to loose track (although we seem to be on a constructive = track ;) )


On Feb 16, 2009, at 12:05 = PM, Dearlove, Christopher (UK) wrote:

There have been a number of = agreed changes in response to emails
from various people. Could we have a = revised draft with what the
current state is please. (I want to review, = and it would seem sensible
not to possibly comment = on something already changed.)
 
=
********************************************************= ************
This email and any attachments are confidential to the = intended
recipient and may also be privileged. If you are not the = intended
recipient please delete it from your system and notify the = sender.
You should not copy it or use it for any purpose nor = disclose or
distribute its contents to any other person.
= ********************************************************************
=
Roll mailing list
=


= --Apple-Mail-41-929354508-- From emmanuel.baccelli@gmail.com Mon Feb 16 04:27:07 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 697663A6C71 for ; Mon, 16 Feb 2009 04:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.769 X-Spam-Level: X-Spam-Status: No, score=-1.769 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNp3xhS1zIaq for ; Mon, 16 Feb 2009 04:27:06 -0800 (PST) Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by core3.amsl.com (Postfix) with ESMTP id 672CB3A6C6D for ; Mon, 16 Feb 2009 04:27:05 -0800 (PST) Received: by fxm13 with SMTP id 13so5714169fxm.13 for ; Mon, 16 Feb 2009 04:27:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=wcDk6FDhaYzawjx+Kn41wmqKyMx/vRtUfXiC5d+XDL4=; b=E49NbcfnSc/wbWBqYIYe9+lhQar0yB84KmQt1e64ucfmp6VPkdplYB80oBxksOX05g NjVY2S9EoUbzcsaHMxzQrsh89m8X7fy6DQi8MiCBoD01+KmWVZK1oT2/SwnK8RyRPny0 i9eyN2FsFIwdKELnEq8w7mexglW6lmyJmrD+U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=t2Wl2hyL9auh72etUSKSJdkrg8iXBMS8ZO4c3095ag8p3OX7i7fToGvxSDe6ZZNZOq nITHh6wanSAeIS/uCcfMoe2kTyChyYr31gC8pCPbMOEyTjfifv/og1LWpjK5JRwTyDKo tSlKZMH0MAde0vqcewzjKPXYeQUgE1QSFWb3E= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.103.218.9 with SMTP id v9mr122225muq.78.1234787233535; Mon, 16 Feb 2009 04:27:13 -0800 (PST) In-Reply-To: References: <49994068.7040507@gmail.com> Date: Mon, 16 Feb 2009 13:27:13 +0100 X-Google-Sender-Auth: 74600213b25b600e Message-ID: From: Emmanuel Baccelli To: ROLL WG Content-Type: multipart/alternative; boundary=00163641695d6d97a10463084e83 Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 12:27:07 -0000 --00163641695d6d97a10463084e83 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, this point is clarified with the new text indeed.Emmanuel On Mon, Feb 16, 2009 at 1:24 PM, JP Vasseur wrote: > Hi Emmanuel, > On Feb 16, 2009, at 1:09 PM, Emmanuel Baccelli wrote: > > I have one comment in the mean-time, though: > > >>> >>> There is a wide scope of application areas for LLNs, including >>> industrial monitoring, building automation (HVAC, lighting, access >>> control, fire), connected home, healthcare, environmental monitoring, >>> urban sensor networks sensor networks, assets tracking, refrigeration. >>> The Working Group will only focus on routing solutions for a subset of >>> these. It will focus on industrial, connected home, building and urban >>> sensor networks and specify the set of routing requirements for >>> these scenarios. >> >> >> >> At first sight there is a serious contradiction with the current charter >> here: what was the purpose of the WG documents so far, including require= ment >> documents, if there needs to be another requirement document down the li= ne? >> This is unclear. >> >> >> You are right, this has been corrected ("will only focus" should read >> "only focuses") - Fixed. >> >> So the document should explain what is the difference between the curren= t >> WG documents and this future document, in order to avoid confusing peopl= e. >> >> > JP, did you see my above comment? I'm not sure you answered the question > about why we do need another requirement document? > > > There will not be any new requirement in fact. I think that the confusion > is coming from the fact that the old text used to say "The Working group > will ... " thus I have updated for "The Working Group focusses ....". Her= e > is the new text. > > There is a wide scope of application areas for LLNs, including=E2=80=A8 i= ndustrial > monitoring, building automation (HVAC, lighting, access =E2=80=A8control,= fire), > connected homes, healthcare, environmental monitoring, =E2=80=A8urban sen= sor > networks (e.g. Smart Grid), assets tracking. =E2=80=A8The Working Group f= ocuses on > routing solutions for a subset of =E2=80=A8these: industrial, connected h= ome, > building and urban=E2=80=A8 sensor networks for which routing requirement= s have been > specified. These application-specific routing requirement documents will = be > used for protocol design. > > Does that clarify ? > > Thanks. > > JP. > > > cheers > > Emmanuel > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > --00163641695d6d97a10463084e83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes,= this point is clarified with the new text indeed.
Emmanuel

On Mon, Feb 16, 2009 at 1:24 PM, JP Vasseur= <jvasseur@cisco= .com> wrote:
Hi Emma= nuel,

On Feb 16, 20= 09, at 1:09 PM, Emmanuel Baccelli wrote:

I have one comment in the mean-time, though:&= nbsp;



There is a wide scope of application areas for LLNs, including
=  industrial monitoring, building automation (HVAC, lighting, accesscontrol, fire), connected home, healthcare, environmental monitoring,
= urban sensor networks sensor networks, assets tracking, refrigeration.
The Working Group will only focus on routing solutions for a subset of
= these. It will focus on industrial, connected home, building and urban
=  sensor networks and specify the set of routing requirements for
&n= bsp;these scenarios.


At first sight there is a s= erious contradiction with the current charter here: what was the purpose of= the WG documents so far, including requirement documents, if there needs t= o be another requirement document down the line? This is unclear.

You are right, this has been= corrected ("will only focus" should read "only focuses"= ;) - Fixed.

So the document should explain what is the difference between the current = WG documents and this future document, in order to avoid confusing people.<= /div>


JP, did you see my above comment? = I'm not sure you answered the question about why we do need another req= uirement document?

There will not be any ne= w requirement in fact. I think that the confusion is coming from the fact t= hat the old text used to say "The Working group will ... " thus I= have updated for "The Working Group focusses ....". Here is the = new text.

There is a wide scope o= f application areas for LLNs, including=E2=80=A8 industrial monitoring, build= ing automation (HVAC, lighting, access =E2=80=A8control, fire), connected homes= , healthcare, environmental monitoring, =E2=80=A8urban sensor networks (e.g. = Smart Grid), assets tracking. =E2=80=A8The Working Group focuses on routing solutions fo= r a subset of =E2=80=A8these: industrial, connected home, building and urban=E2=80=A8 = sensor networks for which routing requirements have been specified. These application-specific routing requirement documents will be used for protoco= l design.


Does that clarify ?

Than= ks.

JP.


cheers

Em= manuel 
______________________________________________= _
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll


--00163641695d6d97a10463084e83-- From ietf@thomasclausen.org Mon Feb 16 04:27:44 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 410D93A6C6D for ; Mon, 16 Feb 2009 04:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqWCyKTZc4Id for ; Mon, 16 Feb 2009 04:27:43 -0800 (PST) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id 0562E3A6B30 for ; Mon, 16 Feb 2009 04:27:43 -0800 (PST) Received: from sphinx.lix.polytechnique.fr ([129.104.11.1] helo=[192.168.112.180]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LZ2Zk-000APF-2M; Mon, 16 Feb 2009 12:27:52 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 129.104.11.1 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+MpS0Z7pAJya4AGX2RLf6H In-Reply-To: References: <49994068.7040507@gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: multipart/alternative; boundary=Apple-Mail-10-929401171 Message-Id: From: Thomas Heide Clausen Date: Mon, 16 Feb 2009 13:25:55 +0100 To: JP Vasseur X-Mailer: Apple Mail (2.753.1) Cc: ROLL WG Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 12:27:44 -0000 --Apple-Mail-10-929401171 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Of charter? I thought that what you proposed sounded like a good step, but would like to see new revision with proposed changes. Thomas On Feb 16, 2009, at 1:25 PM, JP Vasseur wrote: > waiting for an ACK from Thomas on the last thread before sending > out the new revision. > > On Feb 16, 2009, at 1:08 PM, Thomas Heide Clausen wrote: > >> +1 >> >> I am starting to loose track (although we seem to be on a >> constructive track ;) ) >> >> >> On Feb 16, 2009, at 12:05 PM, Dearlove, Christopher (UK) wrote: >> >>> There have been a number of agreed changes in response to emails >>> from various people. Could we have a revised draft with what the >>> current state is please. (I want to review, and it would seem >>> sensible >>> not to possibly comment on something already changed.) >>> >>> ******************************************************************** >>> This email and any attachments are confidential to the intended >>> recipient and may also be privileged. If you are not the intended >>> recipient please delete it from your system and notify the sender. >>> You should not copy it or use it for any purpose nor disclose or >>> distribute its contents to any other person. >>> ******************************************************************** >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> > --Apple-Mail-10-929401171 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Of charter? I thought that what you proposed sounded like a good step, = but would like to see new revision with proposed = changes.

Thomas

On Feb 16, = 2009, at 1:25 PM, JP Vasseur wrote:

waiting = for an ACK from Thomas on the last thread before sending out the new = revision.

On Feb 16, 2009, at 1:08 PM, Thomas Heide = Clausen wrote:

+1

I = am starting to loose track (although we seem to be on a constructive = track ;) )


On Feb 16, 2009, at 12:05 = PM, Dearlove, Christopher (UK) wrote:

There have been a number of = agreed changes in response to emails
from various people. Could we have a = revised draft with what the
current state is please. (I want to review, = and it would seem sensible
not to possibly=A0comment on=A0something = already changed.)
=A0
=
********************************************************= ************
This email and any attachments are confidential to the = intended
recipient and may also be privileged. If you are not the = intended
recipient please delete it from your system and notify the = sender.
You should not copy it or use it for any purpose nor = disclose or
distribute its contents to any other person.
= ********************************************************************
=
Roll mailing list
=



= --Apple-Mail-10-929401171-- From jvasseur@cisco.com Mon Feb 16 04:30:11 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B4323A6B30 for ; Mon, 16 Feb 2009 04:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.575 X-Spam-Level: X-Spam-Status: No, score=-10.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CN-SOdD0buUB for ; Mon, 16 Feb 2009 04:30:08 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 229C83A695F for ; Mon, 16 Feb 2009 04:30:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,216,1233532800"; d="scan'208,217";a="33889508" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Feb 2009 12:30:16 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1GCUG2g028693; Mon, 16 Feb 2009 13:30:16 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1GCUGlx010045; Mon, 16 Feb 2009 12:30:16 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 13:30:16 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 13:30:15 +0100 Message-Id: From: JP Vasseur To: Emmanuel Baccelli In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-43-929661200 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 16 Feb 2009 13:30:15 +0100 References: <49994068.7040507@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 16 Feb 2009 12:30:15.0696 (UTC) FILETIME=[5219D900:01C99032] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8209; t=1234787416; x=1235651416; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20re-chartering |Sender:=20; bh=8ncYGbgn2W4c3fKwKTvxqtr7LDWcp6/6r8CPbSuouy0=; b=ij0nH0lbfQHjg8IqvOIYSuzFYRaDv2j6oSEm+hmkud86UaHuB6gBOtc/sd jRaR8YxS8AINzRHw7taFgXgQYM2RAL33niirX4dIlmjqfUDUyKjh5jWLuU3o BE4i3PWDBZ; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 12:30:11 -0000 --Apple-Mail-43-929661200 Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Thanks. On Feb 16, 2009, at 1:27 PM, Emmanuel Baccelli wrote: > Yes, this point is clarified with the new text indeed. > Emmanuel > > On Mon, Feb 16, 2009 at 1:24 PM, JP Vasseur > wrote: > Hi Emmanuel, > > On Feb 16, 2009, at 1:09 PM, Emmanuel Baccelli wrote: > >> I have one comment in the mean-time, though: >> >>> >>> >>> There is a wide scope of application areas for LLNs, including >>> industrial monitoring, building automation (HVAC, lighting, access >>> control, fire), connected home, healthcare, environmental >>> monitoring, >>> urban sensor networks sensor networks, assets tracking, >>> refrigeration. >>> The Working Group will only focus on routing solutions for a >>> subset of >>> these. It will focus on industrial, connected home, building and >>> urban >>> sensor networks and specify the set of routing requirements for >>> these scenarios. >>> >>> >>> At first sight there is a serious contradiction with the current >>> charter here: what was the purpose of the WG documents so far, >>> including requirement documents, if there needs to be another >>> requirement document down the line? This is unclear. >> >> You are right, this has been corrected ("will only focus" should >> read "only focuses") - Fixed. >> >>> So the document should explain what is the difference between the >>> current WG documents and this future document, in order to avoid >>> confusing people. >>> >> >> >> JP, did you see my above comment? I'm not sure you answered the >> question about why we do need another requirement document? > > There will not be any new requirement in fact. I think that the > confusion is coming from the fact that the old text used to say "The > Working group will ... " thus I have updated for "The Working Group > focusses ....". Here is the new text. > > 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), assets 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. > > Does that clarify ? > > Thanks. > > JP. > >> >> cheers >> >> Emmanuel >> _______________________________________________ >> 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 --Apple-Mail-43-929661200 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks.

On = Feb 16, 2009, at 1:27 PM, Emmanuel Baccelli wrote:

Yes, = this point is clarified with the new text = indeed.
Emmanuel

On Mon, = Feb 16, 2009 at 1:24 PM, JP Vasseur <jvasseur@cisco.com> = wrote:
Hi = Emmanuel,

On Feb = 16, 2009, at 1:09 PM, Emmanuel Baccelli wrote:

I have one comment in the mean-time, = though: 

=


There is a wide = scope of application areas for LLNs, including
 industrial = monitoring, building automation (HVAC, lighting, access
control, = fire), connected home, healthcare, environmental monitoring,
urban = sensor networks sensor networks, assets tracking, refrigeration.
The = Working Group will only focus on routing solutions for a subset = of
these. It will focus on industrial, connected home, building and = urban
 sensor networks and specify the set of routing = requirements for
 these scenarios.
=


At first sight there is a = serious contradiction with the current charter here: what was the = purpose of the WG documents so far, including requirement documents, if = there needs to be another requirement document down the line? This is = unclear.

You are = right, this has been corrected ("will only focus" should read "only = focuses") - Fixed.

So the document should explain = what is the difference between the current WG documents and this future = document, in order to avoid confusing people.
=


JP, did you see my above = comment? I'm not sure you answered the question about why we do need = another requirement document?
=

There will not be any = new requirement in fact. I think that the confusion is coming from the = fact that the old text used to say "The Working group will ... " thus I = have updated for "The Working Group focusses ....". Here is the new = text.

There is a wide scope of application areas = for LLNs, including=E2=80=A8 industrial monitoring, building automation = (HVAC, lighting, access =E2=80=A8control, fire), connected homes, = healthcare, environmental monitoring, =E2=80=A8urban sensor networks = (e.g. Smart Grid), assets tracking. =E2=80=A8The Working Group focuses = on routing solutions for a subset of =E2=80=A8these: industrial, = connected home, building and urban=E2=80=A8 sensor networks for which = routing requirements have been specified. These application-specific = routing requirement documents will be used for protocol = design.


Does that clarify = ?

Thanks.

JP.

<= blockquote type=3D"cite">
=

cheers

Emmanuel 
=
= _______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
=


= _______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-43-929661200-- From jvasseur@cisco.com Mon Feb 16 04:32:01 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16A2A3A6B21 for ; Mon, 16 Feb 2009 04:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.577 X-Spam-Level: X-Spam-Status: No, score=-10.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKBKOsk7W0wL for ; Mon, 16 Feb 2009 04:32:00 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 787903A695F for ; Mon, 16 Feb 2009 04:31:59 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,216,1233532800"; d="scan'208";a="33889768" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 16 Feb 2009 12:32:08 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1GCW8eK015375 for ; Mon, 16 Feb 2009 13:32:08 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1GCW8dS010752 for ; Mon, 16 Feb 2009 12:32:08 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 13:32:08 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 13:32:07 +0100 Message-Id: <21EE679D-9A5D-4655-82B1-9A5E77ECB82A@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 16 Feb 2009 13:32:07 +0100 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 16 Feb 2009 12:32:07.0797 (UTC) FILETIME=[94EB1A50:01C99032] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5694; t=1234787528; x=1235651528; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20New=20Text=20for=20the=20Charter |Sender:=20; bh=DTxAR2SW1OxDutRTT0B9ENIxq1xzrAryNg2T8CRT1rs=; b=VYtNA1PZksTEVKGGjsuX8lxAueN6eiSjCs7vGkbB0gh6Uyv2ncPDt94X2s qruuLUpPP3mH5fugptpEFNThjj5z+iytcevklkXmFh3Sn+dGzD1qdE1Tr6BA 9k/XW06FVd; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [Roll] New Text for the Charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 12:32:01 -0000 With all agreed changes ... Description of Working Group: 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 energy saving, - Typical traffic patterns are not simply unicast flows (e.g. in some environments 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. As shown in a protocol survey existing routing protocols (in their current form) such as OSPF, IS-IS, AODV, and OLSR, do not meet 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), assets 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. 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 protocols 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: In light of the application specific routing requirements, the Working Group will either specify a new protocol and/ or will select an existing routing protocol (with the appropriate extensions in cooperation with the relevant Working Group). - Documentation of applicability statement of ROLL routing protocols. Goals and Milestones: Done Submit Routing requirements for Industrial applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Connected Home networks applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Building applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Urban networks applications to the IESG to be considered as an Informational RFC. July 2009 Submit Routing metrics for LLNs document to the IESG to be considered as a Proposed Standard. * Feb 2009 Submit Protocol Survey to the IESG to be considered as an Informational RFC. April 2009 Submit Security Framework to the IESG to be considered as an Informational RFC May 2009 Submit the Routing for LLNs Architecture document to the IESG as an Informational RFC. July 2009 Submit first draft of ROLL routing protocol specification as Proposed Standard. Nov 2009 Submit first draft of the MIB module of the ROLL routing protocol specification. Feb 2010 Submit the ROLL routing protocol specification to the IESG as Proposed Standard. March 2010 Submit the MIB module of the ROLL routing protocol specification to the IESG as Proposed Standard. April 2010 Evaluate WG progress, recharter or close. PS: I marked * the Milestones that will be "This Week" and before submitting to the IESG for re-chartering. From alexandru.petrescu@gmail.com Mon Feb 16 05:31:39 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 482ED3A6A47; Mon, 16 Feb 2009 05:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-AdaFRnTH5c; Mon, 16 Feb 2009 05:31:38 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 466853A69B4; Mon, 16 Feb 2009 05:31:38 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1GDTbf7021075; Mon, 16 Feb 2009 14:29:38 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1GDVJOY030578; Mon, 16 Feb 2009 14:31:19 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n1GDVJIQ020091; Mon, 16 Feb 2009 14:31:19 +0100 Message-ID: <49996AA7.5080909@gmail.com> Date: Mon, 16 Feb 2009 14:31:19 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Daniel Smolinski References: <49958529.5010306@gmail.com><89BA3B32-421E-4A24-B075-B5518E78FD35@cisco.com><49958D92.5040503@gmail.com><8157AC22-684F-4FA9-8240-AA481A404F22@cisco.com><49993A18.1040500@gmail.com><3833CB70-C16B-4C4F-B569-E8438BE1BD26@cisco.com> <49993E3B.70509@gmail.com> <7BDC023EB136F0499F260228BE2991BC2E9994@rte-rat-exch.RTE.ADWIN.RENESAS.COM> In-Reply-To: <7BDC023EB136F0499F260228BE2991BC2E9994@rte-rat-exch.RTE.ADWIN.RENESAS.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG , roll-bounces@ietf.org, "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 13:31:39 -0000 Hi Daniel, Daniel Smolinski a écrit : > Hi Alex, > > to me, lossy means that link communication can fail because of > natural influences to the transmission media. It makes no difference > if a wireless link fails because some item temporarily blocks the > path (or all paths) or if a powerline link fails if the line > impedance or noise spectrum changes for some time. > >> Lossiness of PLC links could be avoided by setting them up >> properly, don't plug the microwave oven if the manufacturer says >> so. > > I don't think that this is a valid solution to disturbances in the > powerline. The PLC technology itself must be able to handle these > issues, either by the robustness of the PHY layer, link layer > mechanisms or a combination of both. But, so should any technology, > and if it fails due to influences from the outside, it is lossy and > this needs to be considered in the routing. I think the way we describe this lossiness characteristic begs for solutions at PHY and MAC layers; dealing with it in a routing protocol sounds to me as an overly stretched extension. Adaptation to bandwidth variance happens at TCP level during an ongoing exchange. Alex From alexandru.petrescu@gmail.com Mon Feb 16 05:36:08 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA78F3A6A47 for ; Mon, 16 Feb 2009 05:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBPomDzivdEb for ; Mon, 16 Feb 2009 05:36:08 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id C3AD73A6B4A for ; Mon, 16 Feb 2009 05:36:07 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1GDa8Zu007435; Mon, 16 Feb 2009 14:36:08 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1GDa8AY005045; Mon, 16 Feb 2009 14:36:08 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n1GDa74E016034; Mon, 16 Feb 2009 14:36:07 +0100 Message-ID: <49996BC7.70409@gmail.com> Date: Mon, 16 Feb 2009 14:36:07 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: JP Vasseur References: <21EE679D-9A5D-4655-82B1-9A5E77ECB82A@cisco.com> In-Reply-To: <21EE679D-9A5D-4655-82B1-9A5E77ECB82A@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] low power PLC (Was: New Text for the Charter) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 13:36:08 -0000 JP Vasseur a écrit : > With all agreed changes ... > > > Description of Working Group: 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. I disagree saying "low power PLC links". Alex From Daniel.Smolinski@renesas.com Mon Feb 16 05:39:16 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64A403A6C8A for ; Mon, 16 Feb 2009 05:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Jfuetgjd4eK for ; Mon, 16 Feb 2009 05:39:15 -0800 (PST) Received: from mail04.idc.renesas.com (mail.renesas.com [202.234.163.13]) by core3.amsl.com (Postfix) with ESMTP id 72A0B3A6B1D for ; Mon, 16 Feb 2009 05:39:14 -0800 (PST) X-AuditID: ac140387-00000007000005fd-99-49996c7d4a30 Received: from guardian02.idc.renesas.com ([172.20.8.201]) by mail04.idc.renesas.com (sendmail) with ESMTP id n1GDd9ap019640 for ; Mon, 16 Feb 2009 22:39:09 +0900 (JST) Received: (from root@localhost) by guardian02.idc.renesas.com with id n1GDd9bi028564 for roll@ietf.org; Mon, 16 Feb 2009 22:39:09 +0900 (JST) Received: from mta01.idc.renesas.com (localhost [127.0.0.1]) by mta01.idc.renesas.com with ESMTP id n1GDd9En012333 for ; Mon, 16 Feb 2009 22:39:09 +0900 (JST) Received: from mail pickup service by rte-idc-bh1.RTE.ADWIN.RENESAS.COM with Microsoft SMTPSVC; Mon, 16 Feb 2009 13:39:06 +0000 Importance: normal Priority: normal Received: from rte-rat-exch.RTE.ADWIN.RENESAS.COM ([172.28.128.38]) by rte-idc-bh1.RTE.ADWIN.RENESAS.COM with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 Feb 2009 13:39:05 +0000 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.504 Date: Mon, 16 Feb 2009 14:39:04 +0100 Message-ID: <7BDC023EB136F0499F260228BE2991BC2E9A9D@rte-rat-exch.RTE.ADWIN.RENESAS.COM> In-Reply-To: <49996BC7.70409@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] low power PLC (Was: New Text for the Charter) thread-index: AcmQO5JuSeVsBngERCuOtX2bkusXEAAACb7g References: <21EE679D-9A5D-4655-82B1-9A5E77ECB82A@cisco.com> <49996BC7.70409@gmail.com> From: "Daniel Smolinski" To: "Alexandru Petrescu" , "JP Vasseur" X-OriginalArrivalTime: 16 Feb 2009 13:39:05.0915 (UTC) FILETIME=[EFE740B0:01C9903B] X-Brightmail-Tracker: AAAAAA== Cc: ROLL WG Subject: Re: [Roll] low power PLC (Was: New Text for the Charter) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 13:39:16 -0000 While we cannot agree on the low-power part of PLC, maybe we can agree = to: .. such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other = lossy links, e.g. PLC. Regards, Daniel -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: Montag, 16. Februar 2009 14:36 To: JP Vasseur Cc: ROLL WG Subject: Re: [Roll] low power PLC (Was: New Text for the Charter) JP Vasseur a =E9crit : > With all agreed changes ... >=20 >=20 > Description of Working Group: 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. I disagree saying "low power PLC links". Alex _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll Renesas Technology Europe GmbH Sitz: Ratingen, Amtsgericht Duesseldorf, HRB 44903 Geschaeftsfuehrer: Peter Mies, Tsutomu Miki, Matthew Trowbridge, Holger = Zielke From alexandru.petrescu@gmail.com Mon Feb 16 05:43:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E85643A6836 for ; Mon, 16 Feb 2009 05:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARXH8sGak6qf for ; Mon, 16 Feb 2009 05:43:49 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id DF9013A6A0C for ; Mon, 16 Feb 2009 05:43:48 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1GDhuJD022503; Mon, 16 Feb 2009 14:43:56 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1GDht1j015408; Mon, 16 Feb 2009 14:43:56 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n1GDhtFW025018; Mon, 16 Feb 2009 14:43:55 +0100 Message-ID: <49996D9B.2080804@gmail.com> Date: Mon, 16 Feb 2009 14:43:55 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Daniel Smolinski References: <21EE679D-9A5D-4655-82B1-9A5E77ECB82A@cisco.com> <49996BC7.70409@gmail.com> <7BDC023EB136F0499F260228BE2991BC2E9A9D@rte-rat-exch.RTE.ADWIN.RENESAS.COM> In-Reply-To: <7BDC023EB136F0499F260228BE2991BC2E9A9D@rte-rat-exch.RTE.ADWIN.RENESAS.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] low power PLC (Was: New Text for the Charter) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 13:43:50 -0000 Daniel Smolinski a écrit : > While we cannot agree on the low-power part of PLC, maybe we can agree to: > > .. such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other lossy > links, e.g. PLC. In principle yes, but it mixes link-layer specific technologies (15.4, wifi) with generic calls such as 'wired', lossy PLC. And I'm not sure why Low Power WiFi deserves capitalization either. Is it low-power WiFi instead? Does this low-power WiFi technology have a specific name at IEEE? Alex From alexandru.petrescu@gmail.com Mon Feb 16 05:46:07 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 276183A6A0C for ; Mon, 16 Feb 2009 05:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6G9noWNoFku for ; Mon, 16 Feb 2009 05:46:06 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 00A933A6836 for ; Mon, 16 Feb 2009 05:46:05 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1GDkC2k025994; Mon, 16 Feb 2009 14:46:12 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1GDeC74010024; Mon, 16 Feb 2009 14:40:28 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n1GDe2EI023631; Mon, 16 Feb 2009 14:40:02 +0100 Message-ID: <49996CB2.7010705@gmail.com> Date: Mon, 16 Feb 2009 14:40:02 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: JP Vasseur References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> <7F8096B9-1691-44D2-9032-6383C6C765B3@thomasclausen.org> <499938BF.8030409@gmail.com> <906CC3B7-E1D2-428A-BF1F-BDBB676DA088@cisco.com> <499942A3.5020005@gmail.com> <3C213BBC-117D-4C59-BDAF-198382C7A8CE@cisco.com> In-Reply-To: <3C213BBC-117D-4C59-BDAF-198382C7A8CE@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] Internet connectivity (was: ROLL re-chartering) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 13:46:07 -0000 JP Vasseur a écrit : > > On Feb 16, 2009, at 11:40 AM, Alexandru Petrescu wrote: > >> JP Vasseur a écrit : >>> On Feb 16, 2009, at 10:58 AM, Alexandru Petrescu wrote: >>>> Thomas Heide Clausen a écrit : [...] >>>>> I can see where Alexandru's question come from at this point, >>>>> when we were talking about power-lines and such. Essentially, >>>>> what we're wanting to say [I think] is that "ROLL protocols >>>>> MUST be able to run on routers with >>>>> [very-strict-set-of-restrictions]" -- and that there then may >>>>> be a few routers with "better than >>>>> [very-strict-set-of-restrictions]" shouldn't be driving our >>>>> design, and that such routers are present is purely >>>>> incidental. IOW, I'd suggest rephrasing this slightly, to say >>>>> "these are the requirements that ROLL protocols shall satisfy >>>>> -- if a device does better than that, more power to it, but >>>>> it's not our primary design target". >>>> >>>> This rephrasing sounds better to me. >>> What is exactly the proposed rephrasing ? >> >> If one agrees with a distinction in energy between PLC device and >> batter-powered devices. >> >> Then a clarifying suggestion could be the following. >> >> Instead of: >>> Low power and Lossy networks (LLNs) are typically composed of >>> many embedded devices with limited power, memory, and processing >>> resources interconnected by a variety of links, such as IEEE >>> 802.15.4, Bluetooth, Low Power WiFi 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. LLNs have specific characteristics: - >>> LLNs operate with a hard, very small bound on state, - In >>> most cases, LLN need to be optimized for energy saving, - >>> Typical traffic patterns are not simply unicast flows, - In >>> most cases, LLNs need to be effective with very small packet >>> sizes, - LLN routing protocols have to be very careful when >>> trading off efficiency for generality; many LLN nodes do not have >>> resources to waste. >> >> Suggested text: " Low power and Lossy networks (LLNs) are typically >> composed of many embedded devices with limited power, memory, and >> processing resources interconnected by a variety of links, such as >> IEEE 802.15.4, Bluetooth, Low Power WiFi or other low power links >> [remove: 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. LLNs have specific >> characteristics: - ... - They are securely connected to >> the Internet. >> >> - LLN devices and links are linked together with other >> devices and links, which are not energy-constrained and whose >> bandwidth/latency/range/emissionpower could be orders of magnitude >> better, e.g. PLC devices. " >> >> Would you agree with this PLC distinction and the explicit >> statement of Internet connectivity? >> > > Sorry but not sure what you mean ... 1) On Internet connectivity, > some LLNs may not be connected to the Internet at all (not typical I > agree). At the very least limit, I would agree with saying "LLNs are intermitently connected to the Internet". To deserve IETF consensus search, LLNs would be connected to the Internet at least from time to time. Do you think ROLL protocol/extensions would only work in a network which is forbidden to connect to the Internet? Alex From jvasseur@cisco.com Mon Feb 16 06:16:38 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49E433A6B17 for ; Mon, 16 Feb 2009 06:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.577 X-Spam-Level: X-Spam-Status: No, score=-10.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-cYL2Eh6FxJ for ; Mon, 16 Feb 2009 06:16:37 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D6BEB3A6C53 for ; Mon, 16 Feb 2009 06:16:33 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,216,1233532800"; d="scan'208";a="33906490" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 16 Feb 2009 14:16:42 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1GEGgrw021958; Mon, 16 Feb 2009 15:16:42 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1GEGgXu023281; Mon, 16 Feb 2009 14:16:42 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 15:16:42 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 15:16:41 +0100 Message-Id: <9E34ECDE-B44D-462B-B183-AAEFD1DAEC5A@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <49996CB2.7010705@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 16 Feb 2009 15:16:41 +0100 References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> <7F8096B9-1691-44D2-9032-6383C6C765B3@thomasclausen.org> <499938BF.8030409@gmail.com> <906CC3B7-E1D2-428A-BF1F-BDBB676DA088@cisco.com> <499942A3.5020005@gmail.com> <3C213BBC-117D-4C59-BDAF-198382C7A8CE@cisco.com> <49996CB2.7010705@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 16 Feb 2009 14:16:42.0006 (UTC) FILETIME=[30A36B60:01C99041] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4220; t=1234793802; x=1235657802; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20Internet=20connectivity=20(was=3A=20[Ro ll]=20ROLL=20re-chartering) |Sender:=20; bh=7wotDZ7+xFurfXzCB1bq+fxzGZwQQLqYwwe3EPzWGX4=; b=H35eAomwiyNN5bZa2y9TxLYYQ71zu0QwMec6KxIRHxtR9gkVvVVfbdNvdC PgIcg2AcXMlRT/GW7SxXRhVYa6JKsql2z09IrpJBeiG9+q9Ov1fAOuN13luT /RKIg2uZE4; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] Internet connectivity (was: ROLL re-chartering) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 14:16:38 -0000 Hi Alex, As a follow up to our phone call to clarify a few things. In line, On Feb 16, 2009, at 2:40 PM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> On Feb 16, 2009, at 11:40 AM, Alexandru Petrescu wrote: >>> JP Vasseur a =E9crit : >>>> On Feb 16, 2009, at 10:58 AM, Alexandru Petrescu wrote: >>>>> Thomas Heide Clausen a =E9crit : [...] >>>>>> I can see where Alexandru's question come from at this point, >>>>>> when we were talking about power-lines and such. Essentially, >>>>>> what we're wanting to say [I think] is that "ROLL protocols >>>>>> MUST be able to run on routers with [very-strict-set-of-=20 >>>>>> restrictions]" -- and that there then may >>>>>> be a few routers with "better than >>>>>> [very-strict-set-of-restrictions]" shouldn't be driving our >>>>>> design, and that such routers are present is purely >>>>>> incidental. IOW, I'd suggest rephrasing this slightly, to say >>>>>> "these are the requirements that ROLL protocols shall satisfy >>>>>> -- if a device does better than that, more power to it, but >>>>>> it's not our primary design target". >>>>> This rephrasing sounds better to me. >>>> What is exactly the proposed rephrasing ? >>> If one agrees with a distinction in energy between PLC device and =20= >>> batter-powered devices. >>> Then a clarifying suggestion could be the following. >>> Instead of: >>>> Low power and Lossy networks (LLNs) are typically composed of >>>> many embedded devices with limited power, memory, and processing >>>> resources interconnected by a variety of links, such as IEEE >>>> 802.15.4, Bluetooth, Low Power WiFi 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. LLNs have specific characteristics: - >>>> LLNs operate with a hard, very small bound on state, - In >>>> most cases, LLN need to be optimized for energy saving, - >>>> Typical traffic patterns are not simply unicast flows, - In >>>> most cases, LLNs need to be effective with very small packet >>>> sizes, - LLN routing protocols have to be very careful when >>>> trading off efficiency for generality; many LLN nodes do not have >>>> resources to waste. >>> Suggested text: " Low power and Lossy networks (LLNs) are typically >>> composed of many embedded devices with limited power, memory, and >>> processing resources interconnected by a variety of links, such as >>> IEEE 802.15.4, Bluetooth, Low Power WiFi or other low power links >>> [remove: 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. LLNs have specific >>> characteristics: - ... - They are securely connected to >>> the Internet. >>> - LLN devices and links are linked together with other =20 >>> devices and links, which are not energy-constrained and whose =20 >>> bandwidth/latency/range/emissionpower could be orders of magnitude >>> better, e.g. PLC devices. " >>> Would you agree with this PLC distinction and the explicit >>> statement of Internet connectivity? >> Sorry but not sure what you mean ... 1) On Internet connectivity, >> some LLNs may not be connected to the Internet at all (not typical I >> agree). > > At the very least limit, I would agree with saying "LLNs are =20 > intermitently connected to the Internet". > > To deserve IETF consensus search, LLNs would be connected to the =20 > Internet at least from time to time. > > Do you think ROLL protocol/extensions would only work in a network =20 > which is forbidden to connect to the Internet? Some LLNs may not be connected to the Internet, while this is =20 certainly not the majority of the cases. Thus let's stick with the proposed text. As for the PLC, we keep the current text considering that low power =20 PLC technologies are used in LLNs and are both lossy and low power. Thanks for commenting. JP. > > > Alex > > From alexandru.petrescu@gmail.com Mon Feb 16 06:51:23 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BB0A28B23E; Mon, 16 Feb 2009 06:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFZvrq5iy8Ma; Mon, 16 Feb 2009 06:51:21 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 0A61D3A6A9F; Mon, 16 Feb 2009 06:51:20 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1GEnj4H014307; Mon, 16 Feb 2009 15:49:45 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1GEpR6O005360; Mon, 16 Feb 2009 15:51:27 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n1GEpQN5011882; Mon, 16 Feb 2009 15:51:27 +0100 Message-ID: <49997D6E.2030409@gmail.com> Date: Mon, 16 Feb 2009 15:51:26 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Eunsook \"Eunah\" Kim" References: <4992FD7F.8070408@gmail.com> <77f1dba80902160228s4b25285ageb085c51c402fd40@mail.gmail.com> In-Reply-To: <77f1dba80902160228s4b25285ageb085c51c402fd40@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org, ROLL WG Subject: Re: [Roll] Comments on draft-ietf-6lowpan-routing-requirements-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 14:51:23 -0000 [I cut ROLL from the distribution list, because it seems I post too much on the ROLL list] Thanks for the message. I mainly agree with you. I commented on some of the text, below. Eunsook "Eunah" Kim a écrit : [...] >> Some high-level questions: >> -is there a requirement to connect a 6LoWPAN network to the Internet? > > Do you mean in terms of routing? Or a general view of 6LoWPAN? > The birth of 6LoWPAN is to make the Low-power low rate network (based > on IEEE 802.15.4) look like an IPv6 link. > > If you only meant routing, the reachability can be achieved by mesh > routing (or mesh switching in your comment below) or route-over. > > I don't know if it answers your question. If a network running 6LoWPAN routing system (designed according to 6lowpan-routing-requirements) is connected to the Internet - will anything break? >> -is the 6LoWPAN using addressing architecture and longest-prefix match >> based routing as in the Internet? > > Alex, I think RFC 4944 may help your curiosity of 6lowpan fundamental. > > Although the header compression format is updating in 6lowpan now, you > can find a basic needs of 6lowpan in the RFC. > If I shortly explain, an IPv6 Interface Identifier is obtained from > the 64-bit or 16-bit IEEE 802.15.4 address. The IPv6 link-local > address for an IEEE 802.15.4 interface is formed by appending the > Interface Identifier to a certain prefix (see Section 6 and Section 7 > of RFC 4944). With regard to routing, I understand the answer is 'yes' > in the case of route-over. > Please kindly let me know if you already checked the RFC and your > intention from the question was different from my answer. :) Yes, thanks for posting rfc4944, I checked it. Will the 6LoWPAN router use longest-prefix match (as IP protocols do) or exact-match (as some VLAN switch protocols do). Will the 6LoWPAN addressing architecture be local to the network, or integrated in the Internet. How is a link-local scoped solicited node multicast address mapped into an 802.15.4 address? rfc4944 says rightmost 2 bytes go into a 802.15.4 16-bit multicast address. But rfc4291 says a solicited node multicast address has the rightmost 3 octets as significant (FF02:0:0:0:0:1:FFXX:XXXX). Will NS/NA and DAD work ok on these links? >> -how many interfaces will a 15.4 device have potentially? >> > > Well, currently, as I follow up, one interface only for a sensor node > in 6LoWPAN. A gateway usually have more than one interface (e.g., 15.4 > + 802.11 or others). Well a sensor node which is supposed to do routing with only one interface will be different than a PC doing routing with two interfaces (the typical case). >> Following are detail questions and comments. I believe they're not as >> important as the items mentioned above. >> >>> 1. Problem Statement >> Is this _the_ problem statement or should I better go read >> draft-ietf-6lowpan-problem-08? They differ largely... > > First of all, just for your information, draft-ietf-6lowpan-problem-08 > is now RFC 4919. Ok, thanks. > The section 1, problem statement of our draft is focusing on routing > in 6LoWPANs, and RFC 4919 states general problem of 6LoWPAN, including > a brief requirement as you refered in the below. > >>> The 6LoWPAN problem statement document ("6LoWPAN Problems and Goals" [3]) >>> briefly mentions four requirements on routing protocols; >>> >>> (a) low overhead on data packets >>> >>> (b) low routing overhead >> >> What is routing more generally? Is it the act a router performs when >> presenting with a packet, searching in a routing table, maybe exploring >> its ND structures, maybe sending ND messages and then emitting the packet? >> >> Or is it exchanging IP datagrams containing prefixes and metrics and >> reachability information, such that nodes have a common view of the >> network paths? > > I would say that it include all the functionalities needed for the > selection of a path from source to destination. > However, I should be careful use the term 'router' here. > Although 6lowpan nodes may perform such routing functionality for the > reachability, it's different from traditional term of 'router'. > In route-over, they call 6lowpan nodes performing routing as 'routers' > - One radio hop is a single IP link. > However, in mesh-under, only one 6lowpan router exists in one 6lowpan > (ER in Figure 2 of the draft) - Whole 6lowpan is One IPv6 link. > To cover the both case, please understand in this way; 6LoWPAN node > may perform such a 'routing-related functionalities'. > >> I think this is worth discussing, in order to better target what the >> work should follow this problem statement and reqs. >> >> Are the low overhead requirements put on the database construction >> messages? Or on the individual act of forwarding a packet? > > I would say 'on both'. Ok. >>> On the other hand, the route-over approach relies on IP routing and >>> therefore supports routing over possibly various types of interconnected >>> links (see also Figure 1). >> At several places in the draft, when link 'types', device 'types' are >> mentioned, I'm tempted to believe 6LoWPAN considers links other than >> 802.15.4 links? Is it so? Should 6LoWPAN routing protocol work also >> with aseptic point-to-point links? >> Or are the 'types' limited within the relatively large scope of 802.3 >> compatible MACs (I believe 802.15.4 and 802.16 to fit within). >> >> This is of paramount importance in setting the scope. >> > > Oh, link 'type'. ;) Currently 6lowpan is clearly based on 802.15.4, > although some talks that 6LoWPAN can run on top of other radios with > similar characteristics. And, for route-over (as ROLL WG is working > on), the benefit which have been insisted is that the routing > mechanism is link-independent. Mesh-under of 6lowpan is 802.15.4 > dependent. > But I don't know what is 'aseptic' point to point links. Sorry, I meant 'aseptic' to say point-to-point links over which ND is not run actually, no need for ND nor DAD. They have specific ways in which the IPv6 link-local address is formed. They're often independent on the link layer technology. PPP over IPv6 (RFC) is an example. >>> The most significant consequence of mesh-under routing is that routing >>> would be directly based on the IEEE 802.15.4 standard, >> >> Which 'routing' is directly based on 802.15.4 standard? The 'IP >> routing' is based on that standard? This brings back to defining what >> routing is. >> > > Ah~ I think we should change the wording. I meant that the > requirements of 6lowpan routing inherit the stringent characterisitcs > of 802.15.4. I will change the text to make it clear. Thanks. :) Sure. >> Maybe better call 'mesh-under routing' 'mesh-under switching'. >> >> IP routing and addressing may be fundamentally different than mesh-under >> addressing and switching - in the way hosts get and maintain their >> addresses and in the way routers/switches search their databases (exact >> match vs longest-prefix). >> > > Agreed. Either term is okay by me. Just due to the specific > characteristics of 6lowpan configuration, > multi-hop path selection can be achieved in mesh-under. I will ask > others if mesh-under switching is better to be clarified. Ok. >>> When a route-over protocol is built in the IPv6 layer, the Dispatch value >>> can be chosen as one of the Dispatch patterns for 6LoWPAN, compressed or >>> uncompressed IPv6, followed by the IPv6 header. >> >> Sorry, I can't parse this. >> >> A route-over protocol would act both at IP layer and >> application/transport layers. Depends what a routing protocol is. For >> example ICMP Redirect, or NEMOv6 or ND act at IP layer, whereas RIPng is >> over UDP. >> >> 'followed by'... when reading left to right or reverse? >> > > When I read the text again, it can be confusing. I will try to rephrase it. > 6LoPWAN provides compressed or uncompressed IPv6 header. > It just wants to explain the relationship between 6lowpan header and > routing header. > You will get the information from RFC 4944. Ok. >>> For route-over, a default route to the ER could be inserted into the >>> routing system. >> In the routing system of the 6LoWPAN network? Or in the routing system >> of the fixed Internet network? > > 6lowpan. I will also try to rephrase it to be clear. thanks. :) Sure, it answers my question. >>> IP-based low-power WPAN technology is still in its early stage of >> 'WPAN'? >> > wireless personal area network. > 6lowpan = IPv6 over Low power WPAN. But, actually i think it's better > to just use 6LoWPAN, to keep the consistancy of the document. > I will change it. Ok, I meant to say WPAN surprisingly appears there first, without explanation. >>> a. Network Properties: >>> >>> * Number of Devices, Density and Network Diameter: These parameters >>> usually affect the routing state directly (e.g. the number of >>> entries in a routing table or neighbor list). Especially in large >>> and dense networks, policies must >> What is 'large' and 'dense'? Is it about physical dimensions? Or IP >> dimensions? > > It is about physical dimensions. I think Diameter has a physical sense only if it's a circle. I don't think networks have a physical shape of a circle. I may be wrong though. >> Density sounds as a physical characteristic (many devices in a small >> area) whereas Diameter sounds as a pure IP term (max number of IP hops). >> >> The number of entries in the routing table mostly depends on the planned >> addressing architecture. One can have a very high-diameter network with >> a very hierarchical addressing structures, many default routes, and very >> few entries in the routing tables (maybe only 1 per hop). >> > > I fully agree with you. I will discuss woth co-authors and modify the > text, since in the case of appropriate hierarchical addressing > structures, what the text of the draft says may not be true. Sure, thanks. >> Is the addressing architecture for 6LoWPAN networks planned? >> >> Is the addressing architecture following the Internet model? >> > > can be both, i think. It's dependent on 6lowpan scenario. > >>> b. Node Parameters: >> How many interfaces does a 6LoWPAN node typically have? This is of >> paramount importance deciding whether any type of repeating/bridging >> needs to happen. > > In my view, currently one interface for 15.4, for normal 6lowpan nodes. This is a distinguishing characteristic, routing with only one interface. >>> * Throughput: The maximum user data throughput of a bulk data >>> transmission between a single sender and a single receiver through an >>> unslotted IEEE 802.15.4 2.4 GHz channel in ideal conditions is as follows >>> [19]: [...] >>> >>> In the case of 915 MHz band: >> Sorry, for my clarification: is 915MHz the width of band centered on >> the 2.4GHz mentioned above? Or is it the central frequency (thus >> replacing the "2.4GHz" mentioned above)? > > it is the central frequency. Ok. >>> [R02] 6LoWPAN routing protocols SHOULD cause minimal power consumption by >>> the efficient use of control packets (e.g., minimize expensive multicast >>> which cause broadcast to the entire LoWPAN) and by the efficient routing of >>> data packets. >> YEs, but multicast may be more efficient than broadcast - is it >> sufficient? I think it is sufficient to rely on multicast and avoid >> unnecessary duplication such as in broadcast. >> > > multicast may be more efficient. However, 802.15.4 does not support multicast. > for 6lowpan's view, IP multicast is expensive in terms of energy usage > for 6lowpan nodes. Ok. >> 'Efficient routing of data packets' - is it also efficient search in the >> routing table? That may be part of 'routing' too. >> > > Good point. :) > >>> possibliy >> Nit: iy > > thanks. ;) > >>> [R03] 6LoWPAN routing protocol control messages SHOULD not create >>> fragmentation of physical layer (PHY) frames. >> Err... I think PHY frames aren't fragmented... not sure I understand >> this requirement? >> >> Sounds as if one wants an UDP control packets to not be sent in several >> pieces, because of overhead involved fragmenting/reassembling. >> >> Then make sure first IP doesn't fragment. >> > > It means 6lowpan packet should not occur fragmentation. text will be > modified to make it clear. thanks. > >>> Therefore, 6LoWPAN routing should not cause packets to exceed the IEEE >>> 802.15.4 frame size [81bytes]. >> Is this a requirement on the mesh-under link-layer switching protocol? >> Or on the 'route-above' protocol? If the latter - I think this >> requirement is a violation of layer independence :-) >> >> It sounds very special to me to limit the size of the messages of an IP >> routing protocol. >> >> Knowing that IP can fragment too. > > Yes, I know your argument. :) But it's 6lowpan specific requirement, > and as I know many 6lowpaners are agreed on this one. I got a comment > from one roll routing requirement author that this requirement can be > considered in roll as well. I may make a chance to see you to explain > some detail of 6lowpan before the meeting, if you are interested in? > ;) > >>> [R05] The design of routing protocols for 6LoWPANs must consider the >>> end-to-end latency requirements of applications and IEEE 802.15.4 link >>> latency characteristics. >> 'Routing'? Or 'Transport'? end-to-end is what Transport typically >> takes care of, not routing. >> >> If Routing: which routing? The forwarding ahppening at a node? Or the >> convergence time? The exchange of routing messages? >> > > Erm.. maybe we should consider your comments more deeply. Carles, one > of the authors suggested to remove 'end-to-end' from the text. The > text meant all the mechanisms that are used to perform routing > functions. I agree. >>> Some routing protocols are aware of the hop count of a path. >> I think all of them are, no? > > The text is to explain that simple hop-count is not enough for > 6lowpan. There exist Link quality based routing metrics than number of > hops. Ok. >>> In homes, buildings, or infrastructure, some nodes will be installed >>> with mains power. Such power-installed nodes MUST be >> If they have mains power - will they use Power-Line Communications? >> > > Not necessarily. For communication with sensors/actuators, 802.15.4 > radio communication is used, but supported by affluent power instead > of small battery.. > >>> Building monitoring applications, for instance, require that the mobile >>> devices SHOULD be capable of leaving (handing-off) from an old >>> network joining onto a new network within 15 seconds [17]. >> Should such a mobile device change its IP address or is it free to >> change it? >> > > Actually, I don't aware such a case that 6lowpan nodes need to change > the IP address yet. > We just give the example of ROLL documents which are targeting > specific applications, to explain some relavent work. Ok. >>> [R13] 6LoWPAN routing protocol SHOULD support various traffic patterns; >>> point-to-point, point-to-multipoint, and multipoint-to- point, while avoid >>> excessive multicast traffic (broadcast in link layer) in 6LoWPAN. >> It's called multicast at link-layer too (802.3); thus it avoids >> unnecessary packet duplication, thus it avoids duplication of >> broadcasted packets and thus avoids excessive traffic. >> >> If we talk IPv6 and recent link layers then I mostly forget the term >> 'broadcast' and use multicast instead. >> > > As I explained before, we would like to avoid IP multicast. I will > revise the text to make it clear as 'IP multicast'. > >>> 6LoWPAN routing protocols should be designed with the consideration of >>> forwarding packets from/to multiple sources/destinations. >> Sorry, what do you mean? An IP packet with multiple src fields? >> > > No, it means that some applications may have multiple sources that > transmit data to one destination; or a single source may transmit data > to several destination nodes; etc. That's much clearer. >>> Current WG drafts in the ROLL working group explain that the workload >>> or traffic pattern of use cases for 6LoWPANs tend to be highly >>> structured, unlike the any- to-any data transfers that dominate typical >>> client and server workloads. >> Sorry, what do you mean by 'any-to-any' data transfers? Any >> relationship to 'IP anycast'? > > No. but if IP anycast is used, it will be one way to implement > any-to-any data transfer. > >>> [R14] 6LoWPAN protocols SHOULD support secure delivery of control >>> messages. A minimal security level can be achieved by utilizing AES- >>> based mechanism provided by IEEE 802.15.4. >> Isn't AES superstrong and thus computation intensive and thus >> energy intensive? >> >> Intuitively speaking, maybe SHA-1 is sufficient for reduced needs in >> constrained environments. >> > > The IEEE 802.15.4 specification mandates support of AES. So, it is > given as an example of secure mechanism utilized from 802.15.4 > features. > >>> [R16] For neighbor discovery, 6LoWPAN devices SHOULD avoid sending "Hello" >>> messages. >> ND doesn't send Hello messages, but NS, NA, RS and RA. > > Ah~ Good point. we will make it clear for the revision. >>> [R18] If the routing protocol functionality includes enabling IP >>> multicast, then it may want to employ coordinator roles, if any, as relay >>> points of group-targeting messages instead of using link-layer >>> multicast (broadcast). >> link-layer multicast no broadcast. > > I don't know if 'link-layer multicast' is a proper term when 802.15.4 > does not provide multicast. Maybe that's a requirement to put on 802.15.4 not on 6LoWPAN. I mean it would be difficult to revive the 'broadcast' concept back into IPv6 documents, I suppose. Alex >> Nit: 'MAC sub-layer' appears only once and in the figure they're >> all 'layers'. >> >> Alex > > Thanks. we will change it. ;) > > Thank you very much to spend your time to review the documents. > We will gather a bit more comments and will soon post the revision > applying your comments. > Your comments are always appreciated. :) > > Best Regards, > -eunah > > >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > From pal@cs.stanford.edu Mon Feb 16 12:36:46 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 024833A6D0B for ; Mon, 16 Feb 2009 12:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOvhGRvhlO1y for ; Mon, 16 Feb 2009 12:36:44 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 07AD43A6D0A for ; Mon, 16 Feb 2009 12:36:44 -0800 (PST) Received: from 66-117-137-135.dsl.lmi.net ([66.117.137.135] helo=[192.168.0.102]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1LZAD0-0005iG-29; Mon, 16 Feb 2009 12:36:54 -0800 Message-Id: <4163E5B2-A9B1-4EEB-B181-29F732330BAF@cs.stanford.edu> From: Philip Levis To: Alexandru Petrescu In-Reply-To: <49993C5D.8050700@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 16 Feb 2009 12:36:53 -0800 References: <49958529.5010306@gmail.com> <7BDC023EB136F0499F260228BE2991BC2C23D8@rte-rat-exch.RTE.ADWIN.RENESAS.COM> <49993C5D.8050700@gmail.com> X-Mailer: Apple Mail (2.930.3) X-Scan-Signature: 506ee2a94cbf17163a55f02c75f10d0d Cc: ROLL WG , "David E. Culler" , Daniel Smolinski Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 20:36:46 -0000 On Feb 16, 2009, at 2:13 AM, Alexandru Petrescu wrote: > Daniel Smolinski a =E9crit : >> Hi all, >> Actually, from in the field experience, PLC can be quite a lossy =20 >> communication technology. We have seen many cases where influence =20 >> from appliances (e.g. microwave ovens) can cause disturbances on =20 >> the power line that makes communication impossible for some time. =20 >> Also, many PLC links are asymmetrical. > > That's good to know and other influences are related to the number of > devices plugged into a same wall socket. But these are warnings =20 > posted > on red stickers telling how to properly set up a PLC network. > > I'm not sure a layer-3 routing protocol should address these. > >> While I agree that the low-power requirement can be seen either =20 >> way, my experience tells me that PLC is definitely experiencing the =20= >> same problems as do wireless networks. > > It's true, wireless networks often seem non-deterministic in =20 > behaviour, > as wireless links do often. > > It's also very important to build a deterministic behaviour wireless > link-layer, with link-layer solutions. When that is achieved, a =20 > layer-3 > routing protocol is able to better run on top of it. In theory, I agree. Practice, however, has shown otherwise. For =20 example, a link layer could detect that the SNR of a link X has =20 dropped and so switches to a much lower bit rate. But a routing layer =20= might, given the choice, rather use another link Y than X at this =20 lower bit rate. Routing metrics are often tightly wound up with what =20 decision the link layer makes. Super-intelligent link layers that try =20= to do everything and mask this from higher layers generally lead to =20 bad routes. This does *not* mean that there needs to be some complex link/network =20= layer interaction. Rather, it means that a routing protocol can't =20 always assume that the link layer will work in its best interest, and =20= so a specification should not preclude it from making quick and agile =20= decisions. Phil= From STEVE.CHILDRESS@saic.com Mon Feb 16 12:49:02 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 955433A6D0A for ; Mon, 16 Feb 2009 12:49:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AcajNMEwY-D for ; Mon, 16 Feb 2009 12:49:01 -0800 (PST) Received: from cpmx.mail.saic.com (cpmx.mail.saic.com [139.121.17.160]) by core3.amsl.com (Postfix) with ESMTP id A46C13A6BCB for ; Mon, 16 Feb 2009 12:49:01 -0800 (PST) Received: from 0599-ITS-SMS01 ([139.121.17.139] [139.121.17.139]) by cpmx.mail.saic.com with ESMTP id BT-MMP-188451; Mon, 16 Feb 2009 12:48:56 -0800 X-AuditID: 8b79118b-a8a65ba000002b2e-f4-4999d138458b Received: from 0599-its-exbh01.us.saic.com (unknown [139.121.21.144]) by 0599-ITS-SMS01 (Symantec Mail Security) with ESMTP id 8AAD82012D; Mon, 16 Feb 2009 12:48:56 -0800 (PST) Received: from 0461-its-exmb01.us.saic.com ([10.8.67.21]) by 0599-its-exbh01.us.saic.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Feb 2009 12:48:56 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Feb 2009 12:48:56 -0800 Message-Id: <6532E5AE1BD6FF4B989254190D6FF15102942E54@0461-its-exmb01.us.saic.com> In-Reply-To: <4163E5B2-A9B1-4EEB-B181-29F732330BAF@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] ROLL re-chartering Thread-Index: AcmQdmqXWDK0MR8PQEC0l1ICyAKWPgAABytw References: <49958529.5010306@gmail.com> <7BDC023EB136F0499F260228BE2991BC2C23D8@rte-rat-exch.RTE.ADWIN.RENESAS.COM><49993C5D.8050700@gmail.com> <4163E5B2-A9B1-4EEB-B181-29F732330BAF@cs.stanford.edu> From: "Childress, Steve" To: "Philip Levis" , "Alexandru Petrescu" X-OriginalArrivalTime: 16 Feb 2009 20:48:56.0550 (UTC) FILETIME=[FC51D860:01C99077] X-Brightmail-Tracker: AAAAAA== Cc: ROLL WG , Daniel Smolinski , "David E. Culler" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 20:49:02 -0000 It would benefit the state of the art if we *finally* had a dynamic = routing protocol standard that correctly employs link quality metrics. = Wireless challenges are dynamic due to mobility and fleeting impairments = (without mobility, there's little need for wireless). This is not the = instantaneous SNR, RSSI, or SINADR (alias LQI). It's a temporal metric = of the correctable and uncorrectable FER (exclusive of coding/FEC) for = the last x amount of time, for all messages sent by the currently = favored neighbor node, irrespective of the destination MAC address. There are several proprietary implementations of these principles. steve childress -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Philip Levis Sent: Monday, February 16, 2009 12:37 PM To: Alexandru Petrescu Cc: ROLL WG; David E. Culler; Daniel Smolinski Subject: Re: [Roll] ROLL re-chartering On Feb 16, 2009, at 2:13 AM, Alexandru Petrescu wrote: > Daniel Smolinski a =E9crit : >> Hi all, >> Actually, from in the field experience, PLC can be quite a lossy=20 >> communication technology. We have seen many cases where influence=20 >> from appliances (e.g. microwave ovens) can cause disturbances on the=20 >> power line that makes communication impossible for some time. >> Also, many PLC links are asymmetrical. > > That's good to know and other influences are related to the number of=20 > devices plugged into a same wall socket. But these are warnings=20 > posted on red stickers telling how to properly set up a PLC network. > > I'm not sure a layer-3 routing protocol should address these. > >> While I agree that the low-power requirement can be seen either way,=20 >> my experience tells me that PLC is definitely experiencing the same=20 >> problems as do wireless networks. > > It's true, wireless networks often seem non-deterministic in=20 > behaviour, as wireless links do often. > > It's also very important to build a deterministic behaviour wireless=20 > link-layer, with link-layer solutions. When that is achieved, a > layer-3 > routing protocol is able to better run on top of it. In theory, I agree. Practice, however, has shown otherwise. For example, = a link layer could detect that the SNR of a link X has dropped and so = switches to a much lower bit rate. But a routing layer might, given the = choice, rather use another link Y than X at this lower bit rate. Routing = metrics are often tightly wound up with what decision the link layer = makes. Super-intelligent link layers that try to do everything and mask = this from higher layers generally lead to bad routes. This does *not* mean that there needs to be some complex link/network = layer interaction. Rather, it means that a routing protocol can't always = assume that the link layer will work in its best interest, and so a = specification should not preclude it from making quick and agile = decisions. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pister@eecs.berkeley.edu Mon Feb 16 14:01:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 673BA3A69DD for ; Mon, 16 Feb 2009 14:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qml8ZU7rG49Q for ; Mon, 16 Feb 2009 14:01:42 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 8B3F43A69DA for ; Mon, 16 Feb 2009 14:01:42 -0800 (PST) Received: from [70.212.254.158] (158.sub-70-212-254.myvzw.com [70.212.254.158]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n1GM1k0b025185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Feb 2009 14:01:48 -0800 (PST) Message-ID: <4999E25B.6080601@eecs.berkeley.edu> Date: Mon, 16 Feb 2009 14:02:03 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Philip Levis References: <49958529.5010306@gmail.com> <7BDC023EB136F0499F260228BE2991BC2C23D8@rte-rat-exch.RTE.ADWIN.RENESAS.COM> <49993C5D.8050700@gmail.com> <4163E5B2-A9B1-4EEB-B181-29F732330BAF@cs.stanford.edu> In-Reply-To: <4163E5B2-A9B1-4EEB-B181-29F732330BAF@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 22:01:43 -0000 Philip Levis wrote: > > On Feb 16, 2009, at 2:13 AM, Alexandru Petrescu wrote: > >> Daniel Smolinski a écrit : >>> Hi all, >>> Actually, from in the field experience, PLC can be quite a lossy >>> communication technology. We have seen many cases where influence >>> from appliances (e.g. microwave ovens) can cause disturbances on the >>> power line that makes communication impossible for some time. Also, >>> many PLC links are asymmetrical. >> >> That's good to know and other influences are related to the number of >> devices plugged into a same wall socket. But these are warnings posted >> on red stickers telling how to properly set up a PLC network. >> >> I'm not sure a layer-3 routing protocol should address these. >> >>> While I agree that the low-power requirement can be seen either way, >>> my experience tells me that PLC is definitely experiencing the same >>> problems as do wireless networks. >> >> It's true, wireless networks often seem non-deterministic in behaviour, >> as wireless links do often. >> >> It's also very important to build a deterministic behaviour wireless >> link-layer, with link-layer solutions. When that is achieved, a layer-3 >> routing protocol is able to better run on top of it. > > In theory, I agree. Practice, however, has shown otherwise. For > example, a link layer could detect that the SNR of a link X has > dropped and so switches to a much lower bit rate. But a routing layer > might, given the choice, rather use another link Y than X at this > lower bit rate. Routing metrics are often tightly wound up with what > decision the link layer makes. Super-intelligent link layers that try > to do everything and mask this from higher layers generally lead to > bad routes. > > This does *not* mean that there needs to be some complex link/network > layer interaction. How about a really simple one ;) > Rather, it means that a routing protocol can't always assume that the > link layer will work in its best interest, and so a specification > should not preclude it from making quick and agile decisions. I agree with Phil. The solution is not "magic PHY and/or MAC". A good phy/mac can help, and some are better than others, but the laws of physics do not allow for a deterministic link-layer with low power radios. That's one of the many challenges that make RoLL interesting. ksjp > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From Jerald.P.Martocci@jci.com Mon Feb 16 14:30:23 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A0A628C14D; Mon, 16 Feb 2009 14:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.029 X-Spam-Level: X-Spam-Status: No, score=-6.029 tagged_above=-999 required=5 tests=[AWL=0.569, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10qlQ1MtQfGR; Mon, 16 Feb 2009 14:30:20 -0800 (PST) Received: from exprod8og113.obsmtp.com (exprod8og113.obsmtp.com [64.18.3.26]) by core3.amsl.com (Postfix) with ESMTP id E743028C14C; Mon, 16 Feb 2009 14:30:19 -0800 (PST) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob113.postini.com ([64.18.7.12]) with SMTP ID DSNKSZnpBktZqVQPyvta+njfOXfQ+5qEHFlJ@postini.com; Mon, 16 Feb 2009 14:30:31 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009021616311569-1255115 ; Mon, 16 Feb 2009 16:31:15 -0600 In-Reply-To: <21EE679D-9A5D-4655-82B1-9A5E77ECB82A@cisco.com> MIME-Version: 1.0 To: JP Vasseur X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Mon, 16 Feb 2009 16:30:18 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 02/16/2009 04:30:25 PM, Serialize complete at 02/16/2009 04:30:25 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 02/16/2009 04:31:15 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 02/16/2009 04:31:20 PM, Serialize complete at 02/16/2009 04:31:20 PM Content-Type: multipart/alternative; boundary="=_alternative 007BA02B8625755F_=" Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] New Text for the Charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 22:30:23 -0000 This is a multipart message in MIME format. --=_alternative 007BA02B8625755F_= Content-Type: text/plain; charset="US-ASCII" Thanks for collating all the comments. It was getting hard to follow the changes. Unfortunately (for you), now I have more comments. Interlaced below ... JP Vasseur Sent by: roll-bounces@ietf.org 02/16/2009 06:32 AM To ROLL WG cc Subject [Roll] New Text for the Charter With all agreed changes ... Description of Working Group: 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, As best as I know, Bluetooth is a point-to-point protocol only. Not sure if it's a good example of mesh networks. 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 energy saving, Not sure what you mean by 'energy savings'. In past email threads we've discussed the need to balance energy in LLNs That is, use a node's available power as a input to the path cost. This doesn't really 'save' energy, it either 'balances' or 'conserves' energy. (NOTE: minor point, feel free to ignore). - Typical traffic patterns are not simply unicast flows (e.g. in some environments 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. As shown in a protocol survey existing routing protocols (in their current form) such as OSPF, IS-IS, AODV, and OLSR, do not meet 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), assets tracking. Typically the term is 'asset tracking' rather than 'assets 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 Not sure I'd use the word 'pressure'. How 'bout 'resources'. 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. I'm not sure what provoked this change from the original version. If I read this correctly, you believe that balancing communication or providing prioritized messaging (e.g. QoS) is outside the scope of the routing layer and in the province of the application. That can't be. Even if the source node's application could somehow regulate what and when messages get sent to the lower layers (unlikely); once the packet leaves the source node and starts its hopping, the routing layer on all intermediate nodes will have to handle the packet prioritization. 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 protocols 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: In light of the application specific routing requirements, the Working Group will either specify a new protocol and/ or will select an existing routing protocol (with the appropriate extensions in cooperation with the relevant Working Group). - Documentation of applicability statement of ROLL routing protocols. Goals and Milestones: Done Submit Routing requirements for Industrial applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Connected Home networks applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Building applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Urban networks applications to the IESG to be considered as an Informational RFC. July 2009 Submit Routing metrics for LLNs document to the IESG to be considered as a Proposed Standard. * Feb 2009 Submit Protocol Survey to the IESG to be considered as an Informational RFC. April 2009 Submit Security Framework to the IESG to be considered as an Informational RFC May 2009 Submit the Routing for LLNs Architecture document to the IESG as an Informational RFC. July 2009 Submit first draft of ROLL routing protocol specification as Proposed Standard. Nov 2009 Submit first draft of the MIB module of the ROLL routing protocol specification. Feb 2010 Submit the ROLL routing protocol specification to the IESG as Proposed Standard. March 2010 Submit the MIB module of the ROLL routing protocol specification to the IESG as Proposed Standard. April 2010 Evaluate WG progress, recharter or close. PS: I marked * the Milestones that will be "This Week" and before submitting to the IESG for re-chartering. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 007BA02B8625755F_= Content-Type: text/html; charset="US-ASCII"
Thanks for collating all the comments.  It was getting hard to follow the changes.  Unfortunately (for you), now I have more comments.  Interlaced below ...




JP Vasseur <jvasseur@cisco.com>
Sent by: roll-bounces@ietf.org

02/16/2009 06:32 AM

To
ROLL WG <roll@ietf.org>
cc
Subject
[Roll] New Text for the Charter





With all agreed changes ...


Description of Working Group:
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,

As best as I know, Bluetooth is a point-to-point protocol only.  Not sure if it's a good example of mesh networks.

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 energy saving,

Not sure what you mean by 'energy savings'.  In past email threads we've discussed the need to balance energy in LLNs  That is, use a node's available power as a input to the path cost.  This doesn't really 'save' energy, it either 'balances' or 'conserves' energy.  (NOTE: minor point, feel free to ignore).

-       Typical traffic patterns are not simply unicast flows (e.g. in  
some environments 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. As shown in a protocol survey existing routing protocols  
(in their current form) such as OSPF, IS-IS, AODV, and OLSR, do not  
meet 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), assets tracking.

Typically the term is 'asset tracking' rather than 'assets 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

Not sure I'd use the word 'pressure'. How 'bout 'resources'.

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.
I'm not sure what provoked this change from the original version.  If I read this correctly, you believe that balancing communication or providing prioritized messaging (e.g. QoS) is outside the scope of the routing layer and in the province of the application.  That can't be.  Even if the source node's application could somehow regulate what and when messages get sent to the lower layers (unlikely); once the packet leaves the source node and starts its hopping, the routing layer on all intermediate nodes will have to handle the packet prioritization.


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 protocols 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: In light of the application specific routing  
requirements, the Working Group will either specify a new protocol and/
or will select an existing routing protocol (with the appropriate  
extensions in cooperation with the relevant Working Group).
- Documentation of applicability statement of ROLL routing protocols.
Goals and Milestones:
Done   Submit Routing requirements for Industrial applications to the  
IESG to be considered as an Informational RFC.
Done Submit  Routing requirements for Connected Home networks  
applications to the IESG to be considered as an Informational RFC.
Done   Submit Routing requirements for Building applications to the  
IESG to be considered as an Informational RFC.
Done  Submit Routing requirements for Urban networks applications to  
the IESG to be considered as an Informational RFC.
July 2009    Submit Routing metrics for LLNs document to the IESG to  
be considered as a Proposed Standard.
* Feb 2009   Submit Protocol Survey to the IESG to be considered as an  
Informational RFC.
April 2009   Submit Security Framework to the IESG to be considered as  
an Informational RFC
May 2009     Submit the Routing for LLNs Architecture document to the  
IESG as an Informational RFC.
July 2009    Submit first draft of ROLL routing protocol specification  
as Proposed Standard.
Nov 2009     Submit first draft of the MIB module of the ROLL routing  
protocol specification.
Feb 2010     Submit the ROLL routing protocol specification to the  
IESG as Proposed Standard.
March 2010     Submit the MIB module of the ROLL routing protocol  
specification to the IESG as Proposed Standard.
April 2010     Evaluate WG progress, recharter or close.

PS: I marked * the Milestones that will be "This Week" and before  
submitting to the IESG for re-chartering.


_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 007BA02B8625755F_=-- From anand@ekasystems.com Mon Feb 16 14:40:00 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22DB13A689D for ; Mon, 16 Feb 2009 14:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.019 X-Spam-Level: X-Spam-Status: No, score=-0.019 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_50=0.001, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHS6Gm311PrC for ; Mon, 16 Feb 2009 14:39:59 -0800 (PST) Received: from smtp110.biz.mail.re2.yahoo.com (smtp110.biz.mail.re2.yahoo.com [206.190.53.9]) by core3.amsl.com (Postfix) with SMTP id 45BB53A6838 for ; Mon, 16 Feb 2009 14:39:59 -0800 (PST) Received: (qmail 73544 invoked from network); 16 Feb 2009 22:40:09 -0000 Received: from unknown (HELO ?192.168.0.207?) (anand@209.48.242.66 with plain) by smtp110.biz.mail.re2.yahoo.com with SMTP; 16 Feb 2009 22:40:09 -0000 X-YMail-OSG: hZrkyxIVM1lxGKtw44xIgTznmGv21fePqaLxjXkHd1eGmaB0FjwvnwCj1VNolTmCjYZK0pW.NN5cZqlqx_HQdjTDrrLQTTq3a7FpjqkXBMDx0q_sNNIxB0.Gpg.TJ.eUoHE5pZj1AHvCfo0gRyDQR_Os X-Yahoo-Newman-Property: ymail-3 Message-ID: <4999ED0F.9060205@ekasystems.com> Date: Mon, 16 Feb 2009 17:47:43 -0500 From: "M. B. Anand" User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: ROLL WG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] New Text for the Charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 22:40:00 -0000 Jerry, > > */As best as I know, Bluetooth is a point-to-point protocol only. Not > sure if it's a good example of mesh networks./* It defines a PHY and MAC and an LLC(even there it is actually point-to-multipoint) and in that respect is as much suited for mesh as any other. We have examples of operating large mesh networks (10s of K) with it. Regards, Anand. From pister@eecs.berkeley.edu Mon Feb 16 15:23:34 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ACF33A6BEB for ; Mon, 16 Feb 2009 15:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmqC8K5W-2Qm for ; Mon, 16 Feb 2009 15:23:33 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 9362F3A6A58 for ; Mon, 16 Feb 2009 15:23:33 -0800 (PST) Received: from [70.212.254.158] (158.sub-70-212-254.myvzw.com [70.212.254.158]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n1GNNeAY025860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Feb 2009 15:23:41 -0800 (PST) Message-ID: <4999F58C.8070303@eecs.berkeley.edu> Date: Mon, 16 Feb 2009 15:23:56 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "M. B. Anand" References: <4999ED0F.9060205@ekasystems.com> In-Reply-To: <4999ED0F.9060205@ekasystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] New Text for the Charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 23:23:34 -0000 Anand - is it Bluetooth (the industrial Special Interest Group) that defines the phy/max/llc, or IEEE 802.15.1? My understanding is that for our purposes, we'd use just what the IEEE standardized (phy/mac/llc) so that we could use plentiful low-cost radios, but not include the higher-layer stuff that the Bluetooth SIG specifies for applications. yes/no/maybe? ksjp M. B. Anand wrote: > Jerry, >> >> */As best as I know, Bluetooth is a point-to-point protocol only. >> Not sure if it's a good example of mesh networks./* > It defines a PHY and MAC and an LLC(even there it is actually > point-to-multipoint) and in that respect is as much suited for mesh as > any other. We have examples of operating large mesh networks (10s of > K) with it. > > Regards, > Anand. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From anand@ekasystems.com Mon Feb 16 16:06:13 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2AB83A6818 for ; Mon, 16 Feb 2009 16:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.112 X-Spam-Level: X-Spam-Status: No, score=-1.112 tagged_above=-999 required=5 tests=[AWL=0.887, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlM9jcLS1Qs4 for ; Mon, 16 Feb 2009 16:06:13 -0800 (PST) Received: from smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by core3.amsl.com (Postfix) with SMTP id BB3B43A6838 for ; Mon, 16 Feb 2009 16:06:12 -0800 (PST) Received: (qmail 64753 invoked from network); 17 Feb 2009 00:06:23 -0000 Received: from unknown (HELO ?192.168.0.207?) (anand@209.48.242.66 with plain) by smtp107.biz.mail.re2.yahoo.com with SMTP; 17 Feb 2009 00:06:22 -0000 X-YMail-OSG: 8TogC3sVM1kltsAk6fk.I0ak7ALhWKdMLZLYMLGldlgGHGbjlBytErjdC6zLMcx.D_MNPkmx9w.W4BJn.mmYPK7sZWzjwhIuCpDoBVDoizG1k8nC.kZjDA0JDW8YKUvVSmCIb4YAWxFAHxe.4aAZ7R9j7UB6x9__G79gnsAOgEVe_iM2sVvLf_hVZp.mAPuTZHXriVSanyMgmoZ81wjA5hq3dnHn X-Yahoo-Newman-Property: ymail-3 Message-ID: <499A0143.8020908@ekasystems.com> Date: Mon, 16 Feb 2009 19:13:55 -0500 From: "M. B. Anand" User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: ROLL WG References: <4999ED0F.9060205@ekasystems.com> <4999F58C.8070303@eecs.berkeley.edu> In-Reply-To: <4999F58C.8070303@eecs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] New Text for the Charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 00:06:13 -0000 Kris, 15.1 is Bluetooth 1.1 and it actually defines the same conformance as Bluetooth as a normative annex, and you do need to get Bluetooth-qualified in order to comply with this. You don't need all the application profiles to qualify but there is a minimal generic subset. So, the answer here is maybe, depending on what one needs for qualification. Of course, Bluetooth itself is now at version 2.1 and draft 3.0, so for those, there is no equivalent IEEE. Regards, Anand. > Anand - is it Bluetooth (the industrial Special Interest Group) that > defines the phy/max/llc, or IEEE 802.15.1? > My understanding is that for our purposes, we'd use just what the IEEE > standardized (phy/mac/llc) so that we could use plentiful low-cost > radios, but not include the higher-layer stuff that the Bluetooth SIG > specifies for applications. > > yes/no/maybe? > > ksjp > > M. B. Anand wrote: >> Jerry, >>> >>> */As best as I know, Bluetooth is a point-to-point protocol only. >>> Not sure if it's a good example of mesh networks./* >> It defines a PHY and MAC and an LLC(even there it is actually >> point-to-multipoint) and in that respect is as much suited for mesh >> as any other. We have examples of operating large mesh networks (10s >> of K) with it. >> >> Regards, >> Anand. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > From jvasseur@cisco.com Tue Feb 17 00:07:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A4F83A6899; Tue, 17 Feb 2009 00:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.578 X-Spam-Level: X-Spam-Status: No, score=-10.578 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yp81V7YWPw-v; Tue, 17 Feb 2009 00:07:11 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 584913A6853; Tue, 17 Feb 2009 00:07:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,222,1233532800"; d="scan'208,217";a="33970868" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Feb 2009 08:07:01 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1H871QI003366; Tue, 17 Feb 2009 09:07:01 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1H871OC013355; Tue, 17 Feb 2009 08:07:01 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Feb 2009 09:07:01 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Feb 2009 09:07:00 +0100 Message-Id: <498D221E-E246-493F-AEA4-9B4A866B95FF@cisco.com> From: JP Vasseur To: Jerald.P.Martocci@jci.com In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-78-1000266094 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 17 Feb 2009 09:07:00 +0100 References: X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 17 Feb 2009 08:07:00.0843 (UTC) FILETIME=[B60C4BB0:01C990D6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=19912; t=1234858021; x=1235722021; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20New=20Text=20for=20the=20Chart er |Sender:=20; bh=kC+STjOH0/+1naB7JsnqqSuzODNR3iZLwEJf983tm0g=; b=G1K3KZ0b9KJPUBZzblqoidyrjf3ZPjDXBx+Btp+7blwHLRYCQRXs8GuzOE wHOYU2Ev9vbgd+nelniFEOW2wGK99Cb0E0DZ7O6pSUr5ICkwJ6VWySUjgLn6 BFcX8N6XOn; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] New Text for the Charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 08:07:18 -0000 --Apple-Mail-78-1000266094 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hello Jerry, On Feb 16, 2009, at 11:30 PM, Jerald.P.Martocci@jci.com wrote: > > Thanks for collating all the comments. It was getting hard to > follow the changes. Unfortunately (for you), now I have more > comments. Interlaced below ... > That was my fear ;-))) - In line, > > > > JP Vasseur > Sent by: roll-bounces@ietf.org > 02/16/2009 06:32 AM > > To > ROLL WG > cc > Subject > [Roll] New Text for the Charter > > > > > > With all agreed changes ... > > > Description of Working Group: > 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, > > As best as I know, Bluetooth is a point-to-point protocol only. Not > sure if it's a good example of mesh networks. The meshing is at the Layer 3. > > > 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 energy saving, > > Not sure what you mean by 'energy savings'. In past email threads > we've discussed the need to balance energy in LLNs That is, use a > node's available power as a input to the path cost. This doesn't > really 'save' energy, it either 'balances' or 'conserves' energy. > (NOTE: minor point, feel free to ignore). Thanks - If you balance energy, this is to "save" energy on some node. Let's keep that wording. > > > - Typical traffic patterns are not simply unicast flows (e.g. in > some environments 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. As shown in a protocol survey existing routing protocols > (in their current form) such as OSPF, IS-IS, AODV, and OLSR, do not > meet 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), assets tracking. > > Typically the term is 'asset tracking' rather than 'assets tracking' Yes Thanks. > > > 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 > > Not sure I'd use the word 'pressure'. How 'bout 'resources'. > > 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. > > I'm not sure what provoked this change from the original version. > If I read this correctly, you believe that balancing communication > or providing prioritized messaging (e.g. QoS) is outside the scope > of the routing layer and in the province of the application. That > can't be. Even if the source node's application could somehow > regulate what and when messages get sent to the lower layers > (unlikely); once the packet leaves the source node and starts its > hopping, the routing layer on all intermediate nodes will have to > handle the packet prioritization. This has not been changed and was there from day one. I would insist to keep it since this is the result of discussion with other ADs to avoid ambiguity: Yes, application related issues are not in our scope. > > > > 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 protocols 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: In light of the application specific routing > requirements, the Working Group will either specify a new protocol > and/ > or will select an existing routing protocol (with the appropriate > extensions in cooperation with the relevant Working Group). > - Documentation of applicability statement of ROLL routing protocols. > Goals and Milestones: > Done Submit Routing requirements for Industrial applications to the > IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Connected Home networks > applications to the IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Building applications to the > IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Urban networks applications to > the IESG to be considered as an Informational RFC. > July 2009 Submit Routing metrics for LLNs document to the IESG to > be considered as a Proposed Standard. > * Feb 2009 Submit Protocol Survey to the IESG to be considered as an > Informational RFC. > April 2009 Submit Security Framework to the IESG to be considered as > an Informational RFC > May 2009 Submit the Routing for LLNs Architecture document to the > IESG as an Informational RFC. > July 2009 Submit first draft of ROLL routing protocol specification > as Proposed Standard. > Nov 2009 Submit first draft of the MIB module of the ROLL routing > protocol specification. > Feb 2010 Submit the ROLL routing protocol specification to the > IESG as Proposed Standard. > March 2010 Submit the MIB module of the ROLL routing protocol > specification to the IESG as Proposed Standard. > April 2010 Evaluate WG progress, recharter or close. > > PS: I marked * the Milestones that will be "This Week" and before > submitting to the IESG for re-chartering. > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --Apple-Mail-78-1000266094 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello = Jerry,

On Feb 16, 2009, at 11:30 PM, Jerald.P.Martocci@jci.com = wrote:


Thanks for collating all the comments. =  It was getting hard to follow the changes.  Unfortunately = (for you), now I have more comments.  Interlaced below = ...


That was my = fear ;-))) - In line,




=
JP Vasseur <jvasseur@cisco.com> =
Sent by: roll-bounces@ietf.org

<= font size=3D"1" face=3D"sans-serif">02/16/2009 06:32 AM =

To
ROLL WG <roll@ietf.org>
cc
Subject
[Roll] New Text for the = Charter

=



With = all agreed changes ...


Description of Working Group:
= 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,

As best as I know, Bluetooth is a = point-to-point protocol only.  Not sure if it's a good example of = mesh networks.

The = meshing is at the Layer 3.



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 energy saving, =

Not sure what you mean by 'energy savings'. =  In past email threads we've discussed the need to balance energy = in LLNs  That is, use a node's available power as a input to the = path cost.  This doesn't really 'save' energy, it either 'balances' = or 'conserves' energy.  (NOTE: minor point, feel free to = ignore).

Thanks - If you = balance energy, this is to "save" energy on some node. Let's keep that = wording.



= -       Typical traffic patterns are not simply unicast = flows (e.g. in  
some environments 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. As shown in a = protocol survey existing routing protocols  
(in their current = form) such as OSPF, IS-IS, AODV, and OLSR, do not  
meet 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), assets tracking.

Typically the term is 'asset = tracking' rather than 'assets tracking' =

Yes Thanks.



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

Not sure I'd use the = word 'pressure'. How 'bout 'resources'.

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.
I'm not sure what provoked this change from = the original version.  If I read this correctly, you believe that = balancing communication or providing prioritized messaging (e.g. QoS) is = outside the scope of the routing layer and in the province of the = application.  That can't be.  Even if the source node's = application could somehow regulate what and when messages get sent to = the lower layers (unlikely); once the packet leaves the source node and = starts its hopping, the routing layer on all intermediate nodes will = have to handle the packet prioritization. =

This has not been = changed and was there from day one. I would insist to keep it since this = is the result of discussion with other ADs to avoid ambiguity: Yes, = application related issues are not in our scope.




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 protocols 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: In light of the application specific routing  
= requirements, the Working Group will either specify a new protocol and/ =
or will select an existing routing protocol (with the appropriate =  
extensions in cooperation with the relevant Working = Group).
- Documentation of applicability statement of ROLL routing = protocols.
Goals and Milestones:
Done   Submit Routing = requirements for Industrial applications to the  
IESG to be = considered as an Informational RFC.
Done Submit  Routing = requirements for Connected Home networks  
applications to the = IESG to be considered as an Informational RFC.
Done   Submit = Routing requirements for Building applications to the  
IESG to = be considered as an Informational RFC.
Done  Submit Routing = requirements for Urban networks applications to  
the IESG to = be considered as an Informational RFC.
July 2009    Submit = Routing metrics for LLNs document to the IESG to  
be = considered as a Proposed Standard.
* Feb 2009   Submit Protocol = Survey to the IESG to be considered as an  
Informational = RFC.
April 2009   Submit Security Framework to the IESG to be = considered as  
an Informational RFC
May 2009     = Submit the Routing for LLNs Architecture document to the  
IESG = as an Informational RFC.
July 2009    Submit first draft = of ROLL routing protocol specification  
as Proposed = Standard.
Nov 2009     Submit first draft of the MIB = module of the ROLL routing  
protocol specification.
Feb = 2010     Submit the ROLL routing protocol specification to the =  
IESG as Proposed Standard.
March 2010     = Submit the MIB module of the ROLL routing protocol  
= specification to the IESG as Proposed Standard.
April 2010   =   Evaluate WG progress, recharter or close.

PS: I marked * = the Milestones that will be "This Week" and before  
submitting = to the IESG for re-chartering.


= _______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll
 =

= --Apple-Mail-78-1000266094-- From eunah.ietf@gmail.com Tue Feb 17 02:19:08 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 228E63A6A97; Tue, 17 Feb 2009 02:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uh1+CyD5cz1o; Tue, 17 Feb 2009 02:19:07 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id 030903A65A5; Tue, 17 Feb 2009 02:19:06 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1886759rvb.49 for ; Tue, 17 Feb 2009 02:19:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/u645bGurOoggUmGJST06zE0mTObRl76Ppbd+0QRtPQ=; b=rNhU3f3kLv5phJndCUmF4TD/t7Hs9MIQ0PPKtiILyCLsC+RtN+9om2QxVUd8Rx/eo3 pPtF2bTA7WiuSs2LCQcrtJpGSpmrAeyPl53tSbmS+xTuVyYB52cL3d9Zb9PwY3PCioci YVDYwHu82W23sI8Itj0gFNzbWMYIG+U4oDRVg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FMNQozU2XVSJfV47fy4OIPCwi3BiDaTtfHYQg5AViMmiaZ/ljRcXhrWm/XUH2ISTPt 4rwya2CfZx2J21e8RRNf2o5hUL8IhuDMGA8/48cW62S0+GdRhYp7Q1AkiKiIw9aUnXxw D3Edq2jMZDe3gPvIqmi0zWkp71feqaQ99D4Uo= MIME-Version: 1.0 Received: by 10.141.195.5 with SMTP id x5mr3189438rvp.282.1234865957235; Tue, 17 Feb 2009 02:19:17 -0800 (PST) In-Reply-To: <49997D6E.2030409@gmail.com> References: <4992FD7F.8070408@gmail.com> <77f1dba80902160228s4b25285ageb085c51c402fd40@mail.gmail.com> <49997D6E.2030409@gmail.com> Date: Tue, 17 Feb 2009 19:19:17 +0900 Message-ID: <77f1dba80902170219r6a0b319awfffab6aef2abbfe9@mail.gmail.com> From: "Eunsook \"Eunah\" Kim" To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ROLL WG , 6lowpan@ietf.org Subject: Re: [Roll] Comments on draft-ietf-6lowpan-routing-requirements-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 10:19:08 -0000 Alex, Thanks again. :) I put my answers in line. > Thanks for the message. I mainly agree with you. I commented on some of > the text, below. > >>> Some high-level questions: >>> -is there a requirement to connect a 6LoWPAN network to the Internet? >> >> Do you mean in terms of routing? Or a general view of 6LoWPAN? >> The birth of 6LoWPAN is to make the Low-power low rate network (based >> on IEEE 802.15.4) look like an IPv6 link. >> >> If you only meant routing, the reachability can be achieved by mesh >> routing (or mesh switching in your comment below) or route-over. >> >> I don't know if it answers your question. > > If a network running 6LoWPAN routing system (designed according to > 6lowpan-routing-requirements) is connected to the Internet - will anything > break? > Basically, no I don't think so. But, I would like to explain two scenarios to consider. Let's consider the network like this: (a 6lowpan:A)--(gateway/ER)--(outside ipv6 network:B) 1. mesh-under: every node in A does routing (switching/forwarding/or other proper term) with MAC address within A. It is not directly do routing to a node in B. This mechanism is used for this limited situation, and many existing sensor networks based on 802.15.4 have been deployed fitting in the concept. 2. route-over: basically, it should be the same as traditional IPv6 routing, except the gateway needs to work on compression/decompression of IP/UDP.. headers. [snip..] > > Will the 6LoWPAN router use longest-prefix match (as IP protocols do) or > exact-match (as some VLAN switch protocols do). > In route-over, every intermediate node which performs routing fucntions is called 6lowpan router. I didn't see a runing route-over solution for 6LoWPAN yet. In my opinion, it will use as IP protocols do. (I understand that's the concept of route-over. I think ROLL people may answer it more clearly) In mesh-under, generally, one IPv6 router exists in one 6lowpan. 6lowpan nodes in the lowpan will perform routing functions but not use IPv6 address. Whole 6lowpan is one IPv6 link, and the IPv6 router of 6lowpan will act as a normal IPv6 router to communicate with other IPv6 router outside of the 6lowpan, but the functionality for inside of 6lowpan routing would differ (not use IPv6 addresses). I would like to know it helps you to understand better. > Will the 6LoWPAN addressing architecture be local to the network, or > integrated in the Internet. Both are supported. As Hamid already explained, the current 6LoWPAN format documents (RFC 4944 and HC1) supports both link-local and global addressing. >[snip..] >>>> On the other hand, the route-over approach relies on IP routing and >>>> therefore supports routing over possibly various types of interconnected >>>> links (see also Figure 1). >>> >>> At several places in the draft, when link 'types', device 'types' are >>> mentioned, I'm tempted to believe 6LoWPAN considers links other than >>> 802.15.4 links? Is it so? Should 6LoWPAN routing protocol work also >>> with aseptic point-to-point links? >>> Or are the 'types' limited within the relatively large scope of 802.3 >>> compatible MACs (I believe 802.15.4 and 802.16 to fit within). >>> >>> This is of paramount importance in setting the scope. >>> >> >> Oh, link 'type'. ;) Currently 6lowpan is clearly based on 802.15.4, >> although some talks that 6LoWPAN can run on top of other radios with >> similar characteristics. And, for route-over (as ROLL WG is working >> on), the benefit which have been insisted is that the routing >> mechanism is link-independent. Mesh-under of 6lowpan is 802.15.4 >> dependent. >> But I don't know what is 'aseptic' point to point links. > > Sorry, I meant 'aseptic' to say point-to-point links over which ND is not > run actually, no need for ND nor DAD. They have specific ways in which the > IPv6 link-local address is formed. They're often independent on the link > layer technology. PPP over IPv6 (RFC) is an example. > Oh, we need ND, and you already know the draft. :) >>>> a. Network Properties: >>>> >>>> * Number of Devices, Density and Network Diameter: These parameters >>>> usually affect the routing state directly (e.g. the number of >>>> entries in a routing table or neighbor list). Especially in large >>>> and dense networks, policies must >>> >>> What is 'large' and 'dense'? Is it about physical dimensions? Or IP >>> dimensions? >> >> It is about physical dimensions. > > I think Diameter has a physical sense only if it's a circle. I don't think > networks have a physical shape of a circle. I may be wrong though. > I also need to check. Maybe Carles (one of the co-authors who works on routing parameters) can answer it? ;) [snip..] >>>> [R18] If the routing protocol functionality includes enabling IP >>>> multicast, then it may want to employ coordinator roles, if any, as >>>> relay >>>> points of group-targeting messages instead of using link-layer >>>> multicast (broadcast). >>> >>> link-layer multicast no broadcast. >> >> I don't know if 'link-layer multicast' is a proper term when 802.15.4 >> does not provide multicast. > > Maybe that's a requirement to put on 802.15.4 not on 6LoWPAN. > > I mean it would be difficult to revive the 'broadcast' concept back into > IPv6 documents, I suppose. > Yes, i also think that it's great if 802.15.4 supports link-layer multicast. As it does not, 6lowpan wants to avoid IP multicast which causes link broadcast as much as possible. I should think what else term can be used instead of broadcast if it is not acceptable termniology. > Alex > Thanks again for your valuable comments. I'm working on revision to apply your considerations and comments. :) I will soon upload it. But please feel free to give your opinion in any moment. :) -eunah -eunah From abr@zen-sys.com Tue Feb 17 06:01:05 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DA6E3A6A69 for ; Tue, 17 Feb 2009 06:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65Jfz3g1Mzzd for ; Tue, 17 Feb 2009 06:01:04 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 921433A6B5D for ; Tue, 17 Feb 2009 06:01:03 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Feb 2009 15:01:13 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429524@zensys17.zensys.local> In-Reply-To: <49987D77.8030000@ekasystems.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] ROLL re-chartering Thread-Index: AcmPrX85XX9HyDrYSdipbdRXDgIdIQBWnnKw References: <9B90C6C0-194C-4784-AE81-B18F6C7421D4@cisco.com> <49987D77.8030000@ekasystems.com> From: "Anders Brandt" To: "ROLL WG" Subject: Re: [Roll] ROLL re-chartering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 14:01:05 -0000 I am happy with the proposed charter. cheers, Anders JP Vasseur wrote: > Dear WG, >=20 > As indicated in a previous email, the protocol survey I-D will be send > for publication this week (after posting of the last revision=20 > incorporating several useful comments). >=20 > As promised please find below the new proposed charter to be submitted > to the IESG for approval. In the hope of getting quickly re-chartered=20 > thanks to let us know if you have any comment by the ned of this week. > The new charter is pretty straightforward. >=20 > Thanks to Dave Ward for his comments and guidance. >=20 > Description of Working Group: >=20 > Low power and Lossy networks (LLNs) are typically composed of many=20 > embedded devices with limited power, memory, and processing resources=20 > interconnected by a variety of links, such as IEEE 802.15.4,=20 > Bluetooth, Low Power WiFi or other low power PLC (Powerline Communication) links. > LLNs are transitioning to an end-to-end IP-based solution to avoid=20 > the problem of non-interoperable networks interconnected by protocol=20 > translation gateways and proxies. LLNs have specific characteristics: > - LLNs operate with a hard, very small bound on state, > - In most cases, LLN need to be optimized for energy saving, > - Typical traffic patterns are not simply unicast flows, > - In most cases, LLNs need to be effective with very small packet > sizes, > - LLN routing protocols have to be very careful when trading off > efficiency for generality; many LLN nodes do not have resources to waste. >=20 > These unique properties lead to unique routing requirements that may=20 > not met by existing routing protocols, such as OSPF, IS-IS, AODV and=20 > OLSR. For example path selection must be designed to take into=20 > consideration the specific power capabilities, attributes and=20 > functional characteristics of the links and nodes in the network. >=20 >=20 >=20 > The Working Group is focused on routing issues for LLN >=20 > There is a wide scope of application areas for LLNs, including =20 > industrial monitoring, building automation (HVAC, lighting, access=20 > control, fire), connected home, healthcare, environmental monitoring,=20 > urban sensor networks sensor networks, assets tracking, refrigeration. > The Working Group will only focus on routing solutions for a subset of > these. It will focus on industrial, connected home, building and urban > sensor networks and specify the set of routing requirements for these > scenarios. >=20 > The Working Group focuses only on IPv6 only routing architectural =20 > framework for these application scenarios. The Framework will take=20 > into consideration various aspects including high reliability in the=20 > presence of time varying loss characteristics and connectivity while=20 > permitting low-power operation with very modest memory and CPU=20 > pressure in networks potentially comprising a very large number=20 > (several thousands) of nodes. > The Working Group will explore aspects of mobility within a single LLN > (if any) in the routing requirement creation. >=20 > The Working Group will pay particular attention to routing security=20 > and manageability (e.g., self configuration) issues. It will also need > to consider the transport characteristic the routing protocol=20 > messages will experience. Mechanisms that protect an LLN from=20 > congestion collapse or that establish some degree of fairness between > concurrent communication sessions are out of scope of the Working=20 > Group. It is expected that upper-layer applications utilizing LLNs define appropriate mechanisms. >=20 >=20 > Work Items: >=20 > - Specification of routing metrics used in path calculation. This=20 > includes static and dynamic link/node attributes required for routing=20 > in LLNs. >=20 >=20 >=20 > - Provide an architectural framework for routing and path selection at > Layer 3 (Routing for LLN Architecture) that addresses such issues as=20 > whether LLN routing protocols 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=20 > approach, along with various trade-offs for maintaining low power=20 > operation, including the presence of non-trivial loss and networks=20 > with a very large number of nodes. >=20 >=20 > - Produce a routing security framework for routing in LLNs. >=20 > - Protocol work: In light of the application specific routing=20 > requirements, the Working Group will either specify a new protocol=20 > and/or will select an existing routing protocol (with the appropriate=20 > extensions in cooperation with the relevant Working Group). >=20 > - Documentation of applicability statement of ROLL routing protocols. >=20 > Goals and Milestones: >=20 > Done Submit Routing requirements for Industrial applications to the > IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Connected Home networks > applications to the IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Building applications to the IESG > to be considered as an Informational RFC. > Done Submit Routing requirements for Urban networks applications to > the IESG to be considered as an Informational RFC. > July 2009 Submit Routing metrics for LLNs document to the IESG to be > considered as a Proposed Standard. > * Feb 2009 Submit Protocol Survey to the IESG to be considered as an > Informational RFC. > April 2009 Submit Security Framework to the IESG to be considered as > an Informational RFC > May 2009 Submit the Routing for LLNs Architecture document to the > IESG as an Informational RFC. > July 2009 Submit first draft of ROLL routing protocol specification > as Proposed Standard. > Nov 2009 Submit first draft of the MIB module of the ROLL routing > protocol specification. > Dec 2009 Submit the ROLL routing protocol specification to the IESG > as Proposed Standard. > Jan 2010 Submit the MIB module of the ROLL routing protocol > specification to the IESG as Proposed Standard. > Jan 2010 Evaluate WG progress, recharter or close. >=20 > PS: I marked * the Milestones that will be "This Week" and before=20 > submitting to the IESG for re-chartering. >=20 >=20 >=20 > Thanks. >=20 > JP and David. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From root@core3.amsl.com Tue Feb 17 14:30:01 2009 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E1B333A6812; Tue, 17 Feb 2009 14:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090217223001.E1B333A6812@core3.amsl.com> Date: Tue, 17 Feb 2009 14:30:01 -0800 (PST) Cc: roll@ietf.org Subject: [Roll] I-D ACTION:draft-ietf-roll-protocols-survey-06.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 22:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Overview of Existing Routing Protocols for Low Power and Lossy Networks Author(s) : A. Tavakoli, S. Dawson-Haggerty, P. Levis Filename : draft-ietf-roll-protocols-survey-06.txt Pages : 26 Date : 2009-2-17 Low-power wireless devices, such as sensors, actuators and smart objects, present difficult constraints: very limited memory, little processing power, and long sleep periods. As most of these devices are battery-powered, energy efficiency is critically important. Wireless link qualities can vary significantly over time, requiring protocols to make agile decisions yet minimize topology change energy costs. Routing over such low power and lossy networks introduces requirements that existing routing protocols may not fully address. Using existing application requirements documents, this document derives a minimal and not exhaustive set of criteria for routing in low-power and lossy networks. It provides a brief survey of the strengths and weaknesses of existing protocols with respect to these criteria. From this survey it examines whether existing and mature IETF protocols can be used without modification in these networks, or whether further work is necessary. It concludes that no existing IETF protocol meets the requirements of this domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-survey-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-protocols-survey-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-2-17142958.I-D@ietf.org> --NextPart-- From tzeta.tsao@ekasystems.com Tue Feb 17 15:29:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66C843A6948 for ; Tue, 17 Feb 2009 15:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMyIs4zUSKch for ; Tue, 17 Feb 2009 15:29:41 -0800 (PST) Received: from smtp110.biz.mail.re2.yahoo.com (smtp110.biz.mail.re2.yahoo.com [206.190.53.9]) by core3.amsl.com (Postfix) with SMTP id 738573A659C for ; Tue, 17 Feb 2009 15:29:41 -0800 (PST) Received: (qmail 8639 invoked from network); 17 Feb 2009 23:29:53 -0000 Received: from unknown (HELO ?192.168.0.237?) (tzeta.tsao@209.48.242.66 with plain) by smtp110.biz.mail.re2.yahoo.com with SMTP; 17 Feb 2009 23:29:52 -0000 X-YMail-OSG: 03EBhOIVM1nrv3spn1Su8qipszqgMjkeeSW3opm41HOIowTEHXMjFbA67NQe5E68JYLgOUJFTxv02UqkyknMjfQh4FOwvDFbNNjFAdAu7TX2ew_GJ116o2MdcgEVkbUni23ot7FbLVjavA7LCikCKpNc X-Yahoo-Newman-Property: ymail-3 Message-ID: <499B486F.2060603@ekasystems.com> Date: Tue, 17 Feb 2009 18:29:51 -0500 From: Tzeta Tsao User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: roll@ietf.org X-Enigmail-Version: 0.95.0 Content-Type: multipart/mixed; boundary="------------010806000002090103040104" Subject: [Roll] [Fwd: New Version Notification for draft-tsao-roll-security-framework-00] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 23:29:42 -0000 This is a multi-part message in MIME format. --------------010806000002090103040104 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit WG, We have posted draft-tsao-roll-security-framework-00, which should be available from the repository shortly. >From the abstract: This document presents a security framework for routing over low power and lossy networks. The development of the framework builds upon previous work on routing security and adapts the security assessments to the issues and constraints specific to low power and lossy networks. A systematic approach is used in defining and assessing the security threats and identifying applicable countermeasures. These assessments provide the basis of the security recommendations for incorporation into low power, lossy network routing protocols. We greatly appreciate it if you would comment to the list. Thanks, Tzeta Tsao --------------010806000002090103040104 Content-Type: message/rfc822; name="New Version Notification for draft-tsao-roll-security-framework-00.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="New Version Notification for draft-tsao-roll-securi"; filename*1="ty-framework-00.eml" X-Account-Key: account3 X-Mozilla-Keys: X-Apparently-To: tzeta.tsao@ekasystems.com via 67.195.14.48; Tue, 17 Feb 2009 15:22:57 -0800 X-Originating-IP: [64.170.98.32] Authentication-Results: mta109.biz.mail.re3.yahoo.com from=ietf.org; domainkeys=neutral (no sig) Received: from 64.170.98.32 (EHLO mail.ietf.org) (64.170.98.32) by mta109.biz.mail.re3.yahoo.com with SMTP; Tue, 17 Feb 2009 15:22:56 -0800 Received: by core3.amsl.com (Postfix, from userid 30) id 4D9C928C18E; Tue, 17 Feb 2009 15:22:44 -0800 (PST) From: IETF I-D Submission Tool To: tzeta.tsao@ekasystems.com Cc: roger.alexander@ekasystems.com,mischa.dohler@cttc.es,vanesa.daza@upf.edu,angel.lozano@upf.edu Subject: New Version Notification for draft-tsao-roll-security-framework-00 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090217232244.4D9C928C18E@core3.amsl.com> Date: Tue, 17 Feb 2009 15:22:44 -0800 (PST) A new version of I-D, draft-tsao-roll-security-framework-00.txt has been successfuly submitted by Tzeta Tsao and posted to the IETF repository. Filename: draft-tsao-roll-security-framework Revision: 00 Title: A Security Framework for Routing over Low Power and Lossy Networks Creation_date: 2009-02-16 WG ID: Independent Submission Number_of_pages: 30 Abstract: This document presents a security framework for routing over low power and lossy networks. The development of the framework builds upon previous work on routing security and adapts the security assessments to the issues and constraints specific to low power and lossy networks. A systematic approach is used in defining and assessing the security threats and identifying applicable countermeasures. These assessments provide the basis of the security recommendations for incorporation into low power, lossy network routing protocols. The IETF Secretariat. --------------010806000002090103040104-- From chris.dearlove@baesystems.com Wed Feb 18 02:24:13 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F007C28C1E4 for ; Wed, 18 Feb 2009 02:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbv1niYbJb5v for ; Wed, 18 Feb 2009 02:24:13 -0800 (PST) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 961CD28C1AB for ; Wed, 18 Feb 2009 02:24:11 -0800 (PST) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n1IAOKHC020243 for ; Wed, 18 Feb 2009 10:24:21 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n1IAOKgG032659 for ; Wed, 18 Feb 2009 10:24:20 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 18 Feb 2009 10:24:04 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 18 Feb 2009 10:24:19 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 18 Feb 2009 10:24:17 -0000 Message-ID: In-Reply-To: <21EE679D-9A5D-4655-82B1-9A5E77ECB82A@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] New Text for the Charter Thread-Index: AcmQNLjh615rEK/JSYm0muVTMcjK4ABfMATA References: <21EE679D-9A5D-4655-82B1-9A5E77ECB82A@cisco.com> From: "Dearlove, Christopher (UK)" To: "JP Vasseur" , "ROLL WG" X-OriginalArrivalTime: 18 Feb 2009 10:24:19.0777 (UTC) FILETIME=[0F3F9B10:01C991B3] Subject: Re: [Roll] New Text for the Charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 10:24:14 -0000 > With all agreed changes ... I'm not sure if this is too late or not. If it isn't too late, here's my one comment. If it is, then OK, not in the charter, but do you see it as (a), (b) or (c)? Apart from timescale questions, the only issue I see, which others have commented on, is that one of the five distinguishing characteristics is that simple unicast flows are not typical, but nothing is then said about this in the work items. I think that the work items should clearly indicate whether (a) unicast only [but that disagrees with the characteristics], (b) unicast and multicast [significantly more work, and is this a single routing protocol, as in the plan, or not?], or (c) determining whether multicast is required is part of the work [but that's not really consistent with the plan as written]. --=20 Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Jerald.P.Martocci@jci.com Wed Feb 18 06:15:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E22783A6D39; Wed, 18 Feb 2009 06:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.219 X-Spam-Level: X-Spam-Status: No, score=-6.219 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7LiToqBngG0; Wed, 18 Feb 2009 06:15:17 -0800 (PST) Received: from exprod8og106.obsmtp.com (exprod8og106.obsmtp.com [64.18.3.92]) by core3.amsl.com (Postfix) with ESMTP id 40BC13A6843; Wed, 18 Feb 2009 06:15:17 -0800 (PST) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob106.postini.com ([64.18.7.12]) with SMTP ID DSNKSZwYAA4WjB609qBDXC/1F4NCCDe5tfdr@postini.com; Wed, 18 Feb 2009 06:15:30 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009021808161189-1461584 ; Wed, 18 Feb 2009 08:16:11 -0600 In-Reply-To: MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Wed, 18 Feb 2009 08:15:10 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 02/18/2009 08:15:15 AM, Serialize complete at 02/18/2009 08:15:15 AM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 02/18/2009 08:16:11 AM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 02/18/2009 08:16:26 AM, Serialize complete at 02/18/2009 08:16:26 AM Content-Type: multipart/alternative; boundary="=_alternative 004E4B5186257561_=" Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] New Text for the Charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 14:15:19 -0000 This is a multipart message in MIME format. --=_alternative 004E4B5186257561_= Content-Type: text/plain; charset="US-ASCII" Multicast (actually broadcast) is a definite requirement in the commercial sector. We use it for on-line discovery and binding to devices and objects. "Dearlove, Christopher (UK)" Sent by: roll-bounces@ietf.org 02/18/2009 04:24 AM To "JP Vasseur" , "ROLL WG" cc Subject Re: [Roll] New Text for the Charter > With all agreed changes ... I'm not sure if this is too late or not. If it isn't too late, here's my one comment. If it is, then OK, not in the charter, but do you see it as (a), (b) or (c)? Apart from timescale questions, the only issue I see, which others have commented on, is that one of the five distinguishing characteristics is that simple unicast flows are not typical, but nothing is then said about this in the work items. I think that the work items should clearly indicate whether (a) unicast only [but that disagrees with the characteristics], (b) unicast and multicast [significantly more work, and is this a single routing protocol, as in the plan, or not?], or (c) determining whether multicast is required is part of the work [but that's not really consistent with the plan as written]. -- Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 004E4B5186257561_= Content-Type: text/html; charset="US-ASCII"
Multicast  (actually broadcast) is a definite requirement in the commercial sector.  We use it for on-line discovery and binding to devices and objects.




"Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com>
Sent by: roll-bounces@ietf.org

02/18/2009 04:24 AM

To
"JP Vasseur" <jvasseur@cisco.com>, "ROLL WG" <roll@ietf.org>
cc
Subject
Re: [Roll] New Text for the Charter






> With all agreed changes ...

I'm not sure if this is too late or not. If it isn't too late,
here's my one comment. If it is, then OK, not in the charter,
but do you see it as (a), (b) or (c)?


Apart from timescale questions, the only issue I see, which
others have commented on, is that one of the five distinguishing
characteristics is that simple unicast flows are not typical,
but nothing is then said about this in the work items.

I think that the work items should clearly indicate whether
(a) unicast only [but that disagrees with the characteristics],
(b) unicast and multicast [significantly more work, and is this
a single routing protocol, as in the plan, or not?], or
(c) determining whether multicast is required is part of
the work [but that's not really consistent with the plan
as written].


--
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 004E4B5186257561_=-- From ietf@thomasclausen.org Wed Feb 18 07:15:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9F933A6D29 for ; Wed, 18 Feb 2009 07:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9loBrg3H2+o for ; Wed, 18 Feb 2009 07:15:41 -0800 (PST) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id 68B413A69D7 for ; Wed, 18 Feb 2009 07:15:41 -0800 (PST) Received: from aste-genev-bois-153-1-9-122.w83-112.abo.wanadoo.fr ([83.112.71.122] helo=[192.168.147.109]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LZo9N-000NvS-29; Wed, 18 Feb 2009 15:15:49 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 83.112.71.122 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/PNaAcfqvr43bimVCha33C In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: multipart/alternative; boundary=Apple-Mail-2--1034998126 Message-Id: From: Thomas Heide Clausen Date: Wed, 18 Feb 2009 16:17:19 +0100 To: Jerald.P.Martocci@jci.com X-Mailer: Apple Mail (2.753.1) Cc: ROLL WG Subject: Re: [Roll] New Text for the Charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 15:15:42 -0000 --Apple-Mail-2--1034998126 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Chris, Jerald, you both bring up an important question that I hadn't fully realized: to which extend is the output of ROLL going to be an unicast routing protocol? Multicast routing protocol? Multicast transport protocol? Something else? All or some of the above? Neither? In one protocol? I think that the charter might want to be a bit more specific on this matter. I'd think that if ROLL wants to produce a single protocol doing both uni- and multicast routing, then this should be spelled out explicitly in the charter. If ROLL wants to produce both an unicast routing protocol and a multicast routing protocol, then this also should be spelled out explicitly in the charter. (( This is in a way linked to the survey I-D draft-ietf-roll- protocols-survey, which evaluates unicast routing protocols and mechanisms only, with no mention of multicast or broadcast capabilities. If broad/multicast is such a definite requirement, then it might have been easier to dismiss all unicast routing protocols by stating that "they ain't doing multicasting", i.e. on functional grounds. )) Cheers, Thomas On Feb 18, 2009, at 15:15 PM, Jerald.P.Martocci@jci.com wrote: > > Multicast (actually broadcast) is a definite requirement in the > commercial sector. We use it for on-line discovery and binding to > devices and objects. > > > > > "Dearlove, Christopher (UK)" > Sent by: roll-bounces@ietf.org > 02/18/2009 04:24 AM > > To > "JP Vasseur" , "ROLL WG" > cc > Subject > Re: [Roll] New Text for the Charter > > > > > > > > With all agreed changes ... > > I'm not sure if this is too late or not. If it isn't too late, > here's my one comment. If it is, then OK, not in the charter, > but do you see it as (a), (b) or (c)? > > > Apart from timescale questions, the only issue I see, which > others have commented on, is that one of the five distinguishing > characteristics is that simple unicast flows are not typical, > but nothing is then said about this in the work items. > > I think that the work items should clearly indicate whether > (a) unicast only [but that disagrees with the characteristics], > (b) unicast and multicast [significantly more work, and is this > a single routing protocol, as in the plan, or not?], or > (c) determining whether multicast is required is part of > the work [but that's not really consistent with the plan > as written]. > > > -- > Christopher Dearlove > Technology Leader, Communications Group > Networks, Security and Information Systems Department > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 Fax: +44 1245 242124 > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, > Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > 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 --Apple-Mail-2--1034998126 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Chris, Jerald, =A0you both bring up an important question that I hadn't = fully realized: to which extend is the output of ROLL going to be an = unicast routing protocol? Multicast routing protocol? Multicast = transport protocol? Something else? All or some of the above? Neither? = In one protocol?

I think that the charter might want = to be a bit more specific on this = matter.

I'd think that if ROLL wants to = produce a single protocol doing both uni- and multicast routing, then = this should be spelled out explicitly in the charter. If ROLL wants to = produce both an unicast routing protocol and a multicast routing = protocol, then this also should be spelled out explicitly in the = charter.

(( This is in a way linked to the = survey I-D=A0draft-ietf-roll-protocols-survey, which evaluates unicast = routing protocols and mechanisms only, with no mention of multicast or = broadcast capabilities. If broad/multicast is such a definite = requirement, then it might have been easier to dismiss all unicast = routing protocols by stating that "they ain't doing multicasting", i.e. = on functional grounds. = ))

Cheers,

Thomas
<= div>

On Feb 18, 2009, at 15:15 PM, Jerald.P.Martocci@jci.com = wrote:


Multicast = =A0(actually broadcast) is a definite requirement in the commercial = sector. =A0We use it for on-line discovery and binding to devices and = objects.




=
"Dearlove, Christopher (UK)" <chris.dearlove@baesystems.co= m>
Sent by: roll-bounces@ietf.org

<= font size=3D"1" face=3D"sans-serif">02/18/2009 04:24 AM =

To
"JP Vasseur" <jvasseur@cisco.com>, "ROLL WG" = <roll@ietf.org> =
cc
Subject
Re: [Roll] New Text for the = Charter

=




> = With all agreed changes ...

I'm not sure if this is too late or = not. If it isn't too late,
here's my one comment. If it is, then OK, = not in the charter,
but do you see it as (a), (b) or (c)?

=
Apart from timescale questions, the only issue I see, which
= others have commented on, is that one of the five distinguishing
= characteristics is that simple unicast flows are not typical,
but = nothing is then said about this in the work items.

I think that = the work items should clearly indicate whether
(a) unicast only [but = that disagrees with the characteristics],
(b) unicast and multicast = [significantly more work, and is this
a single routing protocol, as = in the plan, or not?], or
(c) determining whether multicast is = required is part of
the work [but that's not really consistent with = the plan
as written].


--
Christopher Dearlove
= Technology Leader, Communications Group
Networks, Security and = Information Systems Department
BAE Systems Advanced Technology = Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, = UK
Tel: +44 1245 242194 =A0Fax: +44 1245 242124

BAE Systems = (Operations) Limited
Registered Office: Warwick House, PO Box = 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, = UK
Registered in England & Wales No: 1996687

= ********************************************************************
= This email and any attachments are confidential to the intended
= recipient and may also be privileged. If you are not the intended
= recipient please delete it from your system and notify the sender.
= You should not copy it or use it for any purpose nor disclose or
= distribute its contents to any other person.
= ********************************************************************
=
_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll
Roll mailing list
=

= --Apple-Mail-2--1034998126-- From chris.dearlove@baesystems.com Wed Feb 18 08:22:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91FDC3A69D7 for ; Wed, 18 Feb 2009 08:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KOYfOWbFm2e for ; Wed, 18 Feb 2009 08:22:17 -0800 (PST) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 005693A68C5 for ; Wed, 18 Feb 2009 08:22:16 -0800 (PST) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n1IGMRX2012473 for ; Wed, 18 Feb 2009 16:22:27 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n1IGMRaD017555 for ; Wed, 18 Feb 2009 16:22:27 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 18 Feb 2009 16:22:12 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 18 Feb 2009 16:22:26 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C991E5.15EDBB57" Date: Wed, 18 Feb 2009 16:22:25 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] New Text for the Charter Thread-Index: AcmR29Na/bVocg05SQiGW1/QtVRh9wACLLqQ References: From: "Dearlove, Christopher (UK)" To: "Thomas Heide Clausen" , X-OriginalArrivalTime: 18 Feb 2009 16:22:26.0772 (UTC) FILETIME=[167ED940:01C991E5] Cc: ROLL WG Subject: Re: [Roll] New Text for the Charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 16:22:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C991E5.15EDBB57 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In my (a) to (c) I didn't consider multicast only as an option. Logically I should have done, though I doubt it will be the case. There are some uses for unicast. --=20 Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 =20 ________________________________ From: Thomas Heide Clausen [mailto:ietf@thomasclausen.org]=20 Sent: 18 February 2009 15:17 To: Jerald.P.Martocci@jci.com Cc: Dearlove, Christopher (UK); ROLL WG Subject: Re: [Roll] New Text for the Charter *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 =09 Chris, Jerald, you both bring up an important question that I hadn't fully realized: to which extend is the output of ROLL going to be an unicast routing protocol? Multicast routing protocol? Multicast transport protocol? Something else? All or some of the above? Neither? In one protocol?=20 I think that the charter might want to be a bit more specific on this matter. I'd think that if ROLL wants to produce a single protocol doing both uni- and multicast routing, then this should be spelled out explicitly in the charter. If ROLL wants to produce both an unicast routing protocol and a multicast routing protocol, then this also should be spelled out explicitly in the charter. (( This is in a way linked to the survey I-D draft-ietf-roll-protocols-survey, which evaluates unicast routing protocols and mechanisms only, with no mention of multicast or broadcast capabilities. If broad/multicast is such a definite requirement, then it might have been easier to dismiss all unicast routing protocols by stating that "they ain't doing multicasting", i.e. on functional grounds. )) Cheers, Thomas On Feb 18, 2009, at 15:15 PM, Jerald.P.Martocci@jci.com wrote: Multicast (actually broadcast) is a definite requirement in the commercial sector. We use it for on-line discovery and binding to devices and objects.=20 =09 =09 =09 =09 =09 "Dearlove, Christopher (UK)" =20 Sent by: roll-bounces@ietf.org=20 02/18/2009 04:24 AM=20 To "JP Vasseur" , "ROLL WG" =09 cc =09 Subject Re: [Roll] New Text for the Charter=09 =09 =09 > With all agreed changes ... =09 I'm not sure if this is too late or not. If it isn't too late, here's my one comment. If it is, then OK, not in the charter, but do you see it as (a), (b) or (c)? =09 =09 Apart from timescale questions, the only issue I see, which others have commented on, is that one of the five distinguishing characteristics is that simple unicast flows are not typical, but nothing is then said about this in the work items. =09 I think that the work items should clearly indicate whether (a) unicast only [but that disagrees with the characteristics], (b) unicast and multicast [significantly more work, and is this a single routing protocol, as in the plan, or not?], or (c) determining whether multicast is required is part of the work [but that's not really consistent with the plan as written]. =09 =09 --=20 Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 =09 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 =09 =09 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. =09 ******************************************************************** =09 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =09 =09 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------_=_NextPart_001_01C991E5.15EDBB57 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
In my (a) = to (c) I didn't=20 consider multicast only as an option.
Logically I = should have=20 done, though I doubt it will be the case.
There are = some uses for=20 unicast.

-- =
Christopher=20 Dearlove
Technology Leader, Communications Group
Networks, = Security and=20 Information Systems Department
BAE Systems Advanced Technology = Centre
West=20 Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 = 1245=20 242194  Fax: +44 1245 242124

BAE Systems (Operations)=20 Limited
Registered Office: Warwick House, PO Box 87,
Farnborough = Aerospace=20 Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & = Wales=20 No: 1996687

 

From: Thomas Heide Clausen=20 [mailto:ietf@thomasclausen.org]
Sent: 18 February 2009=20 15:17
To: Jerald.P.Martocci@jci.com
Cc: Dearlove,=20 Christopher (UK); ROLL WG
Subject: Re: [Roll] New Text for the = Charter

*** WARNING ***

This mail has = originated=20 outside your organization,
either from an external partner or = the=20 Global Internet.
Keep this in mind if you answer this message. =
Chris, Jerald,  you both bring up = an=20 important question that I hadn't fully realized: to which extend is the = output=20 of ROLL going to be an unicast routing protocol? Multicast routing = protocol?=20 Multicast transport protocol? Something else? All or some of the above? = Neither?=20 In one protocol?

I think that the charter might want to be a bit more specific on = this=20 matter.

I'd think that if ROLL wants to produce a single protocol doing = both uni-=20 and multicast routing, then this should be spelled out explicitly in the = charter. If ROLL wants to produce both an unicast routing protocol and a = multicast routing protocol, then this also should be spelled out = explicitly in=20 the charter.

(( This is in a way linked to the survey=20 I-D draft-ietf-roll-protocols-survey, which evaluates unicast = routing=20 protocols and mechanisms only, with no mention of multicast or broadcast = capabilities. If broad/multicast is such a definite requirement, then it = might=20 have been easier to dismiss all unicast routing protocols by stating = that "they=20 ain't doing multicasting", i.e. on functional grounds. ))

Cheers,

Thomas


On Feb 18, 2009, at 15:15 PM, Jerald.P.Martocci@jci.com=20 wrote:


Multicast =  (actually broadcast) is a definite requirement in the commercial = sector.=20  We use it for on-line discovery and binding to devices and=20 objects.




"Dearlove, = Christopher=20 (UK)" <chris.dearlove@baesystems.c= om>=20
Sent by: roll-bounces@ietf.org

02/18/2009 04:24 AM =

To
 "JP Vasseur" <jvasseur@cisco.com>, "ROLL=20 WG" <roll@ietf.org> =
cc
Subject
 Re: [Roll] New Text for = the=20 Charter

=




<= FONT=20 size=3D2>
> With all agreed changes ...

I'm not sure = if this is=20 too late or not. If it isn't too late,
here's my one comment. If it = is,=20 then OK, not in the charter,
but do you see it as (a), (b) or=20 (c)?


Apart from timescale questions, the only issue I see,=20 which
others have commented on, is that one of the five=20 distinguishing
characteristics is that simple unicast flows are not = typical,
but nothing is then said about this in the work = items.

I=20 think that the work items should clearly indicate whether
(a) = unicast only=20 [but that disagrees with the characteristics],
(b) unicast and = multicast=20 [significantly more work, and is this
a single routing protocol, as = in the=20 plan, or not?], or
(c) determining whether multicast is required is = part=20 of
the work [but that's not really consistent with the plan
as=20 written].


--
Christopher Dearlove
Technology Leader, = Communications Group
Networks, Security and Information Systems=20 Department
BAE Systems Advanced Technology Centre
West = Hanningfield=20 Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 =  Fax:=20 +44 1245 242124

BAE Systems (Operations) Limited
Registered = Office:=20 Warwick House, PO Box 87,
Farnborough Aerospace Centre, = Farnborough, Hants,=20 GU14 6YU, UK
Registered in England & Wales No:=20 = 1996687

**********************************************************= **********
This=20 email and any attachments are confidential to the = intended
recipient and=20 may also be privileged. If you are not the intended
recipient = please delete=20 it from your system and notify the sender.
You should not copy it = or use it=20 for any purpose nor disclose or
distribute its contents to any = other=20 = person.
**************************************************************= ******

_______________________________________________
Roll=20 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

= ------_=_NextPart_001_01C991E5.15EDBB57-- From pal@cs.stanford.edu Wed Feb 18 09:56:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91C813A6A5E for ; Wed, 18 Feb 2009 09:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVnyNir9w4FF for ; Wed, 18 Feb 2009 09:56:25 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id D048D3A693F for ; Wed, 18 Feb 2009 09:56:25 -0800 (PST) Received: from dnab42217a.stanford.edu ([171.66.33.122]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1LZqez-00056B-TH; Wed, 18 Feb 2009 09:56:38 -0800 Message-Id: <7D002912-FC79-437A-86EF-2CAB60F21054@cs.stanford.edu> From: Philip Levis To: Thomas Heide Clausen In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 18 Feb 2009 09:56:32 -0800 References: X-Mailer: Apple Mail (2.930.3) X-Scan-Signature: 8e086a056c9d4443aaf3b84243aabc30 Cc: ROLL WG Subject: Re: [Roll] New Text for the Charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 17:56:26 -0000 Comment follows. On Feb 18, 2009, at 7:17 AM, Thomas Heide Clausen wrote: > Chris, Jerald, you both bring up an important question that I > hadn't fully realized: to which extend is the output of ROLL going > to be an unicast routing protocol? Multicast routing protocol? > Multicast transport protocol? Something else? All or some of the > above? Neither? In one protocol? > > I think that the charter might want to be a bit more specific on > this matter. > > I'd think that if ROLL wants to produce a single protocol doing both > uni- and multicast routing, then this should be spelled out > explicitly in the charter. If ROLL wants to produce both an unicast > routing protocol and a multicast routing protocol, then this also > should be spelled out explicitly in the charter. Thomas, I have to disagree on this point. I think that this decision, in and of itself, is protocol design. It would be a real mistake to bind the WG to one approach or the other without any examination of the tradeoffs of each approach. But that examination is what the re- chartering is for. For example, if the charter says "one protocol" but then this one protocol becomes clearly inferior to an approach with two protocols, we're in a bind. If the charter says "two protocols" but then there's a protocol that handles both seamlessly (and so has simpler code), we're in a bind. Phil From IETF@ThomasClausen.org Wed Feb 18 10:16:11 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 624A13A6999 for ; Wed, 18 Feb 2009 10:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EINCGNgmGOb for ; Wed, 18 Feb 2009 10:16:10 -0800 (PST) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id 8FE243A693F for ; Wed, 18 Feb 2009 10:16:10 -0800 (PST) Received: from aste-genev-bois-153-1-9-122.w83-112.abo.wanadoo.fr ([83.112.71.122] helo=[192.168.147.109]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LZqy6-00009V-At; Wed, 18 Feb 2009 18:16:22 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 83.112.71.122 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+BT3y8SNBYAIg8Ia0xG52O In-Reply-To: <7D002912-FC79-437A-86EF-2CAB60F21054@cs.stanford.edu> References: <7D002912-FC79-437A-86EF-2CAB60F21054@cs.stanford.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Thomas Heide Clausen Date: Wed, 18 Feb 2009 19:17:58 +0100 To: Philip Levis X-Mailer: Apple Mail (2.753.1) Cc: ROLL WG Subject: Re: [Roll] New Text for the Charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 18:16:11 -0000 On Feb 18, 2009, at 18:56 PM, Philip Levis wrote: > Comment follows. > > On Feb 18, 2009, at 7:17 AM, Thomas Heide Clausen wrote: > >> Chris, Jerald, you both bring up an important question that I >> hadn't fully realized: to which extend is the output of ROLL going >> to be an unicast routing protocol? Multicast routing protocol? >> Multicast transport protocol? Something else? All or some of the >> above? Neither? In one protocol? >> >> I think that the charter might want to be a bit more specific on >> this matter. >> >> I'd think that if ROLL wants to produce a single protocol doing >> both uni- and multicast routing, then this should be spelled out >> explicitly in the charter. If ROLL wants to produce both an >> unicast routing protocol and a multicast routing protocol, then >> this also should be spelled out explicitly in the charter. > > Thomas, I have to disagree on this point. I think that this > decision, in and of itself, is protocol design. It would be a real > mistake to bind the WG to one approach or the other without any > examination of the tradeoffs of each approach. But that examination > is what the re-chartering is for. > > For example, if the charter says "one protocol" but then this one > protocol becomes clearly inferior to an approach with two > protocols, we're in a bind. If the charter says "two protocols" but > then there's a protocol that handles both seamlessly (and so has > simpler code), we're in a bind. > > Phil Phil, I am actually not disagreeing with what you are saying regarding the protocol(s) that will result. However if the ROLL needs a solution for both unicast and multicast, then this should be stated clearly. As it is, it reads simply: > - Typical traffic patterns are not simply unicast flows, Which I think is a bit too obscure a way of stating that the WG will be working on both unicast and multicast solutions. Thomas From pal@cs.stanford.edu Wed Feb 18 10:26:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47CE53A6959 for ; Wed, 18 Feb 2009 10:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXu3JKJE09eU for ; Wed, 18 Feb 2009 10:26:48 -0800 (PST) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 5CE0E3A6917 for ; Wed, 18 Feb 2009 10:26:46 -0800 (PST) Received: from dnab42217a.stanford.edu ([171.66.33.122]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1LZr8M-0002yi-Fg; Wed, 18 Feb 2009 10:26:58 -0800 Message-Id: <52387448-346C-4324-8A70-104D7658C695@cs.stanford.edu> From: Philip Levis To: Thomas Heide Clausen In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 18 Feb 2009 10:26:58 -0800 References: <7D002912-FC79-437A-86EF-2CAB60F21054@cs.stanford.edu> X-Mailer: Apple Mail (2.930.3) X-Scan-Signature: fb418a055a615a79fddacbea7bf2a8e8 Cc: ROLL WG Subject: Re: [Roll] New Text for the Charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 18:26:49 -0000 Comments inline. On Feb 18, 2009, at 10:17 AM, Thomas Heide Clausen wrote: > > On Feb 18, 2009, at 18:56 PM, Philip Levis wrote: > >> Comment follows. >> >> On Feb 18, 2009, at 7:17 AM, Thomas Heide Clausen wrote: >> >>> Chris, Jerald, you both bring up an important question that I >>> hadn't fully realized: to which extend is the output of ROLL going >>> to be an unicast routing protocol? Multicast routing protocol? >>> Multicast transport protocol? Something else? All or some of the >>> above? Neither? In one protocol? >>> >>> I think that the charter might want to be a bit more specific on >>> this matter. >>> >>> I'd think that if ROLL wants to produce a single protocol doing >>> both uni- and multicast routing, then this should be spelled out >>> explicitly in the charter. If ROLL wants to produce both an >>> unicast routing protocol and a multicast routing protocol, then >>> this also should be spelled out explicitly in the charter. >> >> Thomas, I have to disagree on this point. I think that this >> decision, in and of itself, is protocol design. It would be a real >> mistake to bind the WG to one approach or the other without any >> examination of the tradeoffs of each approach. But that examination >> is what the re-chartering is for. >> >> For example, if the charter says "one protocol" but then this one >> protocol becomes clearly inferior to an approach with two >> protocols, we're in a bind. If the charter says "two protocols" but >> then there's a protocol that handles both seamlessly (and so has >> simpler code), we're in a bind. >> >> Phil > > Phil, I am actually not disagreeing with what you are saying > regarding the protocol(s) that will result. However if the ROLL > needs a solution for both unicast and multicast, then this should be > stated clearly. As it is, it reads simply: Great! > > >> - Typical traffic patterns are not simply unicast flows, > > > Which I think is a bit too obscure a way of stating that the WG will > be working on both unicast and multicast solutions. I thought the new text says - Typical traffic patterns are not simply unicast flows (e.g. in some environments most if not all traffic can be point to multipoint) so it articulates this. How do you think it could be improved? I think it might be important to separate the notion of "point to multipoint" from "multicast." Generally, IP mulitcast is handled by a node joining a multicast group. That is, the set of recipients is defined by which recipients join the group. In contrast, you'll notice that in some application docs the requirements are a bit different: a sender wants to deliver a message to a group of nodes, where the group is defined by the sender. Its seems very likely that multicast is a good way to achieve this, but we're then specifying the solution, rather than the requirement. Does that make sense? It's a very fine line, trying to crisply define what the WG needs to accomplish without defining too tightly and excluding mechanisms that very useful. Phil From jvasseur@cisco.com Wed Feb 18 10:40:28 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1C253A69AA for ; Wed, 18 Feb 2009 10:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.579 X-Spam-Level: X-Spam-Status: No, score=-10.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clZTc3W7B+ja for ; Wed, 18 Feb 2009 10:40:22 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 802313A6917 for ; Wed, 18 Feb 2009 10:40:21 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,230,1233532800"; d="scan'208";a="34182818" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 18 Feb 2009 18:40:32 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1IIeWOx031435; Wed, 18 Feb 2009 19:40:32 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1IIeW4B018361; Wed, 18 Feb 2009 18:40:32 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Feb 2009 19:40:32 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Feb 2009 19:40:31 +0100 Message-Id: <699FB9C8-2625-4EBD-ABE1-EFBBAF57CDD6@cisco.com> From: JP Vasseur To: Philip Levis In-Reply-To: <52387448-346C-4324-8A70-104D7658C695@cs.stanford.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 18 Feb 2009 19:40:31 +0100 References: <7D002912-FC79-437A-86EF-2CAB60F21054@cs.stanford.edu> <52387448-346C-4324-8A70-104D7658C695@cs.stanford.edu> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 18 Feb 2009 18:40:31.0927 (UTC) FILETIME=[60D52C70:01C991F8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3512; t=1234982432; x=1235846432; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20New=20Text=20for=20the=20Chart er |Sender:=20; bh=ARMCWPx8fX0vj/ZLO0RkwKlQeZS6/O1NbzuIo55qh0U=; b=UtIHK4yQ0k8OkYX0jSq46Wo/7aBAczc0eOVgJVg1aSc8sDgS6dmsEpnuRA 7oQPZHwu9e8fmYJ3M3KOc0ZFxo0i6HhIg/eubiHkq/zKEGgQsZPYWTD8FIqz EqWr96Ov47; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG , Thomas Heide Clausen Subject: Re: [Roll] New Text for the Charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 18:40:28 -0000 On Feb 18, 2009, at 7:26 PM, Philip Levis wrote: > Comments inline. > > On Feb 18, 2009, at 10:17 AM, Thomas Heide Clausen wrote: > >> >> On Feb 18, 2009, at 18:56 PM, Philip Levis wrote: >> >>> Comment follows. >>> >>> On Feb 18, 2009, at 7:17 AM, Thomas Heide Clausen wrote: >>> >>>> Chris, Jerald, you both bring up an important question that I >>>> hadn't fully realized: to which extend is the output of ROLL >>>> going to be an unicast routing protocol? Multicast routing >>>> protocol? Multicast transport protocol? Something else? All or >>>> some of the above? Neither? In one protocol? >>>> >>>> I think that the charter might want to be a bit more specific on >>>> this matter. >>>> >>>> I'd think that if ROLL wants to produce a single protocol doing >>>> both uni- and multicast routing, then this should be spelled out >>>> explicitly in the charter. If ROLL wants to produce both an >>>> unicast routing protocol and a multicast routing protocol, then >>>> this also should be spelled out explicitly in the charter. >>> >>> Thomas, I have to disagree on this point. I think that this >>> decision, in and of itself, is protocol design. It would be a real >>> mistake to bind the WG to one approach or the other without any >>> examination of the tradeoffs of each approach. But that >>> examination is what the re-chartering is for. >>> >>> For example, if the charter says "one protocol" but then this one >>> protocol becomes clearly inferior to an approach with two >>> protocols, we're in a bind. If the charter says "two protocols" >>> but then there's a protocol that handles both seamlessly (and so >>> has simpler code), we're in a bind. >>> >>> Phil >> >> Phil, I am actually not disagreeing with what you are saying >> regarding the protocol(s) that will result. However if the ROLL >> needs a solution for both unicast and multicast, then this should >> be stated clearly. As it is, it reads simply: > > Great! > >> >> >>> - Typical traffic patterns are not simply unicast flows, >> >> >> Which I think is a bit too obscure a way of stating that the WG >> will be working on both unicast and multicast solutions. > > I thought the new text says > > - Typical traffic patterns are not simply unicast flows (e.g. > in some environments most if not all traffic can be point to > multipoint) > > so it articulates this. How do you think it could be improved? > > I think it might be important to separate the notion of "point to > multipoint" from "multicast." Generally, IP mulitcast is handled by > a node joining a multicast group. That is, the set of recipients is > defined by which recipients join the group. In contrast, you'll > notice that in some application docs the requirements are a bit > different: a sender wants to deliver a message to a group of nodes, > where the group is defined by the sender. Its seems very likely that > multicast is a good way to achieve this, but we're then specifying > the solution, rather than the requirement. > You stole my words .. fully agreeing. > Does that make sense? It's a very fine line, trying to crisply > define what the WG needs to accomplish without defining too tightly > and excluding mechanisms that very useful. > > Phil > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From achandra@cisco.com Wed Feb 18 21:48:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B36B3A699C for ; Wed, 18 Feb 2009 21:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtHE8dmbMofy for ; Wed, 18 Feb 2009 21:48:15 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 6E92F3A696C for ; Wed, 18 Feb 2009 21:48:15 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,233,1233532800"; d="scan'208";a="133299336" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 19 Feb 2009 05:48:28 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1J5mSHr019575 for ; Wed, 18 Feb 2009 21:48:28 -0800 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n1J5mSqx002647 for ; Thu, 19 Feb 2009 05:48:28 GMT Received: (from achandra@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA02792; Wed, 18 Feb 2009 21:47:07 -0800 (PST) Date: Wed, 18 Feb 2009 21:47:07 -0800 From: Chandrashekhar Appanna To: JP Vasseur Message-ID: <20090219054707.GA1158@cisco.com> References: <21EE679D-9A5D-4655-82B1-9A5E77ECB82A@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21EE679D-9A5D-4655-82B1-9A5E77ECB82A@cisco.com> User-Agent: Mutt/1.4i DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6408; t=1235022508; x=1235886508; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=achandra@cisco.com; z=From:=20Chandrashekhar=20Appanna=20 |Subject:=20Re=3A=20[Roll]=20New=20Text=20for=20the=20Chart er |Sender:=20; bh=fw8uzrW58hv3X+RZTBelNMqCGsgPUIKZTGmdPn316sc=; b=RYrHwGCgetqFogo3KeRK5IZvhKA7X/rY/tMaavH4eyzYm7fUNxp+KiyVvj EyhkLXCfgtKSBzrdFd3bVsPtrX8MU52iIg3jwJ/qf/0oV5HSYcIkdpxqL/R+ 88ZRP7tDzj; Authentication-Results: sj-dkim-2; header.From=achandra@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: ROLL WG Subject: Re: [Roll] New Text for the Charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 05:48:17 -0000 This looks good.. Another point - Given all the discussions around the 'wording' we should keep in mind that as the work progress things will get fine tuned (happens in all working groups). So we should move on to the next stage as quickly as we can. Chandra. On Mon, Feb 16, 2009 at 01:32:07PM +0100, JP Vasseur wrote: > With all agreed changes ... > > > Description of Working Group: > 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 energy saving, > - Typical traffic patterns are not simply unicast flows (e.g. in > some environments 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. As shown in a protocol survey existing routing protocols > (in their current form) such as OSPF, IS-IS, AODV, and OLSR, do not > meet 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), assets 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. > > > > 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 protocols 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: In light of the application specific routing > requirements, the Working Group will either specify a new protocol and/ > or will select an existing routing protocol (with the appropriate > extensions in cooperation with the relevant Working Group). > - Documentation of applicability statement of ROLL routing protocols. > Goals and Milestones: > Done Submit Routing requirements for Industrial applications to the > IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Connected Home networks > applications to the IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Building applications to the > IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Urban networks applications to > the IESG to be considered as an Informational RFC. > July 2009 Submit Routing metrics for LLNs document to the IESG to > be considered as a Proposed Standard. > * Feb 2009 Submit Protocol Survey to the IESG to be considered as an > Informational RFC. > April 2009 Submit Security Framework to the IESG to be considered as > an Informational RFC > May 2009 Submit the Routing for LLNs Architecture document to the > IESG as an Informational RFC. > July 2009 Submit first draft of ROLL routing protocol specification > as Proposed Standard. > Nov 2009 Submit first draft of the MIB module of the ROLL routing > protocol specification. > Feb 2010 Submit the ROLL routing protocol specification to the > IESG as Proposed Standard. > March 2010 Submit the MIB module of the ROLL routing protocol > specification to the IESG as Proposed Standard. > April 2010 Evaluate WG progress, recharter or close. > > PS: I marked * the Milestones that will be "This Week" and before > submitting to the IESG for re-chartering. > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From chris.dearlove@baesystems.com Thu Feb 19 02:15:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D5813A6A5D for ; Thu, 19 Feb 2009 02:15:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7B0mErfsbj7 for ; Thu, 19 Feb 2009 02:15:26 -0800 (PST) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id 3DF023A69FD for ; Thu, 19 Feb 2009 02:15:24 -0800 (PST) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n1JAFX5G023277 for ; Thu, 19 Feb 2009 10:15:33 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n1JAFXXA026371 for ; Thu, 19 Feb 2009 10:15:33 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Thu, 19 Feb 2009 10:15:17 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Thu, 19 Feb 2009 10:15:29 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Feb 2009 10:15:28 -0000 Message-ID: In-Reply-To: <52387448-346C-4324-8A70-104D7658C695@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] New Text for the Charter Thread-Index: AcmR9oEx+AbzAPNBQ3iNwNQE52BKUwAhBMFg References: <7D002912-FC79-437A-86EF-2CAB60F21054@cs.stanford.edu> <52387448-346C-4324-8A70-104D7658C695@cs.stanford.edu> From: "Dearlove, Christopher (UK)" To: "Philip Levis" , "Thomas Heide Clausen" X-OriginalArrivalTime: 19 Feb 2009 10:15:29.0959 (UTC) FILETIME=[FDDD8B70:01C9927A] Cc: ROLL WG Subject: Re: [Roll] New Text for the Charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 10:15:27 -0000 > I thought the new text says > > - Typical traffic patterns are not simply unicast flows (e.g. in > some environments most if not all traffic can be point to multipoint) > > so it articulates this. How do you think it could be improved? By saying what you plan to do in the Work Items. This text is in the description of the group, and isn't at all clear that it specifies what the group will do. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From pthubert@cisco.com Thu Feb 19 03:20:50 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 720BE28C194 for ; Thu, 19 Feb 2009 03:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.979 X-Spam-Level: X-Spam-Status: No, score=-9.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngewGUyO+AOH for ; Thu, 19 Feb 2009 03:20:49 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B91883A695B for ; Thu, 19 Feb 2009 03:20:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,234,1233532800"; d="scan'208";a="34245047" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 Feb 2009 11:20:59 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1JBL0uB022407; Thu, 19 Feb 2009 12:21:00 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1JBKx75026348; Thu, 19 Feb 2009 11:20:59 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Feb 2009 12:20:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Feb 2009 12:20:45 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC06FD49DA@xmb-ams-337.emea.cisco.com> In-Reply-To: <699FB9C8-2625-4EBD-ABE1-EFBBAF57CDD6@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] New Text for the Charter Thread-Index: AcmR+Gr2N64MIYmxTn2eIQG6bQtyAQAgoylA References: <7D002912-FC79-437A-86EF-2CAB60F21054@cs.stanford.edu><52387448-346C-4324-8A70-104D7658C695@cs.stanford.edu> <699FB9C8-2625-4EBD-ABE1-EFBBAF57CDD6@cisco.com> From: "Pascal Thubert (pthubert)" To: "JP Vasseur (jvasseur)" , "Philip Levis" X-OriginalArrivalTime: 19 Feb 2009 11:20:59.0844 (UTC) FILETIME=[24426840:01C99284] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7495; t=1235042460; x=1235906460; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20New=20Text=20for=20the=20Chart er |Sender:=20; bh=jUywoZ9zOS0nwyCR5+JfOEPZ+vSnC3hOvmuW97XyaIU=; b=LMz/HVqp7HRzeB7dauWPMltUuGrNdAPiHQZYvodVKiencr8RlGm+BLjU5a +dCCoqhYoDqJblK2dRnt7H5qUvflG7nSMjcXgjLVqm5spI5Ek+3i5bUynR6L FZ23qhXVAt; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG , Thomas Heide Clausen Subject: Re: [Roll] New Text for the Charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 11:20:50 -0000 Hi: First I wish to concur with Phil and JP that we need to avoid the = confusion between multipoint and multicast. I'll be elaborating a little = bit on multicast and IPv6. Link scope multicast (FF02:...) ------------------------------- IPv6 relies on link scope multicast capabilities for a number of = activities, such as ND. IPv6 does not expect that a Link scope multicast = will ever be routed / relayed at layer 3. For instance ND actively = checks against a change in the hop limit that is set to 255 for that = purpose. Hello protocol uses FF02::5 with the expectation that only = direct connectivity shows up. Etc... Now the type of network we're looking at derives largely from the NBMA = model, and NBMA does not provide native link layer multicast capability; = moreover, in the P2MP case, FF02 would need routing and relaying to span = the whole network, which is incompatible with how link scoped multicast = is used in the first place. So for the purpose of IPv6 operation, a = number of approaches have been proposed to emulate multicast and enable = transparent IPv6 operations. RFCs 2491/2022/2332: This is the generic model for large NBMA. Mars (RFC = 2022) is an example of convergence protocol to emulate multicast = transparently to ND and others. RFC 3122: A new form of ND is introduced that does not need a link = spanning multicast service. Can be coupled with the above id DAD is = required. Secured and generalized in draft-thubert-3122bis. 6LoWPAN: A subcase of NBMA with a backbone link where FF02:: multicast = actually works. An ND extension enables registration over the NBMA edge = and proxy operation over the backbone. That same registration enables a = service similar to MARS for the purpose of NS/DAD, but in a lot simpler = and less generic fashion. For those link scope multicast that could not = be avoided, such as some RAs, Trickle optimizes the dissemination of the = information in the Low Power network. It's unclear at this point how far ROLL can reuse that art and how = efficient that would be; I certainly would not oppose to having an = additional work item to study this specific issue and produce an = informational draft. But it's not proven we have a specific problem with = link scope multicast that prevents ROLL operation either. L3 (routed) multicast, that is FF0x:... (x>2)=20 --------------------------------------------- Multicast appears in the requirements document as the way to distribute = to many small groups of nodes; seems ROLL could survive short term with = multiple P2P even though it'd be inefficient in a deep ROLL network. For all I've seen, that's mostly information and commands being pushed = from the infrastructure into the ROLL network. The way I see it, we do = not necessarily need a full fledged support of multicast, but rather a = way to distribute data coming from the outside along trees that span the = ROLL network from the network sinks. If the routing that we define = provides such trees, then the logical structure can be economically = reused for multicast distribution. MANEMO did just that, though I think = we never published the draft that detailed the mcast NINA that carried = MLD proxy registrations up the TD tree. My take is that we'll need to be creative when we define the unicast = routing to try and fulfill the multicast requirements we have for as = little additional cost as we can... But I would keep the charter as it = stands for that matter. Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = JP Vasseur (jvasseur) >Sent: mercredi 18 f=E9vrier 2009 19:41 >To: Philip Levis >Cc: ROLL WG; Thomas Heide Clausen >Subject: Re: [Roll] New Text for the Charter > > >On Feb 18, 2009, at 7:26 PM, Philip Levis wrote: > >> Comments inline. >> >> On Feb 18, 2009, at 10:17 AM, Thomas Heide Clausen wrote: >> >>> >>> On Feb 18, 2009, at 18:56 PM, Philip Levis wrote: >>> >>>> Comment follows. >>>> >>>> On Feb 18, 2009, at 7:17 AM, Thomas Heide Clausen wrote: >>>> >>>>> Chris, Jerald, you both bring up an important question that I >>>>> hadn't fully realized: to which extend is the output of ROLL >>>>> going to be an unicast routing protocol? Multicast routing >>>>> protocol? Multicast transport protocol? Something else? All or >>>>> some of the above? Neither? In one protocol? >>>>> >>>>> I think that the charter might want to be a bit more specific on >>>>> this matter. >>>>> >>>>> I'd think that if ROLL wants to produce a single protocol doing >>>>> both uni- and multicast routing, then this should be spelled out >>>>> explicitly in the charter. If ROLL wants to produce both an >>>>> unicast routing protocol and a multicast routing protocol, then >>>>> this also should be spelled out explicitly in the charter. >>>> >>>> Thomas, I have to disagree on this point. I think that this >>>> decision, in and of itself, is protocol design. It would be a real >>>> mistake to bind the WG to one approach or the other without any >>>> examination of the tradeoffs of each approach. But that >>>> examination is what the re-chartering is for. >>>> >>>> For example, if the charter says "one protocol" but then this one >>>> protocol becomes clearly inferior to an approach with two >>>> protocols, we're in a bind. If the charter says "two protocols" >>>> but then there's a protocol that handles both seamlessly (and so >>>> has simpler code), we're in a bind. >>>> >>>> Phil >>> >>> Phil, I am actually not disagreeing with what you are saying >>> regarding the protocol(s) that will result. However if the ROLL >>> needs a solution for both unicast and multicast, then this should >>> be stated clearly. As it is, it reads simply: >> >> Great! >> >>> >>> >>>> - Typical traffic patterns are not simply unicast flows, >>> >>> >>> Which I think is a bit too obscure a way of stating that the WG >>> will be working on both unicast and multicast solutions. >> >> I thought the new text says >> >> - Typical traffic patterns are not simply unicast flows (e.g. >> in some environments most if not all traffic can be point to >> multipoint) >> >> so it articulates this. How do you think it could be improved? >> >> I think it might be important to separate the notion of "point to >> multipoint" from "multicast." Generally, IP mulitcast is handled by >> a node joining a multicast group. That is, the set of recipients is >> defined by which recipients join the group. In contrast, you'll >> notice that in some application docs the requirements are a bit >> different: a sender wants to deliver a message to a group of nodes, >> where the group is defined by the sender. Its seems very likely that >> multicast is a good way to achieve this, but we're then specifying >> the solution, rather than the requirement. >> > >You stole my words .. fully agreeing. > >> Does that make sense? It's a very fine line, trying to crisply >> define what the WG needs to accomplish without defining too tightly >> and excluding mechanisms that very useful. >> >> Phil >> >> _______________________________________________ >> 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 From alexandru.petrescu@gmail.com Thu Feb 19 03:48:55 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 934A53A6A4F for ; Thu, 19 Feb 2009 03:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xTjjmGSedhh for ; Thu, 19 Feb 2009 03:48:54 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 807653A6A35 for ; Thu, 19 Feb 2009 03:48:54 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1JBn4Ya002733; Thu, 19 Feb 2009 12:49:04 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1JBn3lX012223; Thu, 19 Feb 2009 12:49:03 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n1JBn3U8011934; Thu, 19 Feb 2009 12:49:03 +0100 Message-ID: <499D472F.8020109@gmail.com> Date: Thu, 19 Feb 2009 12:49:03 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Philip Levis References: <7D002912-FC79-437A-86EF-2CAB60F21054@cs.stanford.edu> <52387448-346C-4324-8A70-104D7658C695@cs.stanford.edu> In-Reply-To: <52387448-346C-4324-8A70-104D7658C695@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG , Thomas Heide Clausen Subject: Re: [Roll] New Text for the Charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 11:48:55 -0000 Philip Levis a écrit : > Comments inline. > > On Feb 18, 2009, at 10:17 AM, Thomas Heide Clausen wrote: > >> >> On Feb 18, 2009, at 18:56 PM, Philip Levis wrote: >> >>> Comment follows. >>> >>> On Feb 18, 2009, at 7:17 AM, Thomas Heide Clausen wrote: >>> >>>> Chris, Jerald, you both bring up an important question that I >>>> hadn't fully realized: to which extend is the output of ROLL going >>>> to be an unicast routing protocol? Multicast routing protocol? >>>> Multicast transport protocol? Something else? All or some of the >>>> above? Neither? In one protocol? >>>> >>>> I think that the charter might want to be a bit more specific on >>>> this matter. >>>> >>>> I'd think that if ROLL wants to produce a single protocol doing both >>>> uni- and multicast routing, then this should be spelled out >>>> explicitly in the charter. If ROLL wants to produce both an unicast >>>> routing protocol and a multicast routing protocol, then this also >>>> should be spelled out explicitly in the charter. >>> >>> Thomas, I have to disagree on this point. I think that this decision, >>> in and of itself, is protocol design. It would be a real mistake to >>> bind the WG to one approach or the other without any examination of >>> the tradeoffs of each approach. But that examination is what the >>> re-chartering is for. >>> >>> For example, if the charter says "one protocol" but then this one >>> protocol becomes clearly inferior to an approach with two protocols, >>> we're in a bind. If the charter says "two protocols" but then there's >>> a protocol that handles both seamlessly (and so has simpler code), >>> we're in a bind. >>> >>> Phil >> >> Phil, I am actually not disagreeing with what you are saying regarding >> the protocol(s) that will result. However if the ROLL needs a solution >> for both unicast and multicast, then this should be stated clearly. As >> it is, it reads simply: > > Great! > >> >> >>> - Typical traffic patterns are not simply unicast flows, >> >> >> Which I think is a bit too obscure a way of stating that the WG will >> be working on both unicast and multicast solutions. > > I thought the new text says > > - Typical traffic patterns are not simply unicast flows (e.g. in > some environments most if not all traffic can be point to multipoint) > > so it articulates this. How do you think it could be improved? > > I think it might be important to separate the notion of "point to > multipoint" from "multicast." YEs, multicast makes me think of IP and/or link-layer multicast. Point-to-multipoint makes me think of TE and MPLS. I agree this could be better disambiguated. Alex From IETF@ThomasClausen.org Thu Feb 19 08:45:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA9063A68A8 for ; Thu, 19 Feb 2009 08:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id px7nTUPM0F3A for ; Thu, 19 Feb 2009 08:45:48 -0800 (PST) Received: from mho-01-bos.mailhop.org (mho-01-bos.mailhop.org [63.208.196.178]) by core3.amsl.com (Postfix) with ESMTP id 391C03A681C for ; Thu, 19 Feb 2009 08:45:48 -0800 (PST) Received: from aste-genev-bois-153-1-9-122.w83-112.abo.wanadoo.fr ([83.112.71.122] helo=[192.168.147.109]) by mho-01-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LaC2A-000FDE-3t; Thu, 19 Feb 2009 16:45:58 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 83.112.71.122 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/LXomgMHddF8vzl3exhuoS In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC06FD49DA@xmb-ams-337.emea.cisco.com> References: <7D002912-FC79-437A-86EF-2CAB60F21054@cs.stanford.edu><52387448-346C-4324-8A70-104D7658C695@cs.stanford.edu> <699FB9C8-2625-4EBD-ABE1-EFBBAF57CDD6@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC06FD49DA@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <95CE8FC0-D503-427C-A88A-40CB41620FA2@ThomasClausen.org> Content-Transfer-Encoding: quoted-printable From: Thomas Heide Clausen Date: Thu, 19 Feb 2009 17:47:32 +0100 To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.753.1) Cc: ROLL WG Subject: Re: [Roll] New Text for the Charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 16:45:49 -0000 Pascal, I agree with much of what you say, but notably except the last =20 sentence of: > My take is that we'll need to be creative when we define the =20 > unicast routing to try and fulfill the multicast requirements we =20 > have for as little additional cost as we can... But I would keep =20 > the charter as it stands for that matter. I think that if the "multicast"/"multipoint" requirement is to appear =20= as an important design space constraint for ROLL protocols, then this =20= should be made evident in the charter. I also think that disambiguifying multicast/multipoint would be of =20 value. Thomas On Feb 19, 2009, at 12:20 PM, Pascal Thubert (pthubert) wrote: > Hi: > > First I wish to concur with Phil and JP that we need to avoid the =20 > confusion between multipoint and multicast. I'll be elaborating a =20 > little bit on multicast and IPv6. > > Link scope multicast (FF02:...) > ------------------------------- > > IPv6 relies on link scope multicast capabilities for a number of =20 > activities, such as ND. IPv6 does not expect that a Link scope =20 > multicast will ever be routed / relayed at layer 3. For instance ND =20= > actively checks against a change in the hop limit that is set to =20 > 255 for that purpose. Hello protocol uses FF02::5 with the =20 > expectation that only direct connectivity shows up. Etc... > > Now the type of network we're looking at derives largely from the =20 > NBMA model, and NBMA does not provide native link layer multicast =20 > capability; moreover, in the P2MP case, FF02 would need routing and =20= > relaying to span the whole network, which is incompatible with how =20 > link scoped multicast is used in the first place. So for the =20 > purpose of IPv6 operation, a number of approaches have been =20 > proposed to emulate multicast and enable transparent IPv6 operations. > > RFCs 2491/2022/2332: This is the generic model for large NBMA. Mars =20= > (RFC 2022) is an example of convergence protocol to emulate =20 > multicast transparently to ND and others. > > RFC 3122: A new form of ND is introduced that does not need a link =20 > spanning multicast service. Can be coupled with the above id DAD is =20= > required. Secured and generalized in draft-thubert-3122bis. > > 6LoWPAN: A subcase of NBMA with a backbone link where FF02:: =20 > multicast actually works. An ND extension enables registration over =20= > the NBMA edge and proxy operation over the backbone. That same =20 > registration enables a service similar to MARS for the purpose of =20 > NS/DAD, but in a lot simpler and less generic fashion. For those =20 > link scope multicast that could not be avoided, such as some RAs, =20 > Trickle optimizes the dissemination of the information in the Low =20 > Power network. > > It's unclear at this point how far ROLL can reuse that art and how =20 > efficient that would be; I certainly would not oppose to having an =20 > additional work item to study this specific issue and produce an =20 > informational draft. But it's not proven we have a specific problem =20= > with link scope multicast that prevents ROLL operation either. > > L3 (routed) multicast, that is FF0x:... (x>2) > --------------------------------------------- > > Multicast appears in the requirements document as the way to =20 > distribute to many small groups of nodes; seems ROLL could survive =20 > short term with multiple P2P even though it'd be inefficient in a =20 > deep ROLL network. > > For all I've seen, that's mostly information and commands being =20 > pushed from the infrastructure into the ROLL network. The way I see =20= > it, we do not necessarily need a full fledged support of multicast, =20= > but rather a way to distribute data coming from the outside along =20 > trees that span the ROLL network from the network sinks. If the =20 > routing that we define provides such trees, then the logical =20 > structure can be economically reused for multicast distribution. =20 > MANEMO did just that, though I think we never published the draft =20 > that detailed the mcast NINA that carried MLD proxy registrations =20 > up the TD tree. > > My take is that we'll need to be creative when we define the =20 > unicast routing to try and fulfill the multicast requirements we =20 > have for as little additional cost as we can... But I would keep =20 > the charter as it stands for that matter. > > Pascal > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =20 >> Behalf Of JP Vasseur (jvasseur) >> Sent: mercredi 18 f=E9vrier 2009 19:41 >> To: Philip Levis >> Cc: ROLL WG; Thomas Heide Clausen >> Subject: Re: [Roll] New Text for the Charter >> >> >> On Feb 18, 2009, at 7:26 PM, Philip Levis wrote: >> >>> Comments inline. >>> >>> On Feb 18, 2009, at 10:17 AM, Thomas Heide Clausen wrote: >>> >>>> >>>> On Feb 18, 2009, at 18:56 PM, Philip Levis wrote: >>>> >>>>> Comment follows. >>>>> >>>>> On Feb 18, 2009, at 7:17 AM, Thomas Heide Clausen wrote: >>>>> >>>>>> Chris, Jerald, you both bring up an important question that I >>>>>> hadn't fully realized: to which extend is the output of ROLL >>>>>> going to be an unicast routing protocol? Multicast routing >>>>>> protocol? Multicast transport protocol? Something else? All or >>>>>> some of the above? Neither? In one protocol? >>>>>> >>>>>> I think that the charter might want to be a bit more specific on >>>>>> this matter. >>>>>> >>>>>> I'd think that if ROLL wants to produce a single protocol doing >>>>>> both uni- and multicast routing, then this should be spelled out >>>>>> explicitly in the charter. If ROLL wants to produce both an >>>>>> unicast routing protocol and a multicast routing protocol, then >>>>>> this also should be spelled out explicitly in the charter. >>>>> >>>>> Thomas, I have to disagree on this point. I think that this >>>>> decision, in and of itself, is protocol design. It would be a real >>>>> mistake to bind the WG to one approach or the other without any >>>>> examination of the tradeoffs of each approach. But that >>>>> examination is what the re-chartering is for. >>>>> >>>>> For example, if the charter says "one protocol" but then this one >>>>> protocol becomes clearly inferior to an approach with two >>>>> protocols, we're in a bind. If the charter says "two protocols" >>>>> but then there's a protocol that handles both seamlessly (and so >>>>> has simpler code), we're in a bind. >>>>> >>>>> Phil >>>> >>>> Phil, I am actually not disagreeing with what you are saying >>>> regarding the protocol(s) that will result. However if the ROLL >>>> needs a solution for both unicast and multicast, then this should >>>> be stated clearly. As it is, it reads simply: >>> >>> Great! >>> >>>> >>>> >>>>> - Typical traffic patterns are not simply unicast flows, >>>> >>>> >>>> Which I think is a bit too obscure a way of stating that the WG >>>> will be working on both unicast and multicast solutions. >>> >>> I thought the new text says >>> >>> - Typical traffic patterns are not simply unicast flows (e.g. >>> in some environments most if not all traffic can be point to >>> multipoint) >>> >>> so it articulates this. How do you think it could be improved? >>> >>> I think it might be important to separate the notion of "point to >>> multipoint" from "multicast." Generally, IP mulitcast is handled by >>> a node joining a multicast group. That is, the set of recipients is >>> defined by which recipients join the group. In contrast, you'll >>> notice that in some application docs the requirements are a bit >>> different: a sender wants to deliver a message to a group of nodes, >>> where the group is defined by the sender. Its seems very likely that >>> multicast is a good way to achieve this, but we're then specifying >>> the solution, rather than the requirement. >>> >> >> You stole my words .. fully agreeing. >> >>> Does that make sense? It's a very fine line, trying to crisply >>> define what the WG needs to accomplish without defining too tightly >>> and excluding mechanisms that very useful. >>> >>> Phil >>> >>> _______________________________________________ >>> 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 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From wwwrun@core3.amsl.com Thu Feb 19 17:37:19 2009 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id C2CCD3A6952; Thu, 19 Feb 2009 17:37:19 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090220013719.C2CCD3A6952@core3.amsl.com> Date: Thu, 19 Feb 2009 17:37:19 -0800 (PST) Cc: roll@ietf.org Subject: [Roll] Last Call: draft-ietf-roll-building-routing-reqs (Building Automation Routing Requirements in Low Power and Lossy Networks) to Informational RFC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 01:37:19 -0000 The IESG has received a request from the Routing Over Low power and Lossy networks WG (roll) to consider the following document: - 'Building Automation Routing Requirements in Low Power and Lossy Networks ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-03-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-roll-building-routing-reqs-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17943&rfc_flag=0The following IPR Declarations may be related to this I-D: From wwwrun@core3.amsl.com Thu Feb 19 17:39:17 2009 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 8CEDE3A6B0A; Thu, 19 Feb 2009 17:39:17 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090220013917.8CEDE3A6B0A@core3.amsl.com> Date: Thu, 19 Feb 2009 17:39:17 -0800 (PST) Cc: roll@ietf.org Subject: [Roll] Last Call: draft-ietf-roll-indus-routing-reqs (Industrial Routing Requirements in Low Power and Lossy Networks) to Informational RFC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 01:39:17 -0000 The IESG has received a request from the Routing Over Low power and Lossy networks WG (roll) to consider the following document: - 'Industrial Routing Requirements in Low Power and Lossy Networks ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-03-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-roll-indus-routing-reqs-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17220&rfc_flag=0The following IPR Declarations may be related to this I-D: