From roll-bounces@ietf.org Tue Apr 1 09:56:32 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B80DF28C184; Tue, 1 Apr 2008 09:56:32 -0700 (PDT) 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 471B028C184 for ; Tue, 1 Apr 2008 09:56:31 -0700 (PDT) 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 KMtc5mTDJrQh for ; Tue, 1 Apr 2008 09:56:30 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 55CB428C19A for ; Tue, 1 Apr 2008 09:56:30 -0700 (PDT) Received: from dn0a422105.sunet ([10.66.33.5]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Jgjme-000067-Qe; Tue, 01 Apr 2008 09:56:29 -0700 Message-Id: <54CE3D4F-5D63-41C6-8688-E3FBDD54D207@cs.stanford.edu> From: Philip Levis To: Ian Chakeres In-Reply-To: <8C1DD7A0-7C74-4F30-A990-0550EB681793@gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 1 Apr 2008 09:01:46 -0700 References: <8C1DD7A0-7C74-4F30-A990-0550EB681793@gmail.com> X-Mailer: Apple Mail (2.919.2) X-Scan-Signature: d28feff3406e72e6317b3bc92234f5b9 Cc: roll@ietf.org Subject: Re: [Roll] review/comments on overview-protocols 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 These are some excellent points, Ian. Details inline. On Mar 31, 2008, at 12:25 PM, Ian Chakeres wrote: > Here are some comments I have from reviewing the overview-protocols > document. > > I think you should consider including proactive/reactive in the > routing protocol taxonomy. > You may also want to discuss distribution of a default route. > Both of these are good points. The first one especially so, because it will give insight on why the analysis plays out like it does. > > > On page 6 you bring up neighbor discovery. I would recommend you > change the terminology to avoid the term "neighbor discovery (ND)". > ND has very specific connotations within the IETF. I might recommend > adjacent router discovery. You might also want to mention asymmetric > reachability (see ND RFC), since this behavior will be common in > ROLL networks. This is a good point. We want to be careful about terminology. > > > RIPng and DYMO use distance as a metric. > > AODV has some weird behaviors when multiple messages are received > with different delays that make it not simply dependent on hop > count. My paper discusses it === Ian D. Chakeres and Elizabeth M. > Belding-Royer. "Transparent Influence of Path Selection in > Heterogeneous Ad hoc Networks." Proceedings of the 15th IEEE > International Symposium on Personal, Indoor and Mobile Radio > Communications (PIMRC), Barcelona, Spain, September 2004. === > Several of these observations/features are also available for DYMO. > > Using the methods (delay or distance) above both AODV and DYMO can > include node metrics such as energy in their route discovery. This > behavior may influence Section 5.2. > > In Section 5.3 you mention GPSR, please include a reference. > > In Section 5.4 you state that AODV headers are 24 bytes. This seems > to be stated as protocols not being built to support small MTU, but > I would argue that 24-bytes is a small packet in comparison to most > other proactive routing protocols. Very true. It is important to give values for more protocols, so a reasonable comparison is possible. > > > In Section 5.4, you might want to mention 6lowpan as one solution > for handling ROLL small MTU problems. > > In Section 5.5 you discuss sleepy nodes. I see sleepy and low power > as related but distinctly different problems. Perhaps you can make > sleepy a subsection of low power. > > In Section 5.7 - I have been working hard to incorporate mechanisms > to enable MTR in all the MANET protocols. The draft is draft- > chakeres-manet-manetid. It has been discussed on list and I plan to > include it in DYMO. > > I'd like to say a few words about DYMO. DYMO has lots of optional > behavior and only the most fundamental behaviors are required. For > example, path accumulation is optional. Even forwarding a RREQ is > optional. Expanding ring search is optional. Interactions with relay > sets are optional. Although not described - precursor lists could be > implemented and they could be used to control RERR propagation. > These optional behaviors allow an intelligent implementation to > perform well in a larger number of scenarios. Good point. I guess part of the trick here will be to figure out how to characterize DYMO given its many options. Having 20 or so different DYMO variants in the table is not particularly helpful. Perhaps the place to start might be what TYMO uses, which is essentially DYMO in its most stripped-down form. > > > The discussion of DSR in the appendix seems quite weak when compared > to the other protocols. > > Feel free to share this with the other authors, > Ian > > One more thing - Here is a comment related to the current on-list > discussion about which protocols to include in the analysis - should > mobile IP and other tunneling protocols be included? I say no, but > many (e.g. MANEMO) people may say yes. > I am tempted to say no: those are (effectively) overlay routes over existing L3 routes, while what we're concerned with here are the underlying L3 routes. Now, one could have a subset of underlying L3 routes and use them as waypoints for the overlay, which then fills in the rest, but I suspect that such a protocol would look very different than mobile IP and such. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Apr 1 09:56:37 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1D7728C34E; Tue, 1 Apr 2008 09:56:36 -0700 (PDT) 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 72F4628C34E; Tue, 1 Apr 2008 09:56:36 -0700 (PDT) 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 hno1DS9sLuUe; Tue, 1 Apr 2008 09:56:32 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id C1CAF28C1AF; Tue, 1 Apr 2008 09:56:32 -0700 (PDT) Received: from dn0a422105.sunet ([10.66.33.5]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Jgjmg-000067-CY; Tue, 01 Apr 2008 09:56:30 -0700 Message-Id: <73B18F4E-8160-4901-9379-48EA98171DB7@cs.stanford.edu> From: Philip Levis To: In-Reply-To: <200804010853.m318rbPt000534@castor.cttc.es> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 1 Apr 2008 09:10:07 -0700 References: <200804010853.m318rbPt000534@castor.cttc.es> X-Mailer: Apple Mail (2.919.2) X-Scan-Signature: b64bce576883819501cf77c9371f4538 Cc: roll@ietf.org, 'manet manet' Subject: Re: [Roll] Discussion on 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Apr 1, 2008, at 1:52 AM, Mischa Dohler wrote: > Phil: "Its purpose is expressly *not* to survey research, other > standards body, and custom protocols." > > Mischa: Ok, we will kick in later then. > > > (Phil: "All of these results are from high-level simulators which > use a > unit-disk model for radio connectivity. Their claims therefore need > to be > taken with a grain of salt. Among other things, they do not consider > any kind of temporal dynamics." > > Mischa: We are very aware of this and our approaches do not consider > unit > disk and also cater for high network dynamicity - and - they work > very well. I was, of course, referring to Vcap and Gspring, the two papers you cited. I can't make any statements about papers I haven't read. For example, the Gspring paper reads: "In our simulations, we adpoted a simple radio model: all nodes have a uniform radio range; two nodes can communicate if and only if they are within radio range of each other and if their line of sight does not intersect and obstacle." Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Apr 1 11:02:28 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 892533A696F; Tue, 1 Apr 2008 11:02:28 -0700 (PDT) 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 6C9843A6D78 for ; Tue, 1 Apr 2008 11:02:27 -0700 (PDT) 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 eNhENCpMhYwV for ; Tue, 1 Apr 2008 11:02:26 -0700 (PDT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.238]) by core3.amsl.com (Postfix) with ESMTP id B70E63A696F for ; Tue, 1 Apr 2008 11:02:25 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id i26so2618923wxd.31 for ; Tue, 01 Apr 2008 11:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=aqDKps0mKdRwn8h6+DOT5tduIVJo+QZMb7P4bESHEns=; b=CPDi27aIX56kn0/YUjVy1F1R0sDPHLLkrzGyBAVwIgaivSK7tF9zDYDVsm8xj/d++35CZaEKvKZq1tdMilejl0YqPA6jPVBCgutLauB0ghGQppWbfBiBYJAj+bAWb71BZ3HGLcxw1Qho0+62NBAmrBjj4RSDcxuyY60rzVnHm/0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Gxam6uW4GVOd3Bqb9jtYkPbYjo6UUyvzaT4513gseOp0ZtBZ8K1g6Z4eCmyCjqf5jpTThGDwXcH75H6IWTafFA04QuxlUTrR2nKMcZK0EroLgJR3nUfHQrO5fYlH2jRAVTiz/ZgMx8m8FZMJs5CByUDqSbPekvNEZYv9AnDcZjc= Received: by 10.100.91.17 with SMTP id o17mr19936638anb.90.1207072909925; Tue, 01 Apr 2008 11:01:49 -0700 (PDT) Received: by 10.100.3.13 with HTTP; Tue, 1 Apr 2008 11:01:49 -0700 (PDT) Message-ID: <374005f30804011101r4d465ae9o559854c9cc58712e@mail.gmail.com> Date: Tue, 1 Apr 2008 23:31:49 +0530 From: "Ian Chakeres" To: "Philip Levis" In-Reply-To: <54CE3D4F-5D63-41C6-8688-E3FBDD54D207@cs.stanford.edu> MIME-Version: 1.0 Content-Disposition: inline References: <8C1DD7A0-7C74-4F30-A990-0550EB681793@gmail.com> <54CE3D4F-5D63-41C6-8688-E3FBDD54D207@cs.stanford.edu> Cc: roll@ietf.org Subject: Re: [Roll] review/comments on overview-protocols 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 Comments inline. On Tue, Apr 1, 2008 at 9:31 PM, Philip Levis wrote: > These are some excellent points, Ian. Details inline. > > > On Mar 31, 2008, at 12:25 PM, Ian Chakeres wrote: > > Here are some comments I have from reviewing the overview-protocols > > document. > > > > I think you should consider including proactive/reactive in the > > routing protocol taxonomy. > > > You may also want to discuss distribution of a default route. > > > > Both of these are good points. The first one especially so, because it > will give insight on why the analysis plays out like it does. > > > > > > > > On page 6 you bring up neighbor discovery. I would recommend you > > change the terminology to avoid the term "neighbor discovery (ND)". > > ND has very specific connotations within the IETF. I might recommend > > adjacent router discovery. You might also want to mention asymmetric > > > reachability (see ND RFC), since this behavior will be common in > > ROLL networks. > > This is a good point. We want to be careful about terminology. > > > > > > > > RIPng and DYMO use distance as a metric. > > > > AODV has some weird behaviors when multiple messages are received > > with different delays that make it not simply dependent on hop > > count. My paper discusses it === Ian D. Chakeres and Elizabeth M. > > > Belding-Royer. "Transparent Influence of Path Selection in > > Heterogeneous Ad hoc Networks." Proceedings of the 15th IEEE > > International Symposium on Personal, Indoor and Mobile Radio > > Communications (PIMRC), Barcelona, Spain, September 2004. === > > Several of these observations/features are also available for DYMO. > > > > Using the methods (delay or distance) above both AODV and DYMO can > > include node metrics such as energy in their route discovery. This > > > behavior may influence Section 5.2. > > > > In Section 5.3 you mention GPSR, please include a reference. > > > > In Section 5.4 you state that AODV headers are 24 bytes. This seems > > to be stated as protocols not being built to support small MTU, but > > I would argue that 24-bytes is a small packet in comparison to most > > other proactive routing protocols. > > Very true. It is important to give values for more protocols, so a > reasonable comparison is possible. > > > > > > > In Section 5.4, you might want to mention 6lowpan as one solution > > for handling ROLL small MTU problems. > > > > > In Section 5.5 you discuss sleepy nodes. I see sleepy and low power > > as related but distinctly different problems. Perhaps you can make > > sleepy a subsection of low power. > > > > In Section 5.7 - I have been working hard to incorporate mechanisms > > > to enable MTR in all the MANET protocols. The draft is draft- > > chakeres-manet-manetid. It has been discussed on list and I plan to > > > include it in DYMO. > > > > I'd like to say a few words about DYMO. DYMO has lots of optional > > behavior and only the most fundamental behaviors are required. For > > example, path accumulation is optional. Even forwarding a RREQ is > > > optional. Expanding ring search is optional. Interactions with relay > > sets are optional. Although not described - precursor lists could be > > implemented and they could be used to control RERR propagation. > > These optional behaviors allow an intelligent implementation to > > perform well in a larger number of scenarios. > > Good point. I guess part of the trick here will be to figure out how > to characterize DYMO given its many options. Having 20 or so different > DYMO variants in the table is not particularly helpful. Perhaps the > place to start might be what TYMO uses, which is essentially DYMO in > its most stripped-down form. I'd like to say that these "variants" are all compatible and interoperate. The challenge with basing the performance on a "stripped-down" version of DYMO, is that the stripped-down version may perform very good or very bad in certain scenarios. For example, path accumulation can be considered very good if it reduces the number of route discovery attempts. On the other hand, if this information isn't used (and therefore doesn't reduce the number of route discovery attempts) it is considered a waste. I think lots of the optional features enable implementors and nodes to make intelligent tradeoff decisions. > > > > > > The discussion of DSR in the appendix seems quite weak when compared > > to the other protocols. > > > > Feel free to share this with the other authors, > > > Ian > > > > One more thing - Here is a comment related to the current on-list > > discussion about which protocols to include in the analysis - should > > mobile IP and other tunneling protocols be included? I say no, but > > many (e.g. MANEMO) people may say yes. > > > > I am tempted to say no: those are (effectively) overlay routes over > existing L3 routes, while what we're concerned with here are the > underlying L3 routes. Now, one could have a subset of underlying L3 > routes and use them as waypoints for the overlay, which then fills in > the rest, but I suspect that such a protocol would look very different > than mobile IP and such. I agree with you, but I also think these items might come into more play when we discuss the network size and what hierarchy is desired/used/required for ROLL networks. Ian _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Apr 1 15:48:51 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 271873A6B7E; Tue, 1 Apr 2008 15:48:51 -0700 (PDT) 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 E3F4C3A6991 for ; Tue, 1 Apr 2008 15:48:49 -0700 (PDT) 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 Png3-6wQ5JvY for ; Tue, 1 Apr 2008 15:48:49 -0700 (PDT) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.250]) by core3.amsl.com (Postfix) with ESMTP id D6A193A6985 for ; Tue, 1 Apr 2008 15:48:48 -0700 (PDT) Received: by ag-out-0708.google.com with SMTP id 23so1316567agd.12 for ; Tue, 01 Apr 2008 15:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=2KCK0AQbbzD4WQHhTX2Yg3gcxYTYd33OT3EV9RG3kJs=; b=lfuDgeshUg/E0sgI1KJW9yFtHJcdDGUsTMnHf/y6iigWTZuwOncZydFT8s5JoJE7O1K7ufwQrVEVIaXwA+cMQ2Z+W9Do08vXMpIxt+1SDON3SDEzWs6jvxFvS7OyThO8VhMDb/JjDi3K5FwDlDpQeEWZD3o2jZMlhDwP4WSwe2I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=X5cjJbf7ls9Z8xOFjoeNVujnDonpI8smz0sHWudVXmqUvUtgDQG7XHZDWO8ei5vnDhWABj96KBqXLO6KzY6sLC9+qsCMqV5a/1gC5vthW8CvinquxieiLBSWtjCRLEKAOfGf6FD6g3lF0g0hks2YVEyJmEKPujvArKQWbghNAU0= Received: by 10.100.140.14 with SMTP id n14mr20623535and.65.1207090127252; Tue, 01 Apr 2008 15:48:47 -0700 (PDT) Received: by 10.100.3.13 with HTTP; Tue, 1 Apr 2008 15:48:47 -0700 (PDT) Message-ID: <374005f30804011548h43e62b9cle68c8808ef9d9103@mail.gmail.com> Date: Wed, 2 Apr 2008 04:18:47 +0530 From: "Ian Chakeres" To: roll@ietf.org In-Reply-To: <47F295AC.7020000@earthlink.net> MIME-Version: 1.0 Content-Disposition: inline References: <374005f30803312155kdcbf3bbsb35afce0c0ddb498@mail.gmail.com> <47F295AC.7020000@earthlink.net> Cc: rich.ogier@earthlink.net Subject: [Roll] TBRPF Analysis in http://www.ietf.org/internet-drafts/draft-levis-roll-overview-protocols-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org I asked Richard Ogier (rich.ogier@earthlink.net) author of TBRPF to look over the overview-protocols document and its statements about TBRPF. Here is his response. ===== The brief summary in Section 3.3 is fine, but I don't agree with the analysis (spelled "analsysis") in Section 11. They say the total control overhead is O(n^2), which would be the overhead if every node advertises its entire source tree, since each source tree has n-1 links. So O(n^2) can be considered the worst case, with high churn and overlapping trees, which they claim would be even larger. So at the very minimum, the text should be changed to say that O(n^2) is the worst case, not the optimal case. The optimal case would probably be O(n^2 / d), but I don't have a proof for this. Similarly, the last paragraph says that in the worst case, each node reports the entire topology. This is not true. In the worst case, each node reports its entire source tree. So in the worst case, each node would have to maintain O(n) state for each neighbor, or O(n*d) for all neighbors. In the best case, each node reports only part of its source tree, so each node would have to maintain O(n) for all neighbors (again I don't have a proof), plus O(d^2) for all neighbors' neighbors. Richard Here is the analysis from the document: "TBRPF" The information transmitted within a neighborhood is the union of all the reported trees of the nodes, where the reported tree is defined in the protocol. In the optimal case, this union comprises a single copy of the entire Topology Graph, which has size O(n * d). Thus given O(n / d) neighborhoods in the entire network, the total control overhead will be O(n ^2). In the worst case, for example with high churn, nodes within a neighborhood will transmit larger, overlapping reported trees leading to more control traffic. Additionally, since TBRPF makes extensive use of differental updates, the observed control overhead may be much smaller if the topology is relatively static. Each node maintains the global network link-state, as reported by each neighbor. Each of these copies has size O(n * d). Thus in the worst case, where each neighbor reports the entire topology, this information has size O(n * (d ^ 2)). However, in the optimal case where each neighbor reports non-overlapping subsets of the topology, the total state will be only O(n * d). _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Apr 2 09:21:49 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31A0B28C538; Wed, 2 Apr 2008 09:21:49 -0700 (PDT) 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 F33D128C538 for ; Wed, 2 Apr 2008 09:21:46 -0700 (PDT) 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 amFcOosWHBBf for ; Wed, 2 Apr 2008 09:21:45 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 7665728C605 for ; Wed, 2 Apr 2008 09:20:26 -0700 (PDT) Received: from dn0a4220cb.sunet ([10.66.32.203]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Jh5hL-0004b7-GP; Wed, 02 Apr 2008 09:20:27 -0700 Message-Id: <88D106ED-E9BE-4F5A-8CFB-29683FBBFDDA@cs.stanford.edu> From: Philip Levis To: "Ian Chakeres" In-Reply-To: <374005f30804011548h43e62b9cle68c8808ef9d9103@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 2 Apr 2008 09:20:27 -0700 References: <374005f30803312155kdcbf3bbsb35afce0c0ddb498@mail.gmail.com> <47F295AC.7020000@earthlink.net> <374005f30804011548h43e62b9cle68c8808ef9d9103@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) X-Scan-Signature: 72f97ea9660f372cf635c7c250d627db Cc: rich.ogier@earthlink.net, roll@ietf.org Subject: Re: [Roll] TBRPF Analysis in http://www.ietf.org/internet-drafts/draft-levis-roll-overview-protocols-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Apr 1, 2008, at 3:48 PM, Ian Chakeres wrote: > I asked Richard Ogier (rich.ogier@earthlink.net) author of TBRPF to > look over the overview-protocols document and its statements about > TBRPF. > > Here is his response. > This is great, Ian. It's exactly the kind of inspection and iteration we need. Thanks for doing this. > ===== > > The brief summary in Section 3.3 is fine, but I don't agree > with the analysis (spelled "analsysis") in Section 11. > They say the total control overhead is O(n^2), which would be > the overhead if every node advertises its entire source tree, > since each source tree has n-1 links. > So O(n^2) can be considered the worst case, with high churn > and overlapping trees, which they claim would be even larger. > So at the very minimum, the text should be changed to say > that O(n^2) is the worst case, not the optimal case. > > The optimal case would probably be O(n^2 / d), but > I don't have a proof for this. Well, big-O is a worst-case analysis, except for randomized algorithms, where it's an expected analysis based on worst-case input. > > > Similarly, the last paragraph says that in the worst case, > each node reports the entire topology. This is not true. > In the worst case, each node reports its entire source tree. > So in the worst case, each node would have to maintain > O(n) state for each neighbor, or O(n*d) for all neighbors. Nice catch. > In the best case, each node reports only part of its > source tree, so each node would have to maintain > O(n) for all neighbors (again I don't have a proof), > plus O(d^2) for all neighbors' neighbors. As big-O is worst case, the above makes more sense. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Apr 2 10:46:27 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF7F93A6BD9; Wed, 2 Apr 2008 10:46:27 -0700 (PDT) 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 1A05D3A6CC3 for ; Wed, 2 Apr 2008 10:39:05 -0700 (PDT) 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 6wObZoiP1a2d for ; Wed, 2 Apr 2008 10:39:04 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 203013A67FD for ; Wed, 2 Apr 2008 10:39:04 -0700 (PDT) Received: from [4.245.96.159] by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Jh6vQ-0004bL-38; Wed, 02 Apr 2008 13:39:05 -0400 Message-ID: <47F3D343.7030200@earthlink.net> Date: Wed, 02 Apr 2008 10:41:07 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Levis References: <374005f30803312155kdcbf3bbsb35afce0c0ddb498@mail.gmail.com> <47F295AC.7020000@earthlink.net> <374005f30804011548h43e62b9cle68c8808ef9d9103@mail.gmail.com> <88D106ED-E9BE-4F5A-8CFB-29683FBBFDDA@cs.stanford.edu> In-Reply-To: <88D106ED-E9BE-4F5A-8CFB-29683FBBFDDA@cs.stanford.edu> X-ELNK-Trace: a073897a9455599e74bf435c0eb9d47887a5dba1e6b14d0a7c3077b857c98c3c49f6c3c7511e4272350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.245.96.159 X-Mailman-Approved-At: Wed, 02 Apr 2008 10:46:26 -0700 Cc: roll@ietf.org Subject: Re: [Roll] TBRPF Analysis in http://www.ietf.org/internet-drafts/draft-levis-roll-overview-protocols-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Philip Levis wrote: > > On Apr 1, 2008, at 3:48 PM, Ian Chakeres wrote: > >> I asked Richard Ogier (rich.ogier@earthlink.net) author of TBRPF to >> look over the overview-protocols document and its statements about >> TBRPF. >> >> Here is his response. >> > > This is great, Ian. It's exactly the kind of inspection and iteration > we need. Thanks for doing this. > >> ===== >> >> The brief summary in Section 3.3 is fine, but I don't agree >> with the analysis (spelled "analsysis") in Section 11. >> They say the total control overhead is O(n^2), which would be >> the overhead if every node advertises its entire source tree, >> since each source tree has n-1 links. >> So O(n^2) can be considered the worst case, with high churn >> and overlapping trees, which they claim would be even larger. >> So at the very minimum, the text should be changed to say >> that O(n^2) is the worst case, not the optimal case. >> >> The optimal case would probably be O(n^2 / d), but >> I don't have a proof for this. > > > Well, big-O is a worst-case analysis, except for randomized > algorithms, where it's an expected analysis based on worst-case input. > Do you agree to change the analysis to say that O(n^2) is the worst case, instead of the optimal case? Also, since your analysis also mentions the optimal case, do you agree to say that the optimal case can be better than this since each node reports only a part of its source tree? After all, that is the whole point of advertising only part of the source tree! >> >> >> Similarly, the last paragraph says that in the worst case, >> each node reports the entire topology. This is not true. >> In the worst case, each node reports its entire source tree. >> So in the worst case, each node would have to maintain >> O(n) state for each neighbor, or O(n*d) for all neighbors. > > > Nice catch. Thanks. I am mainly concerned that you missed my first catch above. Richard > >> In the best case, each node reports only part of its >> source tree, so each node would have to maintain >> O(n) for all neighbors (again I don't have a proof), >> plus O(d^2) for all neighbors' neighbors. > > > As big-O is worst case, the above makes more sense. > > Phil > > "TBRPF" The information transmitted within a neighborhood is the union of all the reported trees of the nodes, where the reported tree is defined in the protocol. In the optimal case, this union comprises a single copy of the entire Topology Graph, which has size O(n * d). Thus given O(n / d) neighborhoods in the entire network, the total control overhead will be O(n ^2). In the worst case, for example with high churn, nodes within a neighborhood will transmit larger, overlapping reported trees leading to more control traffic. Additionally, since TBRPF makes extensive use of differental updates, the observed control overhead may be much smaller if the topology is relatively static. Each node maintains the global network link-state, as reported by each neighbor. Each of these copies has size O(n * d). Thus in the worst case, where each neighbor reports the entire topology, this information has size O(n * (d ^ 2)). However, in the optimal case where each neighbor reports non-overlapping subsets of the topology, the total state will be only O(n * d). _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Apr 8 08:02:40 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D6B128C34D; Tue, 8 Apr 2008 08:02:40 -0700 (PDT) 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 5136628C3C4 for ; Tue, 8 Apr 2008 08:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.424 X-Spam-Level: X-Spam-Status: No, score=-4.424 tagged_above=-999 required=5 tests=[AWL=2.175, 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 QmeaCE2bwFXL for ; Tue, 8 Apr 2008 08:02:34 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 5D99528C1E8 for ; Tue, 8 Apr 2008 08:02:34 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 08 Apr 2008 08:02:50 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m38F2ogc011566 for ; Tue, 8 Apr 2008 08:02:50 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m38F2mf2028703 for ; Tue, 8 Apr 2008 15:02:50 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Apr 2008 11:02:49 -0400 Received: from 10.86.104.186 ([10.86.104.186]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Tue, 8 Apr 2008 15:02:48 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Tue, 08 Apr 2008 11:02:47 -0400 From: JP Vasseur To: Message-ID: Thread-Topic: FYI The rsn@ietf.org mailing list has be decommissioned Thread-Index: AciZiZr+2bzBfQV8Ed2IpwANk8WjQA== Mime-version: 1.0 X-OriginalArrivalTime: 08 Apr 2008 15:02:49.0380 (UTC) FILETIME=[9C69AE40:01C89989] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2; t=1207666970; x=1208530970; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20FYI=20The=20rsn@ietf.org=20mailing=20list=20has =20be=20decommissioned=20 |Sender:=20; bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=; b=dHQ4TDz7AxgE7zUqN5wVeGfUyMsbB9OK8ua55e/4y8m/j2513Tb8rM803r JaCmiEZ0i/xn9YJ/31OgQJwj/rzWAA9R/g25pCPLTkhjscx3tzWr+SoirkAD AcbCL+LbOR; Authentication-Results: sj-dkim-3; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Roll] FYI The rsn@ietf.org mailing list has be decommissioned 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 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Apr 8 11:50:59 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D72AB28C3F5; Tue, 8 Apr 2008 11:50:59 -0700 (PDT) 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 A7ACD3A69EB for ; Tue, 8 Apr 2008 11:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.368 X-Spam-Level: X-Spam-Status: No, score=-4.368 tagged_above=-999 required=5 tests=[AWL=2.004, BAYES_00=-2.599, 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 nWL2uvQEeUkM for ; Tue, 8 Apr 2008 11:50:57 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3677728C411 for ; Tue, 8 Apr 2008 11:50:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,625,1199682000"; d="scan'208";a="4417335" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 08 Apr 2008 14:51:01 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m38Ip1RV023143 for ; Tue, 8 Apr 2008 14:51:01 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m38Ip14Y006392 for ; Tue, 8 Apr 2008 18:51:01 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Apr 2008 14:51:01 -0400 Received: from 10.86.104.186 ([10.86.104.186]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Tue, 8 Apr 2008 18:51:01 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Tue, 08 Apr 2008 14:50:59 -0400 From: JP Vasseur To: Message-ID: Thread-Topic: Adoption of draft-dohler-roll-urban-routing-reqs-01.txt as a WG document ? Thread-Index: AciZqXwPunpgkwWcEd2IpwANk8WjQA== Mime-version: 1.0 X-OriginalArrivalTime: 08 Apr 2008 18:51:01.0898 (UTC) FILETIME=[7DCA1EA0:01C899A9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=263; t=1207680661; x=1208544661; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Adoption=20of=20draft-dohler-roll-urban-routing -reqs-01.txt=20as=20a=20WG=0A=20document=20? |Sender:=20 |To:=20; bh=imI+ZSvdfjiL26hrdJuAxSwXt2g30FC0OnK/OQU62cs=; b=Pb3iw1hjLIYda79sh6oVsd9Y096WFc8phON5RTSgRrrk6Q579Qq46BmVdO 8d4f+t2RO07/v/DjoyliPH+z9q8VCAZeWbwhYaRqwMoZv+WQ1ZfEj69xUWSC GX974FErgs; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [Roll] Adoption of draft-dohler-roll-urban-routing-reqs-01.txt as a WG 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Dear WG, Could you please let us know whether you are in favor or opposed to adopting draft-dohler-roll-urban-routing-reqs-01.txt ( http://www.ietf.org/internet-drafts/draft-dohler-roll-urban-routing-reqs-01. txt) as a ROLL WG document ? Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Apr 8 13:00:49 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 683C13A6902; Tue, 8 Apr 2008 13:00:49 -0700 (PDT) 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 60AF128C39F for ; Tue, 8 Apr 2008 13:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.022 X-Spam-Level: X-Spam-Status: No, score=-3.022 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, 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 8h5Bh8pwUpbU for ; Tue, 8 Apr 2008 13:00:43 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id D84923A6B4A for ; Tue, 8 Apr 2008 13:00:35 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Apr 2008 22:00:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Apr 2008 22:00:37 +0200 Message-ID: <8AA97249241F7148BE6D3D8B93D83F5A112AE312@ftrdmel2> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Adoption of draft-dohler-roll-urban-routing-reqs-01.txt as aWG document ? Thread-Index: AciZqXwPunpgkwWcEd2IpwANk8WjQAACaVVg References: From: To: , X-OriginalArrivalTime: 08 Apr 2008 20:00:45.0481 (UTC) FILETIME=[3B663990:01C899B3] Subject: Re: [Roll] Adoption of draft-dohler-roll-urban-routing-reqs-01.txt as aWG 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: , 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, In favor. Cheers, Christian. = -----Message d'origine----- De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de JP = Vasseur Envoy=E9 : mardi 8 avril 2008 20:51 =C0 : roll@ietf.org Objet : [Roll] Adoption of draft-dohler-roll-urban-routing-reqs-01.txt as a= WG document ? Dear WG, Could you please let us know whether you are in favor or opposed to adoptin= g draft-dohler-roll-urban-routing-reqs-01.txt ( http://www.ietf.org/interne= t-drafts/draft-dohler-roll-urban-routing-reqs-01. txt) as a ROLL WG document ? Thanks. JP. _______________________________________________ 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 Apr 8 13:17:15 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 973EE3A6C76; Tue, 8 Apr 2008 13:17:15 -0700 (PDT) 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 05C953A6B88 for ; Tue, 8 Apr 2008 13:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.372 X-Spam-Level: X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 9eEzim6CWtNe for ; Tue, 8 Apr 2008 13:17:14 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id C2B703A6C76 for ; Tue, 8 Apr 2008 13:17:13 -0700 (PDT) Received: from snl-zach.local (oul119-35.netplaza.fi [80.75.105.35]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id m38KHI9C020204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Apr 2008 23:17:23 +0300 Message-ID: <47FBD2D1.8020509@sensinode.com> Date: Tue, 08 Apr 2008 23:17:21 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: roll@ietf.org References: In-Reply-To: Subject: Re: [Roll] Adoption of draft-dohler-roll-urban-routing-reqs-01.txt as a WG 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi, I am in favor. - Zach JP Vasseur wrote: > Dear WG, > > Could you please let us know whether you are in favor or opposed to adopting > draft-dohler-roll-urban-routing-reqs-01.txt ( > http://www.ietf.org/internet-drafts/draft-dohler-roll-urban-routing-reqs-01. > txt) as a ROLL WG document ? > > Thanks. > > JP. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- Zach Shelby | CTO | +358 40 7796297 Sensinode Ltd. www.sensinode.com _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Apr 8 13:30:30 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC01E28C39F; Tue, 8 Apr 2008 13:30:30 -0700 (PDT) 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 02C5E3A6B88 for ; Tue, 8 Apr 2008 13:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.882 X-Spam-Level: X-Spam-Status: No, score=-0.882 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, SARE_SUB_OBFU_Q1=0.227, STOX_REPLY_TYPE=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 nHHfeVXhopT9 for ; Tue, 8 Apr 2008 13:30:28 -0700 (PDT) Received: from winston.telenet-ops.be (winston.telenet-ops.be [195.130.137.75]) by core3.amsl.com (Postfix) with ESMTP id 9DD723A6B31 for ; Tue, 8 Apr 2008 13:30:21 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by winston.telenet-ops.be (Postfix) with SMTP id 708D1A008E for ; Tue, 8 Apr 2008 22:30:37 +0200 (CEST) Received: from priveiqvfluhp9 (78-22-100-190.access.telenet.be [78.22.100.190]) by winston.telenet-ops.be (Postfix) with SMTP id 507D9A0066 for ; Tue, 8 Apr 2008 22:30:37 +0200 (CEST) Message-ID: <002301c899b7$66a8c2e0$8300a8c0@priveiqvfluhp9> From: "Pieter De Mil" To: References: <8AA97249241F7148BE6D3D8B93D83F5A112AE312@ftrdmel2> Date: Tue, 8 Apr 2008 22:30:35 +0200 Organization: UGent MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Roll] Adoption of draft-dohler-roll-urban-routing-reqs-01.txtas aWG 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org In favor. +1 Pieter -----Message d'origine----- De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de JP = Vasseur Envoy=E9 : mardi 8 avril 2008 20:51 =C0 : roll@ietf.org Objet : [Roll] Adoption of draft-dohler-roll-urban-routing-reqs-01.txt as = aWG document ? Dear WG, Could you please let us know whether you are in favor or opposed to adoptin= g = draft-dohler-roll-urban-routing-reqs-01.txt ( = http://www.ietf.org/internet-drafts/draft-dohler-roll-urban-routing-reqs-01. txt) as a ROLL WG document ? Thanks. JP. _______________________________________________ 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 Apr 8 14:36:17 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCE3E28C444; Tue, 8 Apr 2008 14:36:17 -0700 (PDT) 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 3CD9228C443 for ; Tue, 8 Apr 2008 14:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, 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 tf0Tyyc3RqxN for ; Tue, 8 Apr 2008 14:36:16 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by core3.amsl.com (Postfix) with ESMTP id 9456328C446 for ; Tue, 8 Apr 2008 14:36:16 -0700 (PDT) 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.2/8.13.5) with ESMTP id m38LaVJd005109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 8 Apr 2008 14:36:32 -0700 (PDT) Message-ID: <47FBE55A.2070601@eecs.berkeley.edu> Date: Tue, 08 Apr 2008 14:36:26 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: roll@ietf.org References: In-Reply-To: Subject: Re: [Roll] Adoption of draft-dohler-roll-urban-routing-reqs-01.txt as a WG 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org I'm in favor. ksjp JP Vasseur wrote: > Dear WG, > > Could you please let us know whether you are in favor or opposed to adopting > draft-dohler-roll-urban-routing-reqs-01.txt ( > http://www.ietf.org/internet-drafts/draft-dohler-roll-urban-routing-reqs-01. > txt) as a ROLL WG document ? > > Thanks. > > JP. > > _______________________________________________ > 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 Apr 8 16:12:01 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D72673A6E3B; Tue, 8 Apr 2008 16:12:01 -0700 (PDT) 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 A6F7B3A6C23 for ; Tue, 8 Apr 2008 16:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.245 X-Spam-Level: X-Spam-Status: No, score=0.245 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1, 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 yDqIN05ob9+w for ; Tue, 8 Apr 2008 16:11:59 -0700 (PDT) Received: from mail.dustnetworks.com (66.237.74.130.ptr.us.xo.net [66.237.74.130]) by core3.amsl.com (Postfix) with ESMTP id 106313A6B85 for ; Tue, 8 Apr 2008 16:11:58 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Apr 2008 16:12:42 -0700 Message-ID: <9E9E6A5B6B547F4D8AFA7601E29508A706A7E2@dust-exch-01.dusthq.dust-inc.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Adoption of draft-dohler-roll-urban-routing-reqs-01.txt as a WG document ? Thread-Index: AciZqXwPunpgkwWcEd2IpwANk8WjQAAJFoiw From: "Chol Su Kang" To: Subject: Re: [Roll] Adoption of draft-dohler-roll-urban-routing-reqs-01.txt as a WG 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org I am in favor. Chol Su Kang -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Tuesday, April 08, 2008 11:51 AM To: roll@ietf.org Subject: [Roll] Adoption of draft-dohler-roll-urban-routing-reqs-01.txt as a WG document ? Dear WG, Could you please let us know whether you are in favor or opposed to adopting draft-dohler-roll-urban-routing-reqs-01.txt ( http://www.ietf.org/internet-drafts/draft-dohler-roll-urban-routing-reqs -01. txt) as a ROLL WG document ? Thanks. JP. _______________________________________________ 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 Apr 8 21:59:24 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BDD53A6B3F; Tue, 8 Apr 2008 21:59:24 -0700 (PDT) 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 BB9893A6A99 for ; Tue, 8 Apr 2008 21:59:23 -0700 (PDT) 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 Eq9T1eyjf8Qo for ; Tue, 8 Apr 2008 21:59:22 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by core3.amsl.com (Postfix) with ESMTP id A052C3A6A23 for ; Tue, 8 Apr 2008 21:59:22 -0700 (PDT) Received: from [192.168.2.38] (c-24-4-149-226.hsd1.ca.comcast.net [24.4.149.226]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.2/8.13.5) with ESMTP id m394xaIq010657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Apr 2008 21:59:38 -0700 (PDT) Message-ID: <47FC4DA3.2080201@eecs.berkeley.edu> Date: Tue, 08 Apr 2008 22:01:23 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Telemaco Melia (tmelia)" References: <47F157A3.3080704@eecs.berkeley.edu> In-Reply-To: Cc: roll@ietf.org Subject: Re: [Roll] industrial requirements (was...) 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="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Telemaco - Multi-path routing: definitely needed for reliability in industrial Multi-topology routing: definitely needed to handle different traffic = classes. Having different routes for different traffic classes with different = metrics is important, as you point out. Consider a case where I have many nodes sharing bandwidth allocated for = alarms. The alarms happen infrequently, and are uncorrelated, but when = they happen I need to know within some number of seconds. This is a case = where a route with lots of multi-path redundancy on CSMA or aloha links = makes a lot of sense, and I will allocate some of my precious microAmps = to making available some low-latency bandwidth which may never be used. = In this same network, I may need to do a daily upload of a 30kB log file = from each node. I definitely do not want that traffic clogging up my = low-latency bandwidth. The individual log file data can probably be sent = over a direct route with little or no multi-path redundancy, since over = the time of the upload the link reliabilities should be relatively static. So I have different flows with different routing requirments, and = different layer 2 provisioning to support them. I know that we're not = supposed to talk about layer 2 here, but I think that it's a critical = part (and a novel part?) of the challenge for RoLL to solve these = different routing problems in the context of this very weird layer 2. Another example: it's simple for a node to announce "I can only support = X microAmps average current", or maybe report that in terms how how many = packets per second it can forward, or how many times per second it can = listen for a packet. Turning that into a optimal routes, for regular = data or alarms, which respect the limits of all of the nodes in the = network seems like it's probably a well-understood problem. But when I = throw in a route request for a high-speed file transfer, which only = happens once every 24 hours for just a handful of seconds, but burns way = more than X microAmps during that time... Do I deny the routing request? = Or provide routes and then delete them after a certain amount of packets = have flowed over them? ksjp Telemaco Melia (tmelia) wrote: > HI all, > Sorry to jump in the middle of this discussion but I would like to = > clarify the difference between multi path routing and multi topology = > routing. > The former is the ability to maintain, mainly for reliability = > purposes, different routing paths between a source and destination. > The latter, as stated by JP, refers to the ability to maintain = > multiple topologies for different purposes. > Correct? > Would it also be correct to assume that between a source a destination = > you might have several paths depending on the metric you are considering: > - reliability > - low latency > - bandwidth > - ... > If yes then I guess the text of section 5.1 and 5.7 should be clarified. > What do you think? > Cheers > Telemaco > > ------------------------------------------------------------------------ > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On = > Behalf Of *Jean Philippe Vasseur (jvasseur) > *Sent:* Tuesday, April 01, 2008 12:24 AM > *To:* Kris Pister > *Cc:* roll@ietf.org > *Subject:* Re: [Roll] industrial requirements (was...) > > Hi Kris, > > See JP2> > > > ------------------------------------------------------------------------ > *From: *Kris Pister > *Date: *Mon, 31 Mar 2008 14:29:07 -0700 > *To: *JP Vasseur > *Cc: * > *Subject: *Re: [Roll] industrial requirements (was...) > > JP Vasseur wrote: > > Re: [Roll] [manet] Discussion on draft [...] > The early deployments in industrial are all around getting data > back to one or more sinks. Increasingly over time, these sinks > will be a part of a backbone (today they're often > fragmented/isolated). This function is likely to always be an > important function of the network. > > JP> Which means that you need both in the requirement document. > > They're both in there. e.g. " Most low power and lossy network systems = > [in industrial] in the near future will be for low frequency data = > collection." > "The routing protocol MUST support multiple paths (a tree-based = > solution is not sufficient)." > "Thus, the routing protocol for L2Ns MUST support multi-topology = > routing (e.g especially critical for critical control applications)." > > > JP2> Multi-topology routing is different though: it refers to the > ability to support multiple topologies (e.g., one for low latency, > one for high bandwidth): is this what you want ? > > On-demand internal routes will become more prevalent over time. > Some of the on-demand routes will last for years/decades. Internal > routes will often be the most critical, optimized and > well-maintained (I think that this was where I lost sync: with > your statement that they might be less optimized and less well > maintained). > > JP> Just make sure to stay solution-agnostic in the requirement > document. > > I think that we're largely solution-agnostic in -00, but a lot of = > people of appropriately complained about the repeated references to = > L2. I'm not trying to make this a HART-like document, or an = > ISA100-like document, so I'll yank all of the slotted-link and = > 15.4-specific stuff out of there. At the same time, I think that there = > are important underlying issues here that require some clever thinking = > at layer 3 to deal with what's going on in layer 2, > > JP2> The following WG item should help you there: > Nov 2008 Submit Routing metrics for LLNs document to the IESG to be = > considered as a Proposed Standard. > Link routing metric could be derived from the layer-2 characteristics. > > and relate both to what layer 4 needs. > Zach's email from 11/29 asked if routing metrics can serve as enough = > of an L2 abstraction, or if we need some kind of interactive = > relationship. I don't know the answer to that question, but I'd sure = > like to hear some good ideas. > > JP2> For sure, we=92ll need to have some discussions on this in the = > document referenced above. I tend to suggest to first progress on the = > requirements documents though. > > Thanks, > > Cheers. > > JP. > > ksjp > > > ------------------------------------------------------------------------ > _______________________________________________ > 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 Apr 8 23:06:07 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0F1E3A6EF5; Tue, 8 Apr 2008 23:06:06 -0700 (PDT) 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 8431F3A6B20 for ; Tue, 8 Apr 2008 23:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.215 X-Spam-Level: X-Spam-Status: No, score=-4.215 tagged_above=-999 required=5 tests=[AWL=2.157, BAYES_00=-2.599, 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 ITiAz+0ejejG for ; Tue, 8 Apr 2008 23:06:00 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5113A3A6EFE for ; Tue, 8 Apr 2008 23:05:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,627,1199660400"; d="scan'208";a="5749124" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Apr 2008 08:05:27 +0200 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 m3965Rv1019364 for ; Wed, 9 Apr 2008 08:05:27 +0200 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 m3965RjQ010831 for ; Wed, 9 Apr 2008 06:05:27 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); Wed, 9 Apr 2008 08:05:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Apr 2008 08:04:45 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05808AE4@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Adoption of draft-dohler-roll-urban-routing-reqs-01.txt as a WG document ? thread-index: AciZqXwPunpgkwWcEd2IpwANk8WjQAAXhmUQ From: "Pascal Thubert (pthubert)" To: "Jean Philippe Vasseur (jvasseur)" , X-OriginalArrivalTime: 09 Apr 2008 06:05:27.0568 (UTC) FILETIME=[B5355900:01C89A07] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=726; t=1207721127; x=1208585127; 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]=20Adoption=20of=20draft-dohler-r oll-urban-routing-reqs-01.txt=20as=20a=20WG=20document=20? |Sender:=20; bh=h1S3Xw8I2Ha2/aM8ODxw200LFxXOiX7FVh8R6N+wiFg=; b=VAjYzrSuqRfJEu+VwTPwNWeq7JHFY8HzqOmWcUMZUcxx+dxXpD0pZyxiaB v99JMEfVqtAvQQmLQ+pjsklXKtErpb+qL4KG6HioxWkzjNKcER+yRzAH1WkO /QpEtpl/9m; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [Roll] Adoption of draft-dohler-roll-urban-routing-reqs-01.txt as a WG 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org I'm in favor, Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jean Philippe Vasseur >(jvasseur) >Sent: mardi 8 avril 2008 20:51 >To: roll@ietf.org >Subject: [Roll] Adoption of draft-dohler-roll-urban-routing-reqs-01.txt as a WG document ? > >Dear WG, > >Could you please let us know whether you are in favor or opposed to adopting >draft-dohler-roll-urban-routing-reqs-01.txt ( >http://www.ietf.org/internet-drafts/draft-dohler-roll-urban-routing-req s-01. >txt) as a ROLL WG document ? > >Thanks. > >JP. > >_______________________________________________ >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 Wed Apr 9 00:31:19 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D21A3A6AAD; Wed, 9 Apr 2008 00:31:19 -0700 (PDT) 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 EE8D028C450 for ; Wed, 9 Apr 2008 00:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_101=0.6, RCVD_IN_DNSWL_LOW=-1, 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 HYrtoYQiTp1U for ; Wed, 9 Apr 2008 00:31:18 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id B0B8A3A6F0C for ; Wed, 9 Apr 2008 00:30:54 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Apr 2008 09:31:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Apr 2008 09:31:09 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Adoption of draft-dohler-roll-urban-routing-reqs-01.txt as aWG document ? Thread-Index: AciZqXwPunpgkwWcEd2IpwANk8WjQAAahqtA References: From: To: X-OriginalArrivalTime: 09 Apr 2008 07:31:10.0887 (UTC) FILETIME=[AEDD8B70:01C89A13] Subject: Re: [Roll] Adoption of draft-dohler-roll-urban-routing-reqs-01.txt as aWG 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org I am in favor. Madhusudan,G. -----Message d'origine----- De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de JP = Vasseur Envoy=E9 : mardi 8 avril 2008 20:51 =C0 : roll@ietf.org Objet : [Roll] Adoption of draft-dohler-roll-urban-routing-reqs-01.txt as a= WG document ? Dear WG, Could you please let us know whether you are in favor or opposed to adoptin= g draft-dohler-roll-urban-routing-reqs-01.txt ( http://www.ietf.org/interne= t-drafts/draft-dohler-roll-urban-routing-reqs-01. txt) as a ROLL WG document ? Thanks. JP. _______________________________________________ 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 Wed Apr 9 00:51:21 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA21F3A6F03; Wed, 9 Apr 2008 00:51:21 -0700 (PDT) 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 EB1903A6EF4 for ; Wed, 9 Apr 2008 00:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 7FGz2YjWQpHd for ; Wed, 9 Apr 2008 00:51:20 -0700 (PDT) Received: from mailf.telecomitalia.it (mailf.telecomitalia.it [156.54.233.32]) by core3.amsl.com (Postfix) with ESMTP id D27333A6C99 for ; Wed, 9 Apr 2008 00:51:19 -0700 (PDT) Received: from ptpxch010ba020.idc.cww.telecomitalia.it ([156.54.240.53]) by mailf.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Apr 2008 09:51:37 +0200 Received: from PTPTMP101BA020.idc.cww.telecomitalia.it ([156.54.240.116]) by ptpxch010ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Apr 2008 09:51:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Apr 2008 09:48:23 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Roll Digest, Vol 3, Issue 4 Thread-Index: AciZq5URRjf9nEpORRy7bvuzIl6AfAAaoGA7 References: From: "Porcu Giorgio" To: , X-OriginalArrivalTime: 09 Apr 2008 07:51:36.0760 (UTC) FILETIME=[898AEB80:01C89A16] Subject: [Roll] R: Roll Digest, Vol 3, Issue 4 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 Hi all, I'm in favor. Giorgio ________________________________ Da: roll-bounces@ietf.org per conto di roll-request@ietf.org Inviato: mar 08/04/2008 21.00 A: roll@ietf.org Oggetto: Roll Digest, Vol 3, Issue 4 Send Roll mailing list submissions to roll@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/roll or, via email, send a message with subject or body 'help' to roll-request@ietf.org You can reach the person managing the list at roll-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Roll digest..." Today's Topics: 1. FYI The rsn@ietf.org mailing list has be decommissioned (JP Vasseur) 2. Adoption of draft-dohler-roll-urban-routing-reqs-01.txt as a WG document ? (JP Vasseur) ---------------------------------------------------------------------- Message: 1 Date: Tue, 08 Apr 2008 11:02:47 -0400 From: JP Vasseur Subject: [Roll] FYI The rsn@ietf.org mailing list has be decommissioned To: Message-ID: Content-Type: text/plain; charset="US-ASCII" ------------------------------ Message: 2 Date: Tue, 08 Apr 2008 14:50:59 -0400 From: JP Vasseur Subject: [Roll] Adoption of draft-dohler-roll-urban-routing-reqs-01.txt as a WG document ? To: Message-ID: Content-Type: text/plain; charset="US-ASCII" Dear WG, Could you please let us know whether you are in favor or opposed to adopting draft-dohler-roll-urban-routing-reqs-01.txt ( http://www.ietf.org/internet-drafts/draft-dohler-roll-urban-routing-reqs-01. txt) as a ROLL WG document ? Thanks. JP. ------------------------------ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll End of Roll Digest, Vol 3, Issue 4 ********************************** _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Apr 9 01:02:36 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03FDF3A68AF; Wed, 9 Apr 2008 01:02:36 -0700 (PDT) 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 3B2E63A6AD4 for ; Wed, 9 Apr 2008 01:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.183 X-Spam-Level: X-Spam-Status: No, score=-6.183 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, 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 ph7m5d3Jo6mF for ; Wed, 9 Apr 2008 01:02:34 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DC9613A6967 for ; Wed, 9 Apr 2008 01:02:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,628,1199660400"; d="scan'208";a="5761509" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 09 Apr 2008 10:02:50 +0200 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 m3982oPM023735 for ; Wed, 9 Apr 2008 10:02:50 +0200 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 m3982oRZ014691 for ; Wed, 9 Apr 2008 08:02:50 GMT Received: from xmb-ams-335.cisco.com ([144.254.231.80]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Apr 2008 10:02:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Apr 2008 10:03:36 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Adoption of draft-dohler-roll-urban-routing-reqs-01.txt as a WG document ? Thread-Index: AciZqXwPunpgkwWcEd2IpwANk8WjQAAbrGCQ References: From: "Telemaco Melia (tmelia)" To: "Jean Philippe Vasseur (jvasseur)" , X-OriginalArrivalTime: 09 Apr 2008 08:02:50.0403 (UTC) FILETIME=[1B10AF30:01C89A18] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=713; t=1207728170; x=1208592170; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tmelia@cisco.com; z=From:=20=22Telemaco=20Melia=20(tmelia)=22=20 |Subject:=20RE=3A=20[Roll]=20Adoption=20of=20draft-dohler-r oll-urban-routing-reqs-01.txt=20as=20a=20WG=20document=20? |Sender:=20; bh=2jJPFQXTwOHq4IBvJ+CLvOScqssOniC09/cJKawMv6o=; b=vVrgfZq9XS1vwjypkMIjYQu6VY9kbAdiAj0RI1TECh89OAyfJy3B2FmmGN 1ErIsK8GUHxz/13Lw1goUsujUS5zgjCDjxQS++SQIL+Hp/3axYQLXFpHVxYs NDwOUtiB6p; Authentication-Results: ams-dkim-2; header.From=tmelia@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [Roll] Adoption of draft-dohler-roll-urban-routing-reqs-01.txt as a WG 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org I am in favor. Telemaco -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jean Philippe Vasseur (jvasseur) Sent: Tuesday, April 08, 2008 8:51 PM To: roll@ietf.org Subject: [Roll] Adoption of draft-dohler-roll-urban-routing-reqs-01.txt as a WG document ? Dear WG, Could you please let us know whether you are in favor or opposed to adopting draft-dohler-roll-urban-routing-reqs-01.txt ( http://www.ietf.org/internet-drafts/draft-dohler-roll-urban-routing-reqs -01. txt) as a ROLL WG document ? Thanks. JP. _______________________________________________ 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 Wed Apr 9 07:02:46 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 600B03A6B8E; Wed, 9 Apr 2008 07:02:46 -0700 (PDT) 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 34A4528C466 for ; Wed, 9 Apr 2008 06:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 bnPdI6W-qkRc for ; Wed, 9 Apr 2008 06:46:24 -0700 (PDT) Received: from coe.drexel.edu (cbis.ece.drexel.edu [129.25.60.1]) by core3.amsl.com (Postfix) with ESMTP id 58BCA28C416 for ; Wed, 9 Apr 2008 06:46:24 -0700 (PDT) Received: from [192.168.0.198] (c-68-45-82-154.hsd1.pa.comcast.net [68.45.82.154]) (authenticated bits=0) by coe.drexel.edu (8.13.6/8.13.4) with ESMTP id m39Do9hA003112; Wed, 9 Apr 2008 09:50:09 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Jaudelice de Oliveira Date: Wed, 9 Apr 2008 09:46:31 -0400 To: JP Vasseur X-Mailer: Apple Mail (2.753) X-Scanned-By: MIMEDefang 2.51 on 129.25.60.1 X-Mailman-Approved-At: Wed, 09 Apr 2008 07:02:44 -0700 Cc: roll@ietf.org Subject: Re: [Roll] Adoption of draft-dohler-roll-urban-routing-reqs-01.txt as a WG 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org In favor... Cheers, Jau. On Apr 8, 2008, at 2:50 PM, JP Vasseur wrote: > Dear WG, > > Could you please let us know whether you are in favor or opposed to > adopting > draft-dohler-roll-urban-routing-reqs-01.txt ( > http://www.ietf.org/internet-drafts/draft-dohler-roll-urban-routing- > reqs-01. > txt) as a ROLL WG document ? > > Thanks. > > JP. > > _______________________________________________ > 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 Wed Apr 9 09:46:50 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68A4528C48C; Wed, 9 Apr 2008 09:46:50 -0700 (PDT) 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 05F3528C40F for ; Wed, 9 Apr 2008 09:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 h1IvllW2ealS for ; Wed, 9 Apr 2008 09:46:48 -0700 (PDT) Received: from auswood.securesites.net (auswood.securesites.net [128.121.62.173]) by core3.amsl.com (Postfix) with ESMTP id 323E628C466 for ; Wed, 9 Apr 2008 09:46:45 -0700 (PDT) Received: from [192.168.2.78] (adsl-99-163-7-131.dsl.pltn13.sbcglobal.net [99.163.7.131]) (authenticated bits=0) by auswood.securesites.net (8.13.6.20060614/8.13.6) with ESMTP id m39Gl1W0014115 for ; Wed, 9 Apr 2008 16:47:01 GMT Message-Id: <1BBB495E-04DD-4D0A-A09F-529E55FF2CFB@daintree.net> From: Zachary Smith To: roll@ietf.org In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 9 Apr 2008 09:47:01 -0700 References: X-Mailer: Apple Mail (2.919.2) Subject: Re: [Roll] Adoption of draft-dohler-roll-urban-routing-reqs-01.txt as a WG 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hey all, I'm new to this list (and indeed to this whole domain) so forgive me if I do or say something stupid. The draft is fine and I'm in favor of adopting it. I have to say it reads in some places more like an engineering solutions document and less like a requirements document - e.g. the singling out of repeaters as a distinguished device type - but those are the kinds of things that can be worked out, as necessary, in the process. Anyway. I am certain I have already said too much ;-) z On Apr 9, 2008, at 6:46 AM, Jaudelice de Oliveira wrote: > In favor... > > Cheers, > Jau. > > On Apr 8, 2008, at 2:50 PM, JP Vasseur wrote: > >> Dear WG, >> >> Could you please let us know whether you are in favor or opposed to >> adopting >> draft-dohler-roll-urban-routing-reqs-01.txt ( >> http://www.ietf.org/internet-drafts/draft-dohler-roll-urban-routing- >> reqs-01. >> txt) as a ROLL WG document ? >> >> Thanks. >> >> JP. >> >> _______________________________________________ >> 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 Zachary Smith - CTO http://www.daintree.net/ zsmith@daintree.net _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Apr 9 09:51:27 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45AD63A6ECA; Wed, 9 Apr 2008 09:51:27 -0700 (PDT) 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 388333A6E85 for ; Wed, 9 Apr 2008 09:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.242 X-Spam-Level: X-Spam-Status: No, score=-1.242 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 o4PY2Cj2qDBn for ; Wed, 9 Apr 2008 09:51:22 -0700 (PDT) Received: from bullseye.xbow.com (bullseye.xbow.com [72.3.142.148]) by core3.amsl.com (Postfix) with ESMTP id 682E43A6D93 for ; Wed, 9 Apr 2008 09:51:22 -0700 (PDT) Received: from mail.xbow.com ([63.64.55.211]) by bullseye.xbow.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Apr 2008 09:51:38 -0700 X-Ninja-PIM: Scanned by Ninja X-Ninja-AttachmentFiltering: (no action) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Apr 2008 09:51:31 -0700 Message-ID: In-Reply-To: Thread-Topic: [Roll] Adoption of draft-dohler-roll-urban-routing-reqs-01.txt as a WG document ? Thread-Index: AciZqXwPunpgkwWcEd2IpwANk8WjQAAuHQVA References: From: "Ralph Kling" To: "JP Vasseur" , X-OriginalArrivalTime: 09 Apr 2008 16:51:38.0515 (UTC) FILETIME=[FA7E5E30:01C89A61] Subject: Re: [Roll] Adoption of draft-dohler-roll-urban-routing-reqs-01.txt as a WG 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org In favor - Ralph -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Tuesday, April 08, 2008 11:51 AM To: roll@ietf.org Subject: [Roll] Adoption of draft-dohler-roll-urban-routing-reqs-01.txt as a WG document ? Dear WG, Could you please let us know whether you are in favor or opposed to adopting draft-dohler-roll-urban-routing-reqs-01.txt ( http://www.ietf.org/internet-drafts/draft-dohler-roll-urban-routing-reqs -01. txt) as a ROLL WG document ? Thanks. JP. _______________________________________________ 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 Wed Apr 9 11:16:48 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 448E828C1FB; Wed, 9 Apr 2008 11:16:48 -0700 (PDT) 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 7FD7128C1FB; Wed, 9 Apr 2008 11:16:47 -0700 (PDT) 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 Ykwr11ZSEZ7l; Wed, 9 Apr 2008 11:16:46 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 44CA828C14C; Wed, 9 Apr 2008 11:16:46 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 09 Apr 2008 11:17:05 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m39IH5se026482; Wed, 9 Apr 2008 11:17:05 -0700 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m39IH56X013965; Wed, 9 Apr 2008 18:17:05 GMT Received: (from achandra@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA18140; Wed, 9 Apr 2008 11:14:28 -0700 (PDT) Date: Wed, 9 Apr 2008 11:14:28 -0700 From: Chandrashekhar Appanna To: Philip Levis Message-ID: <20080409181428.GB28983@cisco.com> References: <97E4819D-602B-45ED-97BA-3CA9E130E919@cs.stanford.edu> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <97E4819D-602B-45ED-97BA-3CA9E130E919@cs.stanford.edu> User-Agent: Mutt/1.4i DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1397; t=1207765025; x=1208629025; 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]=20Discussion=20on=20draft |Sender:=20; bh=/kPI8dm4ntQtcFn3Jj9DyszmySezcbeSHGTlD4/Iqug=; b=wPkca+z2oG3G2DmwUMZFaa67Q1Pmo+HnJw6SLIVljKmcXATlYVgsktD01D yLgNV/sF0T0Hiz1ZQX88Kiz/maIaIO+cR6hB59ltUNxfhYqZPI/LZgXF8zxG pfM5BWhyEF; Authentication-Results: sj-dkim-2; header.From=achandra@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: roll@ietf.org, manet manet Subject: Re: [Roll] Discussion on 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi, The big elephant, BGP is missing. I think we should add it in if especially you want to cover all IETF protocols. There have been instances of folks tinkering with BGP for such applications too. I can provide some text to cover BGP.. let me know. Rgds, Chandra. On Thu, Mar 27, 2008 at 08:43:12PM -0700, Philip Levis wrote: > I'd like to start a discussion on draft-levis-roll-overview-protocols. > In particular, Section 5.8 has a table of several existing protocols > and their properties. This table is really going to be critical in > ROLL's assessment of existing technologies and protocols, so we want > to make sure that > > 1) It has the relevant data points to compare (protocols/rows) > 2) It distills what the important properties are(columns) > 3) It accurately captures the properties of the values in question > (cells are accurate) > > Let's start with 1), as it's probably the simplest. Are there any > protocols that we should be including that aren't there? Trying to > cover every single minor protocol tweak is a recipe for disaster, but > protocols that differ significantly from those currently there, either > in mechanism or in properties, are important to include. > > 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 roll-bounces@ietf.org Wed Apr 9 11:54:20 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 352823A6F04; Wed, 9 Apr 2008 11:54:20 -0700 (PDT) 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 124543A6F04; Wed, 9 Apr 2008 11:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.114, 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 945eHFjMOny5; Wed, 9 Apr 2008 11:54:18 -0700 (PDT) Received: from auswood.securesites.net (auswood.securesites.net [128.121.62.173]) by core3.amsl.com (Postfix) with ESMTP id 14FF93A6F00; Wed, 9 Apr 2008 11:54:18 -0700 (PDT) Received: from [192.168.2.78] (adsl-99-163-7-131.dsl.pltn13.sbcglobal.net [99.163.7.131]) (authenticated bits=0) by auswood.securesites.net (8.13.6.20060614/8.13.6) with ESMTP id m39IsSxE054855; Wed, 9 Apr 2008 18:54:28 GMT Message-Id: From: Zachary Smith To: Chandrashekhar Appanna In-Reply-To: <20080409181428.GB28983@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 9 Apr 2008 11:54:27 -0700 References: <97E4819D-602B-45ED-97BA-3CA9E130E919@cs.stanford.edu> <20080409181428.GB28983@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: roll@ietf.org, manet manet Subject: Re: [Roll] Discussion on 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Apr 9, 2008, at 11:14 AM, Chandrashekhar Appanna wrote: >> Let's start with 1), as it's probably the simplest. Are there any >> protocols that we should be including that aren't there? I was struck by the lack of simple hierarchical protocols for the wireless domain - in the style of Cluster Tree. These have the benefits of generally requiring low resources on the device and low discovery overhead but, of course, when things go wrong they can be hard to repair. Just a thought. z Zachary Smith - CTO http://www.daintree.net/ zsmith@daintree.net _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Apr 9 12:02:10 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE29C3A6EFB; Wed, 9 Apr 2008 12:02:10 -0700 (PDT) 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 A0FF93A6EFB; Wed, 9 Apr 2008 12:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.392 X-Spam-Level: X-Spam-Status: No, score=-4.392 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 Rj-auKDxX-MW; Wed, 9 Apr 2008 12:02:07 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 47ECD28C2EC; Wed, 9 Apr 2008 12:01:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,630,1199692800"; d="scan'208";a="20799098" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 09 Apr 2008 12:01:58 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m39J1wBV015759; Wed, 9 Apr 2008 12:01:58 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m39J1qOJ023297; Wed, 9 Apr 2008 19:01:58 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Apr 2008 15:01:57 -0400 Received: from 161.44.71.234 ([161.44.71.234]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 9 Apr 2008 19:01:57 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 09 Apr 2008 15:01:54 -0400 From: JP Vasseur To: Zachary Smith , Chandrashekhar Appanna Message-ID: Thread-Topic: [Roll] Discussion on draft Thread-Index: AciadCzia1T2cAZnEd2YNwANk8WjQA== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 09 Apr 2008 19:01:57.0635 (UTC) FILETIME=[2F0D6530:01C89A74] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1180; t=1207767718; x=1208631718; c=relaxed/simple; s=sjdkim3002; 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]=20Discussion=20on=20draft |Sender:=20; bh=spz+9awD2d9EcNYdA3iv1eur5dv1wOhzS4ZtIoUC8Cs=; b=BU/Pp5jztAfFqWopVIoRXxTorNZx+/8e5ks2UiDpXncmBPWhmun/b6YeLk Xh0G3vuzj8BH+KiXZW13hNSmrBXIgJNsyVZV4+rK0nkL6hUDlYT0C6W/FxLB Z8z8PC1cxU; Authentication-Results: sj-dkim-3; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: roll@ietf.org, manet manet Subject: Re: [Roll] Discussion on 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > From: Zachary Smith > Date: Wed, 9 Apr 2008 11:54:27 -0700 > To: Chandrashekhar Appanna > Cc: , manet manet > Subject: Re: [Roll] Discussion on draft > > > On Apr 9, 2008, at 11:14 AM, Chandrashekhar Appanna wrote: > >>> Let's start with 1), as it's probably the simplest. Are there any >>> protocols that we should be including that aren't there? > > > I was struck by the lack of simple hierarchical protocols for the > wireless domain - in the style of Cluster Tree. These have the > benefits of generally requiring low resources on the device and low > discovery overhead but, of course, when things go wrong they can be > hard to repair. With the usual trade-off between "optimality" and "scalability". Yes, hierarchy will definitely be discussed in the Routing Architecture document. Thanks. JP > > Just a thought. > > z > > Zachary Smith - CTO > http://www.daintree.net/ > zsmith@daintree.net > > > > _______________________________________________ > 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 Wed Apr 9 13:41:40 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CB7128C2DF; Wed, 9 Apr 2008 13:41:40 -0700 (PDT) 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 B905C28C1A5; Wed, 9 Apr 2008 13:41:37 -0700 (PDT) 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 bOCP2Srw+YCP; Wed, 9 Apr 2008 13:41:36 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id D693328C195; Wed, 9 Apr 2008 13:41:36 -0700 (PDT) Received: from dn0a4220e0.sunet ([10.66.32.224]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Jjh7D-0005kz-PV; Wed, 09 Apr 2008 13:41:55 -0700 Message-Id: From: Philip Levis To: Chandrashekhar Appanna In-Reply-To: <20080409181428.GB28983@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 9 Apr 2008 13:41:55 -0700 References: <97E4819D-602B-45ED-97BA-3CA9E130E919@cs.stanford.edu> <20080409181428.GB28983@cisco.com> X-Mailer: Apple Mail (2.919.2) X-Scan-Signature: 6bee508a35d8245455fa42c2dd36c733 Cc: roll@ietf.org, manet manet Subject: Re: [Roll] Discussion on 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Apr 9, 2008, at 11:14 AM, Chandrashekhar Appanna wrote: > Hi, > > The big elephant, BGP is missing. I think we should add it in > if especially you want to cover all IETF protocols. There have > been instances of folks tinkering with BGP for such applications > too. > > I can provide some text to cover BGP.. let me know. Whoops! I guess I didn't add enough qualifications to my statement. Understandably, the document is trying to address internal routing protocols (within an administrative domain, i.e., IGPs), not gateway protocols between administrative domains (BGP, EGP, etc.). The requirements for the latter are sufficiently different that it's a bit of apples and oranges. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Apr 9 16:39:30 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1466A28C232; Wed, 9 Apr 2008 16:39:30 -0700 (PDT) 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 E2CC73A6C41; Wed, 9 Apr 2008 16:39:28 -0700 (PDT) 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 8ElPln9S4h+O; Wed, 9 Apr 2008 16:39:28 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B92403A6D98; Wed, 9 Apr 2008 16:39:27 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 09 Apr 2008 16:39:47 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m39NdlNk013224; Wed, 9 Apr 2008 16:39:47 -0700 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m39NdkKv001359; Wed, 9 Apr 2008 23:39:46 GMT Received: (from achandra@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA01854; Wed, 9 Apr 2008 16:37:11 -0700 (PDT) Date: Wed, 9 Apr 2008 16:37:11 -0700 From: Chandrashekhar Appanna To: Philip Levis Message-ID: <20080409233711.GM28983@cisco.com> References: <97E4819D-602B-45ED-97BA-3CA9E130E919@cs.stanford.edu> <20080409181428.GB28983@cisco.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1409; t=1207784387; x=1208648387; c=relaxed/simple; s=sjdkim1004; 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]=20Discussion=20on=20draft |Sender:=20; bh=ozbwls8XkSwDa0AS2ppz2GIqxyRuNHoWh8EbaE6KlEk=; b=f6c+QgMqmk8GhiG8yxrlj2xc38AYURzNoShvjAO7R7wiO158n/7JM6pAb7 wdbVuanqdXBUqe+F8WaX6O4lmHnrUwXXnPPI6CGEzfFmVG4Dbz5lT6y5UL7G kslaVMaMtHEw1iZIhJL1TFA6ZJoj/1BOUh5zZK2vt2kXDV3gjGGbg=; Authentication-Results: sj-dkim-1; header.From=achandra@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: roll@ietf.org, manet manet Subject: Re: [Roll] Discussion on 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Wed, Apr 09, 2008 at 01:41:55PM -0700, Philip Levis wrote: > > On Apr 9, 2008, at 11:14 AM, Chandrashekhar Appanna wrote: > >Hi, > > > >The big elephant, BGP is missing. I think we should add it in > >if especially you want to cover all IETF protocols. There have > >been instances of folks tinkering with BGP for such applications > >too. > > > >I can provide some text to cover BGP.. let me know. > > Whoops! I guess I didn't add enough qualifications to my statement. > Understandably, the document is trying to address internal routing > protocols (within an administrative domain, i.e., IGPs), not gateway > protocols between administrative domains (BGP, EGP, etc.). The > requirements for the latter are sufficiently different that it's a bit > of apples and oranges. > I do not think it comes out like that.. esp that you have a section of distance vector protocols and BGP is used a lot in many such scenarios too. I have personally been involved in discussions about using BGP in many of scenarios we have discussed in the requirements.. so even if it is to prevent further propagation of that it would be good to list it in there. BGP is used as both iBGP and eBGP.. However, your angle is also ok in that it is consistent.. though I have not seen that mentioned till date and to me is was not obvious. Chandra. > Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Apr 10 04:26:55 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C5E03A6B21; Thu, 10 Apr 2008 04:26:55 -0700 (PDT) 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 31B263A6CBF for ; Thu, 10 Apr 2008 04:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 wL3k-XWrc8R1 for ; Thu, 10 Apr 2008 04:26:44 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id C4CA03A6975 for ; Thu, 10 Apr 2008 04:26:43 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so2699738fgg.41 for ; Thu, 10 Apr 2008 04:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:mime-version:to:message-id:content-type:from:subject:date:x-mailer; bh=tjSXTP9NCDzzC84qb+yXlyXtDBjhCuL+dfjeXQsjcJ0=; b=DtQ5vsqaTFVN0qSGPcvZrARnDft5daBo5lt0T1mSdwN4KU30cgeZHFIhK/FU0Jq3ZOAaf+RvoNcoEDdgdkKKETaJ90S6/zdQC/xk/uo/3dhIwtKWtS025BMnYLIcEilWVDOFHykiFYNeIg0sJoZ0X7T2P7MVUwIQIsY4VAedhfo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:to:message-id:content-type:from:subject:date:x-mailer; b=d4LE9u43ESQbgQZGfMHCPeLAe4he80NhOA0lCy0aLtK3kqSHh1YFGjMddpSwVM/29iiLtPgCp2shbzZWwbtO7S09mBRbLdzktl5R6LSH16VMRPaR3veINYlIyq44VO61GahtQkwsh2pAqMvkptsb6Tl/ZbiV++lBI3QMPZ1+tjg= Received: by 10.86.50.8 with SMTP id x8mr2863179fgx.25.1207826822761; Thu, 10 Apr 2008 04:27:02 -0700 (PDT) Received: from ?193.1.133.89? ( [193.1.133.89]) by mx.google.com with ESMTPS id d4sm1268019fga.2.2008.04.10.04.27.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 Apr 2008 04:27:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753) To: roll@ietf.org Message-Id: From: Antonio Date: Thu, 10 Apr 2008 12:26:57 +0100 X-Mailer: Apple Mail (2.753) Subject: [Roll] draft-dohler-roll-urban-routing-reqs-01.txt as a WG 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: , Content-Type: multipart/mixed; boundary="===============1369335557==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1369335557== Content-Type: multipart/alternative; boundary=Apple-Mail-14--261132983 --Apple-Mail-14--261132983 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed I am also in favour of Dohler's draft. Regards, Antonio Ruzzelli ____________________________ Antonio G. Ruzzelli, ME, PhD University College Dublin, http://csserver.ucd.ie/~aruzzelli/ Tel: +353-17162488 --Apple-Mail-14--261132983 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 I am also in favour of=A0Dohler's= draft.

Regards,
Antonio = Ruzzelli=A0

Antonio = G. Ruzzelli, ME, PhD
University College = Dublin,
Tel: +353-17162488




=

= --Apple-Mail-14--261132983-- --===============1369335557== 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 --===============1369335557==-- From roll-bounces@ietf.org Thu Apr 10 09:59:57 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 179D13A6B5D; Thu, 10 Apr 2008 09:59:57 -0700 (PDT) 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 C06F33A68A8 for ; Thu, 10 Apr 2008 09:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.834 X-Spam-Level: X-Spam-Status: No, score=-3.834 tagged_above=-999 required=5 tests=[AWL=1.368, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 sB17Tx16sd1K for ; Thu, 10 Apr 2008 09:59:44 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 2BF883A6B5D for ; Thu, 10 Apr 2008 09:59:44 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 10 Apr 2008 10:00:05 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3AH05vT010484 for ; Thu, 10 Apr 2008 10:00:05 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m3AH04NJ017965 for ; Thu, 10 Apr 2008 17:00:05 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Apr 2008 13:00:04 -0400 Received: from 10.86.104.186 ([10.86.104.186]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 10 Apr 2008 17:00:04 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Thu, 10 Apr 2008 13:00:02 -0400 From: JP Vasseur To: Message-ID: Thread-Topic: IETF-72 Important Meeting Dates Thread-Index: AcibLFEBj1qNfQcfEd2YNwANk8WjQA== Mime-version: 1.0 X-OriginalArrivalTime: 10 Apr 2008 17:00:04.0820 (UTC) FILETIME=[52B02140:01C89B2C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4604; t=1207846805; x=1208710805; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20IETF-72=20Important=20Meeting=20Dates |Sender:=20; bh=aNBN4zZ9dAMfDFPmoORCRhHgu/7q1g+Yw7w8TWycLBY=; b=hqge/otlntVp1HWNcWnTzRPTBXzs0TT1gGDqe4sp5d69GBVFUIXjySOKE7 Do3F28ge5/mqfi88hVRg/W5a875oburFEBQdTxVSVWoaGLGfJdqEp/KR6a8y mQn56idzmL; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Roll] IETF-72 Important Meeting Dates 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="===============1757745649==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1757745649== Content-type: multipart/alternative; boundary="B_3290677202_10220489" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3290677202_10220489 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 72nd IETF Meeting July 27-August 1, 2008 Important Meeting Dates April 7 - IETF Online Registration is now open. April 28, Monday - Working Group and BOF scheduling begins. May 26, Monday - Cutoff date for requests to schedule Working Group meetings and for preliminary BOF proposals to ADs at 17:00 PDT (24:00 UTC/GMT). June 9, Monday - Cutoff date for requests to Area Directors to schedule BOFs at 17:00 PDT (24:00 UTC/GMT). June 16, Monday - Cutoff date for Area Directors to approve BOF requests at 17:00 PDT (24:00 UTC/GMT). June 20, Friday - Preliminary agenda published for comment. June 30, Monday - Working Group Chair approval for initial document (Version -00) submissions appreciated by 17:00 PDT (24:00 UTC/GMT) July 2, Wednesday - Cutoff date for requests to reschedule Working Group and BOF meetings 17:00 PDT (24:00 UTC/GMT) July 7, Monday - Final agenda to be published. July 7, Monday - Internet Draft Cut-off for initial document (-00) submission by 17:00 PDT (24:00 UTC/GMT), upload using IETF ID Submission Tool. July 14, Monday - Internet Draft final submission cut-off by 17:00 PDT (24:00 UTC/GMT), upload using IETF ID Submission Tool. July 16, Wednesday - Draft Working Group agendas due by 17:00 PDT (24:00 UTC/GMT). July 18, Friday - Early-Bird registration and payment cut-off at 17:00 PDT (24:00 UTC/GMT) July 21, Monday - Revised Working Group agendas due by 17:00 PDT (24:00 UTC/GMT). July 21, Monday - Registration cancellation cut-off at 17:00 PDT (24:00 UTC/GMT) July 25, Friday - Final Pre-Registration and Pre-Payment cut-off at 17:00 PDT (24:00 UTC/GMT) July 27 - August 1 - 72nd IETF Meeting in Dublin, Ireland August 29, Friday - Proceedings submission cutoff date by 17:00 PDT (24:00 UTC/GMT). September 17, Wednesday - Proceedings submission corrections cutoff date by 17:00 PDT (24:00 UTC/GMT). **** Times are in US Eastern Time and UTC/GMT **** **** Dates are subject to change **** --B_3290677202_10220489 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable IETF-72 Important Meeting Dates 72nd = IETF Meeting
July 27-August 1, 2008
Important Meeting Dates
April 7 - IETF Online Registration is now open.
April 28, Monday - Working Group and BOF scheduling begins.
May 26, Monday - Cutoff date for requests to schedule Working Group meeting= s and for preliminary BOF proposals to ADs at 17:00 PDT (24:00 UTC/GMT).
June 9, Monday - Cutoff date for requests to Area Directors to schedule BOF= s at 17:00 PDT (24:00 UTC/GMT).
June 16, Monday - Cutoff date for Area Directors to approve BOF requests at= 17:00 PDT (24:00 UTC/GMT).
June 20, Friday - Preliminary agenda published for comment.
June 30, Monday - Working Group Chair approval for initial document (Versio= n -00) submissions appreciated by 17:00 PDT (24:00 UTC/GMT)
July 2, Wednesday - Cutoff date for requests to reschedule Working Group an= d BOF meetings 17:00 PDT (24:00 UTC/GMT)
July 7, Monday - Final agenda to be published.
July 7, Monday - Internet Draft Cut-off for initial document (-00) submissi= on by 17:00 PDT (24:00 UTC/GMT), upload using IETF ID Submission Tool.
July 14, Monday - Internet Draft final submission cut-off by 17:00 PDT (24:= 00 UTC/GMT), upload using IETF ID Submission Tool.
July 16, Wednesday - Draft Working Group agendas due by 17:00 PDT (24:00 UT= C/GMT).
July 18, Friday - Early-Bird registration and payment cut-off at 17:00 PDT = (24:00 UTC/GMT)
July 21, Monday - Revised Working Group agendas due by 17:00 PDT (24:00 UTC= /GMT).
July 21, Monday - Registration cancellation cut-off at 17:00 PDT (24:00 UTC= /GMT)
July 25, Friday - Final Pre-Registration and Pre-Payment cut-off at 17:00 P= DT (24:00 UTC/GMT)
July 27 - August 1 - 72nd IETF Meeting in Dublin, Ireland
August 29, Friday - Proceedings submission cutoff date by 17:00 PDT (24:00 = UTC/GMT).
September 17, Wednesday - Proceedings submission corrections cutoff date by= 17:00 PDT (24:00 UTC/GMT).
**** Times are in US Eastern Time and UTC/GMT ****

**** Dates are subject to change **** --B_3290677202_10220489-- --===============1757745649== 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 --===============1757745649==-- From roll-bounces@ietf.org Fri Apr 11 00:16:23 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 539CF3A695D; Fri, 11 Apr 2008 00:16:23 -0700 (PDT) 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 04DC93A69A2 for ; Fri, 11 Apr 2008 00:16:22 -0700 (PDT) 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 mSOoRVS7EFRJ for ; Fri, 11 Apr 2008 00:16:21 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by core3.amsl.com (Postfix) with ESMTP id 6237A3A689C for ; Fri, 11 Apr 2008 00:16:20 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 19so411868fkr.5 for ; Fri, 11 Apr 2008 00:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=5RVoPGUrhOmPGv6/eJQpRIjVppa9AXcs4vjUeFsANNM=; b=wbovHY5i88GPq7d8neKtQ249ER2ldUxMARy9IZ1ISxCqWwvo9DsLhdMX/aI1oN1d4lJcD0toT3xPVCWslaLboDaRSRv9rbgLP+B6JXi6BaZGrA+naImFSVRV+IfKpPZU8K8M0hex2kfsV02tHFbZ72/Tv8bUzx3oUqhdL1dHfTY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=GagwchbqUvV4rNirgYBmzeuwfKzJAY7VxXYSFd6pOrCsvDGYS8QXcTcGzH716twQA5A501le8nmU5xDs/lAxa0/zRRgWaDB1RR8FyDU8ukawA2gRUVGpqK6gcpY0v7gx4UOtlD9pP6ft+nw76EsgSh3yoTiQ1R+zYnYOZEcsgyA= Received: by 10.78.157.15 with SMTP id f15mr2269016hue.2.1207898201473; Fri, 11 Apr 2008 00:16:41 -0700 (PDT) Received: by 10.78.40.16 with HTTP; Fri, 11 Apr 2008 00:16:41 -0700 (PDT) Message-ID: Date: Fri, 11 Apr 2008 09:16:41 +0200 From: "Hasnaa Moustafa" To: roll@ietf.org In-Reply-To: MIME-Version: 1.0 References: Subject: Re: [Roll] Roll Digest, Vol 3, Issue 4 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="===============0444363292==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0444363292== Content-Type: multipart/alternative; boundary="----=_Part_32141_26370889.1207898201466" ------=_Part_32141_26370889.1207898201466 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I am in favor to adopting the draft as a WG item. Kind regards, Hassnaa ------------------------------ > > Date: Tue, 08 Apr 2008 14:50:59 -0400 > From: JP Vasseur > Subject: [Roll] Adoption of > draft-dohler-roll-urban-routing-reqs-01.txt as a WG document ? > To: > Message-ID: > > > Content-Type: text/plain; charset="US-ASCII" > > Dear WG, > > Could you please let us know whether you are in favor or opposed to > adopting > draft-dohler-roll-urban-routing-reqs-01.txt ( > > http://www.ietf.org/internet-drafts/draft-dohler-roll-urban-routing-reqs-01 > . > txt) as a ROLL WG document ? > > Thanks. > > JP. > > > > ------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > End of Roll Digest, Vol 3, Issue 4 > ********************************** > ------=_Part_32141_26370889.1207898201466 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
 
I am in favor to adopting the draft as a WG item.
 
Kind regards,
Hassnaa
 
 
 

------------------------------

Date: Tue, 08 Apr 2008 14:50:59 -0400
From: JP Vasseur <jvasseur@cisco.com>
Subject: [Roll] Adoption of
       draft-dohler-roll-urban-routing-reqs-01.txt as a WG document ?
To: <roll@ietf.org>
Message-ID: <C42136D3.335B5%jvasseur@cisco.com>
Content-Type: text/plain;       charset="US-ASCII"

Dear WG,

Could you please let us know whether you are in favor or opposed to adopting
draft-dohler-roll-urban-routing-reqs-01.txt (
http://www.ietf.org/internet-drafts/draft-dohler-roll-urban-routing-reqs-01.
txt) as a ROLL WG document ?

Thanks.

JP.



------------------------------

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


End of Roll Digest, Vol 3, Issue 4
**********************************

------=_Part_32141_26370889.1207898201466-- --===============0444363292== 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 --===============0444363292==-- From roll-bounces@ietf.org Fri Apr 11 05:28:42 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02D6428C127; Fri, 11 Apr 2008 05:28:42 -0700 (PDT) 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 C62B33A6845 for ; Fri, 11 Apr 2008 01:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_82=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 g4rbPIufN7Us for ; Fri, 11 Apr 2008 01:05:52 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by core3.amsl.com (Postfix) with ESMTP id A08AA3A6D84 for ; Fri, 11 Apr 2008 01:05:51 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x19so474289pyg.24 for ; Fri, 11 Apr 2008 01:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=pb+AtmDKV8SK+QlJsrFdY/SuVXbNm2Jg5Q+odLJtWdQ=; b=ISCvr/zcd+MRvFPrV0ZXVaSzeDUvWDzDf7ftloRrOHttW6p3PRhEdM5TEtUCmQtK/KpWxMGZSoWNTu8K4HraICqRaB/aSjBy5ONxdExDJ6sip5XoGVMU8RNV2xw0fYnLEtCEiZGm5G4T279+tp1vg9aIna9vBjSmWWkZkiunn9w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=X17CxQqlpFBGaI4HeBMZeK/+G4jNPBJXKCZN0z3JweyefDr+AVVD/raU9o8gifqK4VUnHQCFzjohcp7zU5WRHDooABZbC+C/l/OWEONbf9+aJ5Y89bgW7qljQoub49RdsgEnapqmaZBvA2sP4/RdPhd9+U1RdQAZO9mFpAv4Qag= Received: by 10.141.86.14 with SMTP id o14mr1327747rvl.148.1207901173798; Fri, 11 Apr 2008 01:06:13 -0700 (PDT) Received: by 10.141.82.16 with HTTP; Fri, 11 Apr 2008 01:06:13 -0700 (PDT) Message-ID: <9674399e0804110106h54c75783uf0ec305889cd1711@mail.gmail.com> Date: Fri, 11 Apr 2008 01:06:13 -0700 From: "tarini goyal" To: Roll@ietf.org In-Reply-To: <9674399e0804030340p1cc11e33mcf7eb201a6efea4@mail.gmail.com> MIME-Version: 1.0 References: <470.45296.qm@web46107.mail.sp1.yahoo.com> <9674399e0804030340p1cc11e33mcf7eb201a6efea4@mail.gmail.com> X-Mailman-Approved-At: Fri, 11 Apr 2008 05:28:38 -0700 Subject: [Roll] Fwd: [manet] query 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="===============1766328619==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1766328619== Content-Type: multipart/alternative; boundary="----=_Part_25916_5593712.1207901173767" ------=_Part_25916_5593712.1207901173767 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline ---------- Forwarded message ---------- From: tarini goyal Date: Apr 3, 2008 3:40 AM Subject: Re: [manet] query To: ravi kumar Hi , Plz tell me how is the cluster formation phase should be included were in the code of glomosim for clustering protocols !!!!!!!!] Tarini On 4/2/08, ravi kumar wrote: > hi > plz tell me that how i cn change in recv() in DSRAgent.cc so pakets start > dropping instead of of forwarding. i.e node should behave like selfish node > > > ravi > > ------------------------------ > You rock. That's why Blockbuster's offering you one month of Blockbuster > Total Access, > No Cost. > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > ------=_Part_25916_5593712.1207901173767 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

---------- Forwarded message ----------
From: tarini goyal <tarini.goyal@gmail.com>
Date: Apr 3, 2008 3:40 AM
Subject: Re: [manet] query
To: ravi kumar <ravisuman1980@yahoo.com>
Hi ,
 Plz tell me how is the cluster formation phase should be included were in the code of glomosim for clustering protocols !!!!!!!!]
 
Tarini

 
On 4/2/08, ravi kumar <ravisuman1980@yahoo.com> wrote:
hi
 plz tell me that how i cn change in recv() in DSRAgent.cc so pakets start dropping instead of of forwarding. i.e node should behave like selfish node


ravi

You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


------=_Part_25916_5593712.1207901173767-- --===============1766328619== 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 --===============1766328619==-- From roll-bounces@ietf.org Mon Apr 14 07:59:07 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D51C3A6B53; Mon, 14 Apr 2008 07:59:07 -0700 (PDT) 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 DB9E23A695A for ; Mon, 14 Apr 2008 07:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.416 X-Spam-Level: X-Spam-Status: No, score=-4.416 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 4El3pm+bM-Tt for ; Mon, 14 Apr 2008 07:59:05 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 276E23A68C1 for ; Mon, 14 Apr 2008 07:59:05 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 14 Apr 2008 07:59:36 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3EExa8o008993 for ; Mon, 14 Apr 2008 07:59:36 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m3EExJB5023554 for ; Mon, 14 Apr 2008 14:59:35 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Apr 2008 10:59:31 -0400 Received: from 161.44.71.234 ([161.44.71.234]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 14 Apr 2008 14:59:31 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 14 Apr 2008 10:59:30 -0400 From: JP Vasseur To: Message-ID: Thread-Topic: New ROLL WG document Thread-Index: AcieQCQNYn2vYAozEd2zcQANk8WjQA== Mime-version: 1.0 X-OriginalArrivalTime: 14 Apr 2008 14:59:32.0079 (UTC) FILETIME=[254A6FF0:01C89E40] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=314; t=1208185176; x=1209049176; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20New=20ROLL=20WG=20document |Sender:=20; bh=CEZjZDKEWCpU70UKVm5Wg/ohlv2qkjOExK6dslvxU8k=; b=mF1supSl+h8neXgpReYvjcMlXBslpRkVQpwBykneh4ryPOxF6QtYPAJWII 4wROihzPuWJfLQgEn1rQ3KhBuwOVZayd1O78yFdIN5LGZ7U9nDVU1ULXOSOw fSGSJePgIg; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Roll] New ROLL WG 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Dear WG, There was a good consensus with no oposition to adopt draft-dohler-roll-urban-routing-reqs as a WG document. Authors, could you please republish draft-dohler-roll-urban-routing-reqs as draft-ietf-roll-urban-routing-reqs with no changes other than the document name and dates ? Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Apr 16 00:45:41 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 346913A6895; Wed, 16 Apr 2008 00:45:41 -0700 (PDT) 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 D30863A6D12 for ; Wed, 16 Apr 2008 00:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 TnK+t6n+y4l5 for ; Wed, 16 Apr 2008 00:45:31 -0700 (PDT) Received: from mailm.telecomitalia.it (mailm.telecomitalia.it [217.169.121.53]) by core3.amsl.com (Postfix) with ESMTP id 46D683A6EB4 for ; Wed, 16 Apr 2008 00:44:58 -0700 (PDT) Received: from ptpxch008rm001.idc.cww.telecomitalia.it ([156.54.205.170]) by mailm.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Apr 2008 09:45:30 +0200 Received: from GRFHUB702BA020.griffon.local ([10.188.101.112]) by ptpxch008rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Apr 2008 09:45:27 +0200 Received: from GRFMBX706BA020.griffon.local ([10.188.101.19]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Wed, 16 Apr 2008 09:45:25 +0200 From: Porcu Giorgio To: "roll@ietf.org" Date: Wed, 16 Apr 2008 09:41:27 +0200 Thread-Topic: Home Requirements Feedback Thread-Index: AQHIn5XUdGCf1HB1mU6UJhcsPj2yzQ== Message-ID: Accept-Language: it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: it-IT MIME-Version: 1.0 X-OriginalArrivalTime: 16 Apr 2008 07:45:27.0701 (UTC) FILETIME=[D6753C50:01C89F95] Subject: Re: [Roll] Home Requirements Feedback 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="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi All, Telecom Italia is very interested in the definition of the routing requirem= ents for LLN. Existing researches are often far from real users=92 requirements, they are= focused on lack of infrastructure and instant deployment. From users=92 standpoint, costs and maintenance are an issue and interopera= bility is a MUST, so it is important to focus on these keypoints. This mail could be divided in two part: the first one contains specific comments about the draft; the second one is= more general and contains some hints and ideas. Specific comments about the draft: 3.7 Use-case "HealthCare" This use-case is very interesting for Telecom Italia, since we has been wor= king on it for at least three years. We think that it could be a good opportunity to explicitly describe such a = use case with its own routing peculiarities: -priority: max priority should be granted at least to alarm messages -event detection: a "group" of nodes may cooperate to recognize different s= ituations (distributed and cooperative computation) -mobility: of course, a patient moves into the home... -low power: batteries should last for years -gateway: a main device should connect WSN to outside networks For these reasons (and mainly for the last) this use-case could also introd= uce a noteworthy device: something like an "IP-Phone" playing the gateway r= ole. If you think that could be useful, we'll care this part of the draft. 4.2 "Depending on the node type..." Does it depend on the power capacity or on the node's role (RFD/FFD)? I actually prefer the first differentiation criterion, so I think that this= section has to explicitly take into account three node types: - always on - battery powered (that take part in the routing) - battery powered (that don't take part in routing, like remote control) 5."A centralized system may benefit from a tree topology routing strategy; = having the central light controller close to the root." A tree topology may prove inefficient for nodes in a distribuited system..." It seems that centralized tree routing is not viable for HA scenario, but I= can=92t catch exactly why. General comments about the draft/WG: - I think that it could be worthwhile to spend a little effort to define a = set of criteria to be used to classify the application profiles, stressing = routing requirements and traffic features. E.g. for the healthcare scenario, the above mentioned criteria may sound li= ke this: traffic pattern || type of node taking part in routing || latency .= .. -------------------------------------------------------------------- any-to-many || battery powered: yes , always on || low What do you think about something like this? - I consider very interesting the use-case of Vincent Rossi concerning the = home energy efficiency. I think it differs from any others proposed scenario for some peculiar aspe= cts and could be an interesting market driver application. For this reasons, I'd like to include it in the draft. I have some other questions but I have wrote too much so... I'm looking forward to receiving your replies. Giorgio _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Apr 16 05:04:24 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B34B3A6F6C; Wed, 16 Apr 2008 05:04:24 -0700 (PDT) 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 5B4DB3A6F71 for ; Wed, 16 Apr 2008 05:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 58nZIxXp-4yy for ; Wed, 16 Apr 2008 05:04:19 -0700 (PDT) Received: from mailouta.tno.nl (mailouta.tno.nl [134.221.1.16]) by core3.amsl.com (Postfix) with ESMTP id E2D973A6D6B for ; Wed, 16 Apr 2008 05:04:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,664,1199660400"; d="scan'208";a="2466731" Received: from ms-dt01thalia.tno.nl (HELO ms-dt01thalia.tsn.tno.nl) ([134.221.225.157]) by mailhost1a.tno.nl with ESMTP; 16 Apr 2008 14:04:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Apr 2008 14:04:52 +0200 Message-ID: <092AD5B07D73934182942832D193AE1ABFE3E3@ms-dt01thalia.tsn.tno.nl> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Welcome to the "Roll" mailing list Thread-Index: AcifuZxiM4PR+w1BTH2DDe7s2QAS9gAAFl4g From: "Zhu, Y. (Yetao)" To: Subject: Re: [Roll] Welcome to the "Roll" mailing list 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 To post to this list! Best, Yetao -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of roll-request@ietf.org Sent: woensdag 16 april 2008 14:01 To: Zhu, Y. (Yetao) Subject: Welcome to the "Roll" mailing list Welcome to the Roll@ietf.org mailing list! To post to this list, send your email to: roll@ietf.org General information about the mailing list is at: https://www.ietf.org/mailman/listinfo/roll If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: https://www.ietf.org/mailman/options/roll/yetao.zhu%40tno.nl You can also make such adjustments via email by sending a message to: Roll-request@ietf.org with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: Normally, Mailman will remind you of your ietf.org mailing list passwords once every month, although you can disable this if you prefer. This reminder will also include instructions on how to unsubscribe or change your account options. There is also a button on your options page that will email your current password to you. This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Apr 16 14:03:47 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 012893A6D43; Wed, 16 Apr 2008 14:03:47 -0700 (PDT) X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2052E3A6C2F; Wed, 16 Apr 2008 14:00:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080416210001.2052E3A6C2F@core3.amsl.com> Date: Wed, 16 Apr 2008 14:00:01 -0700 (PDT) X-Mailman-Approved-At: Wed, 16 Apr 2008 14:03:46 -0700 Cc: roll@ietf.org Subject: [Roll] I-D ACTION:draft-ietf-roll-urban-routing-reqs-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: , 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 : Urban WSNs Routing Requirements in Low Power and Lossy Networks Author(s) : M. Dohler, T. Watteyne, C. Jacquenet, G. Madhusudan, G. Chegaray Filename : draft-ietf-roll-urban-routing-reqs-00.txt Pages : 16 Date : 2008-4-16 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 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 outdoors urban application scenario. As such, for a wireless ROLL solution to be competitive with other incumbent and emerging solutions, the protocol(s) ought to be energy-efficient, scalable and autonomous. This documents aims to specify a set of 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-00.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-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-4-16135245.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 Wed Apr 16 14:04:33 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC5CA3A6CCC; Wed, 16 Apr 2008 14:04:33 -0700 (PDT) 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 BCA253A695F for ; Wed, 16 Apr 2008 14:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.5 X-Spam-Level: X-Spam-Status: No, score=-4.5 tagged_above=-999 required=5 tests=[AWL=1.872, BAYES_00=-2.599, 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 SvwQZjEEzwjd for ; Wed, 16 Apr 2008 14:04:31 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 52EFE3A6C9C for ; Wed, 16 Apr 2008 14:04:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,666,1199692800"; d="scan'208";a="22099477" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 16 Apr 2008 14:05:07 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m3GL57Rm005012 for ; Wed, 16 Apr 2008 14:05:07 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m3GL54qx014090 for ; Wed, 16 Apr 2008 21:05:07 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Apr 2008 17:05:04 -0400 Received: from 10.86.104.187 ([10.86.104.187]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 Apr 2008 21:03:34 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 16 Apr 2008 17:03:27 -0400 From: JP Vasseur To: Message-ID: Thread-Topic: I-D ACTION:draft-ietf-roll-urban-routing-reqs-00.txt Thread-Index: AcigBVC+j1I03wv4Ed2a4QANk8WjQA== In-Reply-To: <20080416210001.2052E3A6C2F@core3.amsl.com> Mime-version: 1.0 X-OriginalArrivalTime: 16 Apr 2008 21:05:04.0601 (UTC) FILETIME=[8AEB3490:01C8A005] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2840; t=1208379907; x=1209243907; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20FW=3A=20I-D=20ACTION=3Adraft-ietf-roll-urban-ro uting-reqs-00.txt=20 |Sender:=20; bh=QeBAN3u+qN1TWbzUEUqsCusSQ0JUHrjRbqatr0puPAE=; b=P/ZWszBXHIPFsagYxUg0xBY534qkikiflNPLEb8qEYNpEl+CUJQT5fUa/j gU42jgJgu37tKXbP7lFnm1bynwIsuK/mrSNw/QN5pdnUjTNOk0Cjo3mxbbNg 29PmiDelm4; Authentication-Results: sj-dkim-3; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Roll] FW: I-D ACTION:draft-ietf-roll-urban-routing-reqs-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Our first WG document ! JP. ------ Forwarded Message > From: > Reply-To: > Date: Wed, 16 Apr 2008 14:00:01 -0700 (PDT) > To: > Cc: > Subject: I-D ACTION:draft-ietf-roll-urban-routing-reqs-00.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 : Urban WSNs Routing Requirements in Low Power and Lossy Networks > Author(s) : M. Dohler, T. Watteyne, C. Jacquenet, G. Madhusudan, G. Chegaray > Filename : draft-ietf-roll-urban-routing-reqs-00.txt > Pages : 16 > Date : 2008-4-16 > > 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 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 outdoors urban application scenario. As such, > for a wireless ROLL solution to be competitive with other incumbent > and emerging solutions, the protocol(s) ought to be energy-efficient, > scalable and autonomous. This documents aims to specify a set of > 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-00.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: <2008-4-16135245.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------ End of Forwarded Message _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Apr 17 15:37:11 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84E713A6FBC; Thu, 17 Apr 2008 15:37:11 -0700 (PDT) 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 9D7E13A7045 for ; Thu, 17 Apr 2008 15:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 Vl06i9PO3Qyh for ; Thu, 17 Apr 2008 15:37:08 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by core3.amsl.com (Postfix) with ESMTP id AE82A3A6FBC for ; Thu, 17 Apr 2008 15:37:08 -0700 (PDT) Received: from [128.32.168.42] (dhcp-168-42.EECS.Berkeley.EDU [128.32.168.42]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.2/8.13.5) with ESMTP id m3HMb6Zm024790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 17 Apr 2008 15:37:07 -0700 (PDT) Message-ID: <4807D10D.8090202@cs.berkeley.edu> Date: Thu, 17 Apr 2008 15:37:01 -0700 From: "David E. Culler" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: roll@ietf.org Subject: [Roll] Comments on the Industrial Requirements 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Now that we have our first WG document, let's keep things rolling. The following are comments on the Industrial Routing Requirements draft from November 9. Hope they are helpful. 1. Terminology - defines access point, but not router. In the ROLL WG meeting there was a good deal of terminology discussion because the term gateway was used in places where router was intended. Here that confusion has been avoided, but it may make sense to be clear on where the R in ROLL is involved. - "host application" may be a little confusing. In IP terms, the field devices is also a host. - Superframe - a very specific link layer mechanism. Unclear that it belongs in a routing requirements doc. - HART - belongs in Informative Reference section (where it does appear). Probably not in Terminology. - ISA - same Slotted-link - specific choice of link layer media access control mechanism. Unclear in belongs in routing requirements doc. Timeslot - same 2. Introduction page 4: can access points be wireless too? Presumably not low power or lossy "wired HART" - should other wired industrial options be mentioned, like foundation field bus? capacity analysis is for a localized region. It does not account for spatial reuse, which is expected to be common place in geographically large deployments - where Routing is most critical. 2.1 - class are out of sp100.11a RFP. Should it be referenced? Critical function... add "those that" Page 5 - customers => users discussion of typical data rates is important. Should that paragraph draw implications for route update rates? Page 6 Nine-9s discussion seems a bit misleading. Trues that there are a trillion seconds in 30 years, but that is hardly the point. This seems to suggest that there is no mechanism for error detection or recovery anywhere other than plant shutdown. First MUST relates to multi-topology routing. It seems like it would be good to develop more fully what we mean by this in the industrial setting. Second MUST seems entirely out of place. "color slotted-links" is a particular form of a particular link layer mechanism. It may be a great thing, but it hardly seems like it belongs in a routing requirements doc. There is probably a requirement having to do with isolation or predictability or something that this particular solution was standing as a proxy for. We should try to state the requirement, rather than dictate a particular solution at this stage. Third MUST is indeed a very important point that should bubble up to a requirement, but it isn't developed here. It wants supporting evidence, which fundamentally relates to the L's. Note that this is the reverse of previous MUST. This one takes general characteristics of the underlying link and the needs of applications to yield a requirement on routing. That is what these docs should do. QoS. -3. Is 200 ms serving as a bound or an expected? -4. Can we bound limited period? QoS parameters Transmission time seems to be calling for time correlated sampling, i.e., NTP, rather than coordinated transmissions. Are we establishing a requirement or advocating a solution? Reliability - 99.9% - Should probably clarify that this is end-to-end. Transmission priority - this seems to address forwarding, rather than routing. Page 7-8. We should be careful not to confuse the presence of a particular approach or solution with a requirement. Page 8. "MUST be able to set up routes that are directional". Is this to mean that A ----> B need not follow the reverse of the route B -----A. Or is this dealing with the asymmetry of the flows? 3.1 two additional MUSTs. First seems like it needs to be clarified. I think it is trying to get at adjusting to different flow rates - sampling may be very different from maintenance. This primarily a forwarding issue. Even with adaptation, it doesn't mean that it MUST be changing. Second MUST confuses dynamic path determination with a particular link layer mechanism. First is probably the intended requirement. Send is a particular solution. Section 4 para 2. Appears to define MAC requirement, rather than routing req. Perhaps is intended to define end-to-end application requirement. Also a piece of a service requirement (NTP?). Throughout analysis is for a particular MAC. Graph - Access points or routers? Both? Page 10. Section 7. Seems to want to deal with transient loss. Is it necessary to put it in terms of a particular link mechanism? section 8. Demographic discussion is probably accurate, but is it relevant for routing? "Should support the wireless worker" is probably a bit too vague a requirement. section 9 - so is this calling for Autoconf? Section 10 - Claims of the relative tolerance to failure in these industries should probably be removed. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Apr 23 09:13:10 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9EA83A6F58; Wed, 23 Apr 2008 09:13:10 -0700 (PDT) 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 E22DB28C163 for ; Wed, 23 Apr 2008 09:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.089 X-Spam-Level: X-Spam-Status: No, score=-5.089 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 758GVbpdsObZ for ; Wed, 23 Apr 2008 09:13:09 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id E6E7C3A6F58 for ; Wed, 23 Apr 2008 09:13:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,700,1199692800"; d="scan'208,217";a="11642637" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 23 Apr 2008 09:13:14 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3NGDEFo010051; Wed, 23 Apr 2008 09:13:14 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3NGCmxw003522; Wed, 23 Apr 2008 16:13:14 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Apr 2008 12:13:01 -0400 Received: from 10.86.104.189 ([10.86.104.189]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 23 Apr 2008 16:13:00 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Wed, 23 Apr 2008 12:12:59 -0400 From: JP Vasseur To: Message-ID: Thread-Topic: Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG Document Thread-Index: AcilXOW89ql1dLl4bE+Lol0n5SDswA== Mime-version: 1.0 X-OriginalArrivalTime: 23 Apr 2008 16:13:01.0144 (UTC) FILETIME=[E7041D80:01C8A55C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1952; t=1208967194; x=1209831194; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Adoption=20of=20draft-pister-roll-indus-routing -reqs-01=20as=20a=20ROLL=20WG=0A=20Document |Sender:=20; bh=w96fFelf3XAZlxoyAeQ6TDQeHP9GWCAZspIvZUZUbCI=; b=CLnmTQocoEP3L+apdITWmHDiA9B1G+UnCC5oQSruvWCCGyXPcqxlFDstbI 85K0FF4Q5eOz+o0Nwo1xTvySoS0boVc29yndQ7xp0kkZuQ+/RfhPBH5guujb ay/r4DNI/eYF4LAXcDxMmFH9cbQCWAPOWb6gybqWXitvCW+HNKZPo=; Authentication-Results: sj-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Roll] Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG 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: , Content-Type: multipart/mixed; boundary="===============2058000783==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============2058000783== Content-type: multipart/alternative; boundary="B_3291797580_2888386" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3291797580_2888386 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear WG, A new revision of draft-pister-roll-indus-routing-reqs has been published addressing a number of comments (the authors mentioned to us that there are still a few comments to address that require some discussion the list). Could you tell us whether you are in favor or opposed to the adoption of draft-pister-roll-indus-routing-reqs-01 (http://www.ietf.org/internet-drafts/draft-pister-roll-indus-routing-reqs-01 .txt) as a ROLL WG document ? Thanks. JP. --B_3291797580_2888386 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG Doc= ument Dear WG,

A new revision of draft-pister-roll-indus-routing-reqs has been published = addressing a number of comments (the authors mentioned to us that there are = still a few comments to address that require some discussion the list).

Could you tell us whether you are in favor or opposed to the adoption of draft-pister-roll-indus-routing-reqs-= 01 (http:/= /www.ietf.org/internet-drafts/draft-pister-roll-indus-routing-reqs-01.txt) as a ROLL WG document ?

Thanks.

JP. --B_3291797580_2888386-- --===============2058000783== 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 --===============2058000783==-- From roll-bounces@ietf.org Wed Apr 23 09:31:23 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B35413A6C93; Wed, 23 Apr 2008 09:31:23 -0700 (PDT) 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 9AEE43A6B7D for ; Wed, 23 Apr 2008 09:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.246 X-Spam-Level: X-Spam-Status: No, score=0.246 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1, 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 ZULwHvYfBCPk for ; Wed, 23 Apr 2008 09:31:18 -0700 (PDT) Received: from mail.dustnetworks.com (66.237.74.130.ptr.us.xo.net [66.237.74.130]) by core3.amsl.com (Postfix) with ESMTP id BDF453A6D34 for ; Wed, 23 Apr 2008 09:31:00 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Apr 2008 09:31:34 -0700 Message-ID: <9E9E6A5B6B547F4D8AFA7601E29508A70B5EAB@dust-exch-01.dusthq.dust-inc.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG Document Thread-Index: AcilXOW89ql1dLl4bE+Lol0n5SDswAAAkVcg From: "Chol Su Kang" To: Subject: Re: [Roll] Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG 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: , Content-Type: multipart/mixed; boundary="===============1220589792==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============1220589792== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A55F.82805670" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A55F.82805670 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi JP, =20 I am in favor of accepting the draft. =20 Regards, Chol Su Kang =20 =20 ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Wednesday, April 23, 2008 9:13 AM To: roll@ietf.org Subject: [Roll] Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG Document =20 Dear WG, A new revision of draft-pister-roll-indus-routing-reqs has been published addressing a number of comments (the authors mentioned to us that there are still a few comments to address that require some discussion the list). Could you tell us whether you are in favor or opposed to the adoption of draft-pister-roll-indus-routing-reqs-01 (http://www.ietf.org/internet-drafts/draft-pister-roll-indus-routing-req s-01.txt) as a ROLL WG document ? Thanks. JP.=20 ------_=_NextPart_001_01C8A55F.82805670 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG Document

Hi JP,

 

I am in favor of accepting the = draft.

 

Regards,

Chol Su = Kang

 

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur
Sent: Wednesday, April = 23, 2008 9:13 AM
To: roll@ietf.org
Subject: [Roll] Adoption = of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG = Document

 

Dear WG,

A new revision of draft-pister-roll-indus-ro= uting-reqs has been published addressing a number of comments (the authors = mentioned to us that there are still a few comments to address that require some = discussion the list).

Could you tell us whether you are in favor or opposed to the adoption of = draft-pister-roll-indus-ro= uting-reqs-01 (http://www.ietf.org/internet-drafts/draft-pister-roll-in= dus-routing-reqs-01.txt) as a ROLL WG document ?

Thanks.

JP.

------_=_NextPart_001_01C8A55F.82805670-- --===============1220589792== 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 --===============1220589792==-- From roll-bounces@ietf.org Wed Apr 23 09:43:50 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB26128C0F8; Wed, 23 Apr 2008 09:43:50 -0700 (PDT) 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 341DF3A6D34 for ; Wed, 23 Apr 2008 09:43:50 -0700 (PDT) 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 I+5vOhiMWWj2 for ; Wed, 23 Apr 2008 09:43:49 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 4AC4A3A6D66 for ; Wed, 23 Apr 2008 09:43:49 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 23 Apr 2008 09:43:55 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m3NGhsQs014983 for ; Wed, 23 Apr 2008 09:43:54 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m3NGhrEn025264 for ; Wed, 23 Apr 2008 16:43:55 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Apr 2008 09:43:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Apr 2008 09:46:51 -0700 Message-ID: <813F12598722004A9F0A3593D83F7A040595DBBF@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG Document Thread-Index: AcilXOW89ql1dLl4bE+Lol0n5SDswAABJJPQ References: From: "Tarun Banka (tabanka)" To: "Jean Philippe Vasseur (jvasseur)" , X-OriginalArrivalTime: 23 Apr 2008 16:43:54.0745 (UTC) FILETIME=[37D92E90:01C8A561] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3869; t=1208969035; x=1209833035; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tabanka@cisco.com; z=From:=20=22Tarun=20Banka=20(tabanka)=22=20 |Subject:=20RE=3A=20[Roll]=20Adoption=20of=20draft-pister-r oll-indus-routing-reqs-01=20as=20a=20ROLL=20WG=20Document |Sender:=20; bh=g5zP6TJsdN25hWUFFfOYmJbeB4m80RTaUmm3f/+4Wx4=; b=HbG0chab8P1sxA1oDVQQwp2BrXuhggqmBUU/HHjDtsUwz4hzmI8pXS95Yk MIwUeQ/alCvvU3pNr6RbCs4bbG0eFurfIJ6HZT3lVxcE6rXFtcIn3bobtlWb i68m0UlRgm; Authentication-Results: sj-dkim-4; header.From=tabanka@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Roll] Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG 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: , Content-Type: multipart/mixed; boundary="===============1798410225==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============1798410225== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A561.37B1331A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A561.37B1331A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi JP, =20 I am in favor of adoption of this draft. =20 Thanks, Tarun ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jean Philippe Vasseur (jvasseur) Sent: Wednesday, April 23, 2008 9:13 AM To: roll@ietf.org Subject: [Roll] Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG Document Dear WG, A new revision of draft-pister-roll-indus-routing-reqs has been published addressing a number of comments (the authors mentioned to us that there are still a few comments to address that require some discussion the list). Could you tell us whether you are in favor or opposed to the adoption of draft-pister-roll-indus-routing-reqs-01 (http://www.ietf.org/internet-drafts/draft-pister-roll-indus-routing-req s-01.txt) as a ROLL WG document ? Thanks. JP.=20 ------_=_NextPart_001_01C8A561.37B1331A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adoption of draft-pister-roll-indus-routing-reqs-01 = as a ROLL WG Document
Hi JP,
 
I am in favor of adoption of this=20 draft.
 
Thanks,
Tarun

From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On Behalf Of Jean Philippe Vasseur = (jvasseur)
Sent: Wednesday, April 23, 2008 9:13 = AM
To:=20 roll@ietf.org
Subject: [Roll] Adoption of=20 draft-pister-roll-indus-routing-reqs-01 as a ROLL WG=20 Document

Dear WG,

A new revision of = draft-pister-roll-indus-routing-reqs has = been=20 published addressing a number of comments (the authors mentioned to us = that=20 there are still a few comments to address that require some discussion = the=20 list).

Could = you tell=20 us whether you are in favor or opposed to the adoption of draft-pister-roll-indus-routing-reqs-01 (http://www.ietf.org/internet-drafts/draft-pister-roll-in= dus-routing-reqs-01.txt)=20 as a ROLL WG document ?

Thanks.

JP.=20 ------_=_NextPart_001_01C8A561.37B1331A-- --===============1798410225== 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 --===============1798410225==-- From roll-bounces@ietf.org Wed Apr 23 15:24:37 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73E363A6C07; Wed, 23 Apr 2008 15:24:37 -0700 (PDT) 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 0AEA43A6C07 for ; Wed, 23 Apr 2008 15:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[AWL=1.186, BAYES_00=-2.599, 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 T6-ebkn4YRik for ; Wed, 23 Apr 2008 15:24:36 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by core3.amsl.com (Postfix) with ESMTP id 5BA963A6B2F for ; Wed, 23 Apr 2008 15:24:36 -0700 (PDT) Received: from [128.32.168.42] (dhcp-168-42.EECS.Berkeley.EDU [128.32.168.42]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.2/8.13.5) with ESMTP id m3NMOZ3W014528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 23 Apr 2008 15:24:41 -0700 (PDT) Message-ID: <480FB71E.9050403@cs.berkeley.edu> Date: Wed, 23 Apr 2008 15:24:30 -0700 From: "David E. Culler" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: roll@ietf.org Subject: [Roll] Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Kris and Pascal, Great job on this. I think it provides an excellent foundation for the workgroup efforts on industrial requirements. The big picture is well framed so the remaining debate on technical specifics can be very focused. Assuming that the responses on the list continue to be supportive and we take it on, I would like to see some discussion regarding the figure on page 7 and the last MUST in paragraph 2 of section 9. David _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Apr 23 19:10:34 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C45C628C25E; Wed, 23 Apr 2008 19:10:34 -0700 (PDT) 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 8F23A3A6D5A for ; Wed, 23 Apr 2008 19:10:30 -0700 (PDT) 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 nWCa+KzLxign for ; Wed, 23 Apr 2008 19:10:29 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id E7F803A6DE3 for ; Wed, 23 Apr 2008 19:10:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,701,1199692800"; d="scan'208,217";a="23149062" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 23 Apr 2008 19:10:32 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3O2AWOo015240 for ; Wed, 23 Apr 2008 19:10:32 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3O2AW3b003942 for ; Thu, 24 Apr 2008 02:10:32 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Apr 2008 19:10:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Apr 2008 19:06:25 -0700 Message-ID: <52E903A38F544F46A2A6632AC66103EE05B072C2@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG Document Thread-Index: AcilXOW89ql1dLl4bE+Lol0n5SDswAAUtyOA References: From: "Shitanshu Shah (svshah)" To: "Jean Philippe Vasseur (jvasseur)" , X-OriginalArrivalTime: 24 Apr 2008 02:10:31.0810 (UTC) FILETIME=[5FAD9E20:01C8A5B0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3577; t=1209003032; x=1209867032; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=svshah@cisco.com; z=From:=20=22Shitanshu=20Shah=20(svshah)=22=20 |Subject:=20RE=3A=20[Roll]=20Adoption=20of=20draft-pister-r oll-indus-routing-reqs-01=20as=20a=20ROLL=20WG=20Document |Sender:=20; bh=Yc5HL2r+9rwz4ksdLNrd5oM7s5/jnxtmj9JYhOs+Qhg=; b=SrwDX95Wof/XloH3q4dV8ZvaE8wFVKiW2rDN3JnC7VzgRfgmMsnoKVXfCH hev/UyTM1Ei0ev0vKVMjpkC/5tXdsek8pv3DAfNogjCsxYfxc8yYcL5DVVHP DZzbGDDeNy; Authentication-Results: sj-dkim-2; header.From=svshah@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Roll] Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG 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: , Content-Type: multipart/mixed; boundary="===============1264773008==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============1264773008== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A5B0.5F8FE71A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A5B0.5F8FE71A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable in favor =20 Shitanshu ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jean Philippe Vasseur (jvasseur) Sent: Wednesday, April 23, 2008 9:13 AM To: roll@ietf.org Subject: [Roll] Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG Document =09 =09 Dear WG, =09 A new revision of draft-pister-roll-indus-routing-reqs has been published addressing a number of comments (the authors mentioned to us that there are still a few comments to address that require some discussion the list). =09 Could you tell us whether you are in favor or opposed to the adoption of draft-pister-roll-indus-routing-reqs-01 (http://www.ietf.org/internet-drafts/draft-pister-roll-indus-routing-req s-01.txt) as a ROLL WG document ? =09 Thanks. =09 JP.=20 ------_=_NextPart_001_01C8A5B0.5F8FE71A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adoption of draft-pister-roll-indus-routing-reqs-01 = as a ROLL WG Document
in favor
 
Shitanshu

From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On Behalf Of Jean Philippe = Vasseur=20 (jvasseur)
Sent: Wednesday, April 23, 2008 9:13 = AM
To:=20 roll@ietf.org
Subject: [Roll] Adoption of=20 draft-pister-roll-indus-routing-reqs-01 as a ROLL WG=20 Document

Dear WG,

A new revision of = draft-pister-roll-indus-routing-reqs has = been=20 published addressing a number of comments (the authors mentioned to us = that=20 there are still a few comments to address that require some discussion = the=20 list).

Could you=20 tell us whether you are in favor or opposed to the adoption of = draft-pister-roll-indus-routing-reqs-01 (http://www.ietf.org/internet-drafts/draft-pister-roll-in= dus-routing-reqs-01.txt)=20 as a ROLL WG document ?

Thanks.

JP. = ------_=_NextPart_001_01C8A5B0.5F8FE71A-- --===============1264773008== 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 --===============1264773008==-- From roll-bounces@ietf.org Thu Apr 24 01:42:09 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B1DC3A6BA3; Thu, 24 Apr 2008 01:42:09 -0700 (PDT) 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 36B023A67AE for ; Thu, 24 Apr 2008 01:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.492 X-Spam-Level: X-Spam-Status: No, score=-0.492 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 VEN5zN9OzkjF for ; Thu, 24 Apr 2008 01:41:55 -0700 (PDT) Received: from maild.telecomitalia.it (maild.telecomitalia.it [156.54.233.30]) by core3.amsl.com (Postfix) with ESMTP id 0720228C263 for ; Thu, 24 Apr 2008 01:41:37 -0700 (PDT) Received: from ptpxch007ba020.idc.cww.telecomitalia.it ([156.54.240.50]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Apr 2008 10:41:41 +0200 Received: from GRFHUB702BA020.griffon.local ([10.188.101.112]) by ptpxch007ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Apr 2008 10:41:41 +0200 Received: from GRFMBX706BA020.griffon.local ([10.188.101.20]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Thu, 24 Apr 2008 10:41:40 +0200 From: Porcu Giorgio To: "roll@ietf.org" Date: Thu, 24 Apr 2008 10:38:13 +0200 Thread-Topic: Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG Document Thread-Index: AQHIpecDASCP3Dfte0O5E3eBSPqp0Q== Message-ID: Accept-Language: it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: it-IT MIME-Version: 1.0 X-OriginalArrivalTime: 24 Apr 2008 08:41:41.0180 (UTC) FILETIME=[048347C0:01C8A5E7] Subject: [Roll] R: Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi all, I'm in favor. Cheers, Giorgio ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jean Philippe Vasseur (jvasseur) Sent: Wednesday, April 23, 2008 9:13 AM To: roll@ietf.org Subject: [Roll] Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG Document Dear WG, A new revision of draft-pister-roll-indus-routing-reqs has been published addressing a number of comments (the authors mentioned to us that there are still a few comments to address that require some discussion the list). Could you tell us whether you are in favor or opposed to the adoption of draft-pister-roll-indus-routing-reqs-01 (http://www.ietf.org/internet-drafts/draft-pister-roll-indus-routing-req s-01.txt) as a ROLL WG document ? Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Apr 24 02:30:04 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C6B93A693D; Thu, 24 Apr 2008 02:30:04 -0700 (PDT) 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 C387F3A693D for ; Thu, 24 Apr 2008 02:30:02 -0700 (PDT) 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 kqrX3ZiuBWXS for ; Thu, 24 Apr 2008 02:30:00 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 95DF03A6AFF for ; Thu, 24 Apr 2008 02:29:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,703,1199660400"; d="scan'208";a="7191678" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 24 Apr 2008 11:30:03 +0200 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 m3O9U32l007328; Thu, 24 Apr 2008 11:30:03 +0200 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 m3O9U3nm025199; Thu, 24 Apr 2008 09:30:03 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, 24 Apr 2008 11:30:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Apr 2008 11:29:28 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05957E1E@xmb-ams-337.emea.cisco.com> In-Reply-To: <4807D10D.8090202@cs.berkeley.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Comments on the Industrial Requirements Draft thread-index: Acig25aMZtoMlMkoTRiF/C9PXXBqnwFEXJTQ References: <4807D10D.8090202@cs.berkeley.edu> From: "Pascal Thubert (pthubert)" To: "David E. Culler" , X-OriginalArrivalTime: 24 Apr 2008 09:30:03.0638 (UTC) FILETIME=[C6833960:01C8A5ED] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=17388; t=1209029403; x=1209893403; 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]=20Comments=20on=20the=20Industri al=20Requirements=20Draft |Sender:=20; bh=UitSwy60/OruDKLox8Nykbiy2ZTJczgsW/J8j/Evz6A=; b=i9+3cgLgB6xXA9qfGoMhw43NomJQzsA+k/df1ly7EvAz/jLBo0Fzzqi5wv gLIVRh8FwosQlbof/nmoyOeW5vim5mkzlRLPGmEXfAz2ec/i2GLBrzq2mE6b 6C9Wh8xGq5; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [Roll] Comments on the Industrial Requirements 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi David: I'm trying to summarize here what we did or did not do (yet) about your com= ments here. BTW thanks a huge deal for your help here. Also this response s= om=F9etimes reflects my opinion and not necessarily a consensus amonst the = authors. I note that there's still work to do on 3.1 and 7 for the chicken and an eg= g problem between routing and dynamic radio links instantiations, in sectio= n 10 about security and provisionning, and per your comments on rev 1. Also: to avoid nested >>> I kept your text without a > and added mine prefi= xed with [Pascal] --------------------------------------------------------- Now that we have our first WG document, let's keep things rolling. The fol= lowing are comments on the Industrial Routing Requirements draft from Novem= ber 9. Hope they are helpful. 1. Terminology - defines access point, but not router. In the ROLL WG meeting there was = a good deal of terminology discussion because the term gateway was used in = places where router was intended. Here that confusion has been avoided, bu= t it may make sense to be clear on where the R in ROLL is involved. [Pascal] we need to find the right term. Right now L2N AP = = - "host application" may be a little confusing. In IP terms, the field de= vices is also a host. = = [Pascal] now plant application = = - Superframe - a very specific link layer mechanism. Unclear that it belon= gs in a routing requirements doc. [Pascal] gone - HART - belongs in Informative Reference section (where it does appear). = Probably not in Terminology. - ISA - same [Pascal] Not done yet. I would agree though; terminology mostly defines new= terms and refers to docs for existing terms Slotted-link - specific choice of link layer media access control mechanism= . Unclear in belongs in routing requirements doc. Timeslot - same [Pascal] still a ref in section 5 that we could remove 2. Introduction page 4: can access points be wireless too? Presumably not low power or los= sy [Pascal] sure but then we need to express the same reliability and security= as in the WSN. At this point the term "wired" was removed. "wired HART" - should other wired industrial options be mentioned, like fou= ndation field bus? [Pascal] still there. No big del is it? and yes we could name the alternate capacity analysis is for a localized region. It does not account for spati= al reuse, which is expected to be common place in geographically large depl= oyments - where Routing is most critical. [Pascal] Should routing know about spatial reuse? Is there text that this s= pecifically aims at changing or is it entirely new? 2.1 - class are out of sp100.11a RFP. Should it be referenced? [Pascal] yes I think so. Critical function... add "those that" [Pascal] fixed, removed 'are' Page 5 - customers =3D> users [Pascal] done discussion of typical data rates is important. Should that paragraph draw = implications for route update rates? [Pascal] there is now a section on route maintenance Page 6 Nine-9s discussion seems a bit misleading. Trues that there are a trillion= seconds in 30 years, but that is hardly the point. This seems to suggest = that there is no mechanism for error detection or recovery anywhere other t= han plant shutdown. [Pascal] I also fail to understand this text: "In critical control, tens of milliseconds of latency is typical. In many of these systems, if a packet does not arrive within the specified interval, the system enters an emergency shutdown state, often with substantial financial repercussions. For a one-second control loop in a system with a mean-time between shutdowns target of 30 years, the latency requirement implies nine 9s of reliability." First MUST relates to multi-topology routing. It seems like it would be go= od to develop more fully what we mean by this in the industrial setting. [Pascal] that text is gone and the development was done in section 2.2 Second MUST seems entirely out of place. "color slotted-links" is a partic= ular form of a particular link layer mechanism. It may be a great thing, b= ut it hardly seems like it belongs in a routing requirements doc. There is= probably a requirement having to do with isolation or predictability or so= mething that this particular solution was standing as a proxy for. We shou= ld try to state the requirement, rather than dictate a particular solution = at this stage. [Pascal] isolation is missing in that version but we are working on it for = the next version Third MUST is indeed a very important point that should bubble up to a requ= irement, but it isn't developed here. It wants supporting evidence, which = fundamentally relates to the L's. Note that this is the reverse of previou= s MUST. This one takes general characteristics of the underlying link and = the needs of applications to yield a requirement on routing. That is what = these docs should do. = [Pascal] what about this text: "" The logical topologies = ---------------------- = Publication ----------- Most of the traffic over the LLN is publish/subscribe of sensor data from t= he field device towards the backbone router or gateway that acts as the sin= k for the WSN. The destination of the sensor data is an Infrastructure dev= ices that sits on the backbone and is reachable via one or more backbone ro= uter. Since publishing the data is the raison d'etre for most of the sensor= s, it makes sense to build proactively a set of default routes between the = sensors and one or more backbone router and maintain those routes at all ti= me. Also, because of the lossy nature of the network, the routing in place = should attempt to propose multiple forwarding solutions, building non congr= uent forwarding topologies in the form of Directed acyclic graphs oriented = towards the sinks. Note that for a control application, the jitter is just = as important as latency and has a potential of destabilizing control algori= thms. = Closed loop ----------- = In contrast with the general requirement of maintaining default routes towa= rds the sinks, the need for field device to field device connectivity is on= ly occasional, though the traffic associated might be of foremost importanc= e. An example of field device to field device traffic is a control loop bet= ween a vibration sensor and an actuator that can stop a motor that is faili= ng. A class 0 control loop requires guaranteed delivery and extremely tight= response times. In other words, both the respect of criteria in the route = computation and the quality of the maintenance of the route are critical fo= r the field devices operation. The requirements vary with the operations of= the field devices but in a general fashion field device to field device ro= utes will often be the most critical, optimized and well-maintained. " QoS. -3. Is 200 ms serving as a bound or an expected? -4. Can we bound limited period? QoS as a term is gone because it's forwarding. We used the term service and= changed this 200 to hundereds of ms. = = QoS parameters Transmission time seems to be calling for time correlated sampling, = i.e., NTP, rather than coordinated transmissions. Are we establishing a = requirement or advocating a solution? [Pascal] is there text left to be changed for this remark? [Pascal] Do you disagree with text about Transmission phase? If so would yo= u propose an alternate text? = Reliability - 99.9% - Should probably clarify that this is end-to-end. [Pascal] This text is gone = Transmission priority - this seems to address forwarding, rather than = routing. [Pascal] right. Maybe we need to get this out. It's just good information t= hough Page 7-8. We should be careful not to confuse the presence of a = particular approach or solution with a requirement. [Pascal] referenced to slotted are gone Page 8. "MUST be able to set up routes that are directional". Is this = to mean that A ----> B need not follow the reverse of the route B = -----A. Or is this dealing with the asymmetry of the flows? [Pascal] we added text: " Industrial application data flows between field devices are not necessarily symmetric. In particular, asymmetrical cost and unidirectional routes are common for published data and alerts, which represent the most part of the sensor traffic. The routing protocol MUST be able to set up unidirectional or asymmetrical cost routes that are composed of one or more non congruent paths. " 3.1 two additional MUSTs. First seems like it needs to be clarified. I = think it is trying to get at adjusting to different flow rates - = sampling may be very different from maintenance. This primarily a = forwarding issue. Even with adaptation, it doesn't mean that it MUST be = changing. [Pascal] I would agree on this. If the routing has established multiple pat= h then = a forwarding protocol can control the bandwidth and latency in real time an= d that = can be all a forwarding issue. I note that we have to work some more on 3.1 Second MUST confuses dynamic path determination with a particular link = layer mechanism. First is probably the intended requirement. Send is a = particular solution. [Pascal] I would agree on this too. There is a chicken and an egg problem b= etween routing = an link provisionning when links can be provisionned dynamically. This is n= othing new = if you consider traffic engineering. We have to figure what we really want.= I see 2 options: - links come and go because they are used or not and L3 makes the best of it - L3 uses virtual links that are actually instantiated when they are really= needed and L2 = tries to adapt to the traffic that L3 causes to go over links To be honest I think that the later makes more sense. Section 4 para 2. Appears to define MAC requirement, rather than = routing req. Perhaps is intended to define end-to-end application = requirement. Also a piece of a service requirement (NTP?). Throughout analysis is for a particular MAC. Graph - Access points or routers? Both? [Pascal] 4 moved into 2.2. The text you refer to is all gone now. = Page 10. Section 7. Seems to want to deal with transient loss. Is it = necessary to put it in terms of a particular link mechanism? [Pascal] Terms were fixed (no more slotted links) but the chicken and an eg= g problem also discussed in 3.1 stays section 8. Demographic discussion is probably accurate, but is it = relevant for routing? "Should support the wireless worker" is probably = a bit too vague a requirement. [Pascal]Text with requirements was added in 2.2.1 in the long p=E2ragraph a= fter the picture. = Maybe this section (that is unchanged BTW) should move earlier in the doc t= o intriduce the issue? section 9 - so is this calling for Autoconf? [Pascal] Certainly something to look at when considering solution. We can d= ig into MANET and MANEMO history as well. Section 10 - Claims of the relative tolerance to failure in these = industries should probably be removed. [Pascal] I agree we should remove the terms link banking industry which poi= nt at someone in particular. There's also the discussion about keys, perimeter of security and related p= rovisionning that needs rework. This section should bequite improved with the help of new authors (Sicco Dw= ars and Tom Phinney) who were invited in. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Da= vid E. Culler >Sent: vendredi 18 avril 2008 00:37 >To: roll@ietf.org >Subject: [Roll] Comments on the Industrial Requirements Draft > >Now that we have our first WG document, let's keep things rolling. The >following are comments on the Industrial Routing Requirements draft from >November 9. Hope they are helpful. > >1. Terminology > - defines access point, but not router. In the ROLL WG meeting there >was a good deal of terminology discussion because the term gateway was >used in places where router was intended. Here that confusion has been >avoided, but it may make sense to be clear on where the R in ROLL is >involved. > > - "host application" may be a little confusing. In IP terms, the field >devices is also a host. > >- Superframe - a very specific link layer mechanism. Unclear that it >belongs in a routing requirements doc. > >- HART - belongs in Informative Reference section (where it does >appear). Probably not in Terminology. >- ISA - same > >Slotted-link - specific choice of link layer media access control >mechanism. Unclear in belongs in routing requirements doc. >Timeslot - same > >2. Introduction > >page 4: can access points be wireless too? Presumably not low power or >lossy > >"wired HART" - should other wired industrial options be mentioned, like >foundation field bus? > >capacity analysis is for a localized region. It does not account for >spatial reuse, which is expected to be common place in geographically >large deployments - where Routing is most critical. > >2.1 - class are out of sp100.11a RFP. Should it be referenced? > >Critical function... add "those that" > >Page 5 - customers =3D> users > >discussion of typical data rates is important. Should that paragraph >draw implications for route update rates? > >Page 6 > >Nine-9s discussion seems a bit misleading. Trues that there are a >trillion seconds in 30 years, but that is hardly the point. This seems >to suggest that there is no mechanism for error detection or recovery >anywhere other than plant shutdown. > >First MUST relates to multi-topology routing. It seems like it would be >good to develop more fully what we mean by this in the industrial setting. > >Second MUST seems entirely out of place. "color slotted-links" is a >particular form of a particular link layer mechanism. It may be a great >thing, but it hardly seems like it belongs in a routing requirements >doc. There is probably a requirement having to do with isolation or >predictability or something that this particular solution was standing >as a proxy for. We should try to state the requirement, rather than >dictate a particular solution at this stage. > >Third MUST is indeed a very important point that should bubble up to a >requirement, but it isn't developed here. It wants supporting evidence, >which fundamentally relates to the L's. Note that this is the reverse >of previous MUST. This one takes general characteristics of the >underlying link and the needs of applications to yield a requirement on >routing. That is what these docs should do. > >QoS. > -3. Is 200 ms serving as a bound or an expected? > -4. Can we bound limited period? > >QoS parameters > >Transmission time seems to be calling for time correlated sampling, >i.e., NTP, rather than coordinated transmissions. Are we establishing a >requirement or advocating a solution? > >Reliability - 99.9% - Should probably clarify that this is end-to-end. > >Transmission priority - this seems to address forwarding, rather than >routing. > >Page 7-8. We should be careful not to confuse the presence of a >particular approach or solution with a requirement. > >Page 8. "MUST be able to set up routes that are directional". Is this >to mean that A ----> B need not follow the reverse of the route B >-----A. Or is this dealing with the asymmetry of the flows? > >3.1 two additional MUSTs. First seems like it needs to be clarified. I >think it is trying to get at adjusting to different flow rates - >sampling may be very different from maintenance. This primarily a >forwarding issue. Even with adaptation, it doesn't mean that it MUST be >changing. > >Second MUST confuses dynamic path determination with a particular link >layer mechanism. First is probably the intended requirement. Send is a >particular solution. > >Section 4 para 2. Appears to define MAC requirement, rather than >routing req. Perhaps is intended to define end-to-end application >requirement. Also a piece of a service requirement (NTP?). > >Throughout analysis is for a particular MAC. > >Graph - Access points or routers? Both? > >Page 10. Section 7. Seems to want to deal with transient loss. Is it >necessary to put it in terms of a particular link mechanism? > >section 8. Demographic discussion is probably accurate, but is it >relevant for routing? "Should support the wireless worker" is probably >a bit too vague a requirement. > >section 9 - so is this calling for Autoconf? > >Section 10 - Claims of the relative tolerance to failure in these >industries should probably be removed. > > > > > > >_______________________________________________ >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 Thu Apr 24 04:11:47 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4A2F3A6A52; Thu, 24 Apr 2008 04:11:47 -0700 (PDT) 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 15F053A6915 for ; Thu, 24 Apr 2008 04:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 7oISW9JbelSh for ; Thu, 24 Apr 2008 04:11:45 -0700 (PDT) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id AD8943A6A52 for ; Thu, 24 Apr 2008 04:11:44 -0700 (PDT) Received: from ind-dkim-1.cisco.com ([64.104.140.57]) by ind-iport-1.cisco.com with ESMTP; 24 Apr 2008 16:41:49 +0530 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3OBBm45004137 for ; Thu, 24 Apr 2008 16:41:48 +0530 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by india-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3OBBl0r003224 for ; Thu, 24 Apr 2008 11:11:47 GMT Received: from XMB-BLR-419.apac.cisco.com ([64.104.140.154]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Apr 2008 16:41:47 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Apr 2008 16:41:43 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG Document Thread-Index: AcilXOW89ql1dLl4bE+Lol0n5SDswAAnkXkQ References: From: "Prashant Jhingran (pjhingra)" To: X-OriginalArrivalTime: 24 Apr 2008 11:11:47.0741 (UTC) FILETIME=[FCD76CD0:01C8A5FB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1142; t=1209035508; x=1209899508; c=relaxed/simple; s=inddkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pjhingra@cisco.com; z=From:=20=22Prashant=20Jhingran=20(pjhingra)=22=20 |Subject:=20RE=3A=20[Roll]=20Adoption=20of=20draft-pister-r oll-indus-routing-reqs-01=20as=20a=20ROLL=20WG=20Document |Sender:=20; bh=HxaMrRW/WgLEir0xK2J2EzHiSkEg+BhmF+MKpJkLFdA=; b=Nn2KtOrLNL1JKOsDCNm5moOhWv/IAAZ5zIRsiJJiKIZUDK0DsMgnJnOXj/ lMdh9tbVYlOEnk4IVVTAfIpnRKFEsS6hsuXHR3qHuasrjI0KLePEkRfJt8+E V5siY+Kx9/; Authentication-Results: ind-dkim-1; header.From=pjhingra@cisco.com; dkim=pass ( sig from cisco.com/inddkim1002 verified; ); Subject: Re: [Roll] Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi All, Terminologies & Requirements are very well elaborated, I am in favor of the same. TYPO Section 2.2: A plant or corporate network is also present on the factory site. This is the typical IT "nework" for the factory operations beyond process control. Regards, Prashant Jhingran Phone: +91-80-442 61800 ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jean Philippe Vasseur (jvasseur) Sent: Wednesday, April 23, 2008 9:43 PM To: roll@ietf.org Subject: [Roll] Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG Document Dear WG, A new revision of draft-pister-roll-indus-routing-reqs has been published addressing a number of comments (the authors mentioned to us that there are still a few comments to address that require some discussion the list). Could you tell us whether you are in favor or opposed to the adoption of draft-pister-roll-indus-routing-reqs-01 (http://www.ietf.org/internet-drafts/draft-pister-roll-indus-routing-req s-01.txt) as a ROLL WG document ? Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Apr 24 04:21:51 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 898453A6BB7; Thu, 24 Apr 2008 04:21:51 -0700 (PDT) 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 F14723A6AAA for ; Thu, 24 Apr 2008 04:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 6qpt21ifrR6L for ; Thu, 24 Apr 2008 04:21:48 -0700 (PDT) Received: from coe.drexel.edu (cbis.ece.drexel.edu [129.25.60.1]) by core3.amsl.com (Postfix) with ESMTP id 6A6A928C1CD for ; Thu, 24 Apr 2008 04:21:07 -0700 (PDT) Received: from [129.25.14.14] (n1-14-14.dhcp.drexel.edu [129.25.14.14]) (authenticated bits=0) by coe.drexel.edu (8.13.6/8.13.4) with ESMTP id m3OBOiA8019320; Thu, 24 Apr 2008 07:24:44 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <5DA09F98-9235-43C4-8658-F92DC2FD266E@ece.drexel.edu> From: Jaudelice de Oliveira Date: Thu, 24 Apr 2008 07:20:45 -0400 To: JP Vasseur X-Mailer: Apple Mail (2.753) X-Scanned-By: MIMEDefang 2.51 on 129.25.60.1 Cc: roll@ietf.org Subject: Re: [Roll] Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG 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: , Content-Type: multipart/mixed; boundary="===============1791475636==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1791475636== Content-Type: multipart/alternative; boundary=Apple-Mail-4-948095035 --Apple-Mail-4-948095035 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed In favor! Cheers, Jau. On Apr 23, 2008, at 12:12 PM, JP Vasseur wrote: > Dear WG, > > A new revision of draft-pister-roll-indus-routing-reqs has been > published addressing a number of comments (the authors mentioned to > us that there are still a few comments to address that require some > discussion the list). > > Could you tell us whether you are in favor or opposed to the > adoption of draft-pister-roll-indus-routing-reqs-01 (http:// > www.ietf.org/internet-drafts/draft-pister-roll-indus-routing- > reqs-01.txt) as a ROLL WG document ? > > Thanks. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-4-948095035 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII In = favor!

Cheers,
Jau.

= On Apr 23, 2008, at 12:12 PM, JP Vasseur wrote:
Dear WG,

A new revision of = draft-pister-roll-indus-routing-reqs has been published = addressing a number of comments (the authors mentioned to us that there = are still a few comments to address that require some discussion the = list).

= Could you tell us whether you are in favor or opposed to the adoption of = draft-pister-roll-indus-routing-reqs-01 (http://www.ietf.org/internet-drafts/draft-pister-roll-indu= s-routing-reqs-01.txt) as a ROLL WG document ?

Thanks.
=
JP.
Roll mailing list
=

= --Apple-Mail-4-948095035-- --===============1791475636== 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 --===============1791475636==-- From roll-bounces@ietf.org Thu Apr 24 05:21:33 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FBC128C1BA; Thu, 24 Apr 2008 05:21:33 -0700 (PDT) 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 A54C228C11C for ; Thu, 24 Apr 2008 05:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 p-z04zcV5sHu for ; Thu, 24 Apr 2008 05:21:29 -0700 (PDT) Received: from cedar.ugent.be (cedar.ugent.be [157.193.49.14]) by core3.amsl.com (Postfix) with ESMTP id ADE6428C13B for ; Thu, 24 Apr 2008 05:21:28 -0700 (PDT) Received: from gorilla.ugent.be (HELO localhost) ([157.193.49.20]) by cedar.ugent.be with ESMTP; 24 Apr 2008 14:21:33 +0200 Received: from cedar.ugent.be ([157.193.49.14]) by localhost (gorilla.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id 03862-04-3; Thu, 24 Apr 2008 14:21:33 +0200 (CEST) Received: from mail4.intec.ugent.be ([157.193.214.4]) by cedar.ugent.be with ESMTP; 24 Apr 2008 14:21:33 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEUYEEidwdYE/2dsb2JhbACtTQ Received: from localhost (localhost [127.0.0.1]) by mail4.intec.ugent.be (Postfix) with ESMTP id C912C40B2B9; Thu, 24 Apr 2008 14:21:32 +0200 (CEST) Received: from mail4.intec.ugent.be ([127.0.0.1]) by localhost (mail4.intec.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVi4QJ44pHcm; Thu, 24 Apr 2008 14:21:32 +0200 (CEST) Received: from [157.193.214.151] (crane.intec.ugent.be [157.193.214.151]) by mail4.intec.ugent.be (Postfix) with ESMTP id 877B140011C; Thu, 24 Apr 2008 14:21:32 +0200 (CEST) Message-ID: <48107B2E.2000308@intec.ugent.be> Date: Thu, 24 Apr 2008 14:21:02 +0200 From: Pieter De Mil User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: JP Vasseur References: In-Reply-To: X-Virus-Scanned: by UGent DICT Cc: roll@ietf.org Subject: Re: [Roll] Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org In favor. Pieter JP Vasseur wrote: > Dear WG, > > A new revision of draft-pister-roll-indus-routing-reqs has been > published addressing a number of comments (the authors mentioned to us > that there are still a few comments to address that require some > discussion the list). > > Could you tell us whether you are in favor or opposed to the adoption > of draft-pister-roll-indus-routing-reqs-01 > (http://www.ietf.org/internet-drafts/draft-pister-roll-indus-routing-reqs-01.txt) > > as a ROLL WG document ? > > Thanks. > > JP. > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > -- Pieter De Mil Department of Information Technology (INTEC) Ghent University Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium tel.: +32-9331 4981; tel. secr.: +32-9331 4900 fax: +32-9331 4899 pieter.demil@intec.ugent.be http://www.ibcn.intec.ugent.be Confidentiality Statement: This e-mail and any attached files are confidential and may be legally privileged. If you are not the addressee, any disclosure, reproduction, copying, distribution, or other dissemination or use of this communication is strictly prohibited. If you have received this transmission in error please notify INTEC immediately and then delete this e-mail. INTEC does not accept liability for the correct and complete transmission of the information, nor for any delay or interruption of the transmission, nor for damages arising from the use of or reliance on the information. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Apr 24 06:18:18 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 829453A6BAC; Thu, 24 Apr 2008 06:18:18 -0700 (PDT) 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 2299E3A6918 for ; Thu, 24 Apr 2008 06:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 mgwoWkTlcvbM for ; Thu, 24 Apr 2008 06:18:16 -0700 (PDT) Received: from scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by core3.amsl.com (Postfix) with ESMTP id 9F4DE3A6A08 for ; Thu, 24 Apr 2008 06:18:15 -0700 (PDT) Received: from leo (postfix@leo.cttc.es [84.88.62.208]) by scorpius.cttc.es (8.13.8/8.13.5) with ESMTP id m3ODE2so015780 for ; Thu, 24 Apr 2008 15:15:19 +0200 Received: from CTTCPCMDOHLER (pcmdohler.cttc.es [84.88.61.89]) by leo (Postfix) with ESMTP id 55D8F10C209 for ; Thu, 24 Apr 2008 13:55:32 +0200 (CEST) From: "Mischa Dohler" To: Date: Thu, 24 Apr 2008 13:54:29 +0200 Organization: CTTC MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: Thread-Index: AcilXOW89ql1dLl4bE+Lol0n5SDswAApQSYQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Message-Id: <20080424115532.55D8F10C209@leo> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (leo); Thu, 24 Apr 2008 13:55:32 +0200 (CEST) X-Scanned-By: MIMEDefang 2.57 on 84.88.62.197 Subject: Re: [Roll] Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG Document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mischa.dohler@cttc.es List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1816805557==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============1816805557== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0073_01C8A612.B7490FE0" This is a multi-part message in MIME format. ------=_NextPart_000_0073_01C8A612.B7490FE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am in favor. Mischa. _____ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Wednesday, April 23, 2008 6:13 PM To: roll@ietf.org Subject: [Roll] Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG Document Dear WG, A new revision of draft-pister-roll-indus-routing-reqs has been published addressing a number of comments (the authors mentioned to us that there are still a few comments to address that require some discussion the list). Could you tell us whether you are in favor or opposed to the adoption of draft-pister-roll-indus-routing-reqs-01 (http://www.ietf.org/internet-drafts/draft-pister-roll-indus-routing-reqs-01 .txt) as a ROLL WG document ? Thanks. JP. ------=_NextPart_000_0073_01C8A612.B7490FE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG Document

I am in favor. = Mischa.

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur
Sent: Wednesday, April = 23, 2008 6:13 PM
To: roll@ietf.org
Subject: [Roll] Adoption = of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG = Document

 

Dear WG,

A new revision of draft-pister-roll-indus-ro= uting-reqs has been published addressing a number of comments (the authors = mentioned to us that there are still a few comments to address that require some = discussion the list).

Could you tell us whether you are in favor or opposed to the adoption of = draft-pister-roll-indus-ro= uting-reqs-01 (http://www.ietf.org/internet-drafts/draft-pister-roll-in= dus-routing-reqs-01.txt) as a ROLL WG document ?

Thanks.

JP.

------=_NextPart_000_0073_01C8A612.B7490FE0-- --===============1816805557== 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 --===============1816805557==-- From roll-bounces@ietf.org Thu Apr 24 07:35:01 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1FC93A69C8; Thu, 24 Apr 2008 07:35:01 -0700 (PDT) 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 B4F583A69C8 for ; Thu, 24 Apr 2008 07:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.349 X-Spam-Level: X-Spam-Status: No, score=-4.349 tagged_above=-999 required=5 tests=[AWL=-1.366, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, TVD_SPACE_RATIO=2.219] 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 k-cL9FpSv0n7 for ; Thu, 24 Apr 2008 07:35:00 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 97EBB3A67A8 for ; Thu, 24 Apr 2008 07:34:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,704,1199682000"; d="scan'208,217";a="6227652" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 24 Apr 2008 10:35:03 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3OEZ3El026941 for ; Thu, 24 Apr 2008 10:35:03 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3OEZ3aQ007648 for ; Thu, 24 Apr 2008 14:35:03 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Apr 2008 10:35:03 -0400 Received: from 10.86.104.189 ([10.86.104.189]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 24 Apr 2008 14:35:03 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Thu, 24 Apr 2008 10:35:01 -0400 From: JP Vasseur To: Message-ID: Thread-Topic: IETF-72 Important Dates Thread-Index: AcimGGCX1UrrxYNnIUy2lKCspaHkXA== Mime-version: 1.0 X-OriginalArrivalTime: 24 Apr 2008 14:35:03.0484 (UTC) FILETIME=[62121FC0:01C8A618] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=747; t=1209047703; x=1209911703; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20IETF-72=20Important=20Dates |Sender:=20 |To:=20; bh=KFwkZvZeDLK36Jw9YWo8otum6oEbg47sw2kZeaO4J7Y=; b=dmlb9fhWcV2CJkHnnoXxbhSGh1SOQCF/W3DMIern1d9RMGIpSbJq1X/3yx ck3nvKaE96+g/wo+JK6lCXV6Su9feHmuKAfJdNpwsO58lBuo+hV33GOfASl6 iyq58hehpE; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [Roll] IETF-72 Important Dates 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="===============0228936362==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0228936362== Content-type: multipart/alternative; boundary="B_3291878102_7286879" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3291878102_7286879 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit http://www.ietf.org/meetings/72/72-cutoff_dates.html --B_3291878102_7286879 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable IETF-72 Important Dates http://www.ietf.org/meetings/72/72-cutoff_dates.html --B_3291878102_7286879-- --===============0228936362== 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 --===============0228936362==-- From roll-bounces@ietf.org Thu Apr 24 08:59:56 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A21E028C287; Thu, 24 Apr 2008 08:59:56 -0700 (PDT) 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 EE7F728C26F for ; Thu, 24 Apr 2008 08:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 JtIEj50DbAF2 for ; Thu, 24 Apr 2008 08:59:54 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id C91A128C294 for ; Thu, 24 Apr 2008 08:59:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id A1F83A92F7; Thu, 24 Apr 2008 08:59:58 -0700 (PDT) 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 xXvbRbDO9qhU; Thu, 24 Apr 2008 08:59:51 -0700 (PDT) Received: from [192.168.7.66] (69-12-164-139.sfo.archedrock.com [69.12.164.139]) by mail.sf.archrock.com (Postfix) with ESMTP id 73975A9286; Thu, 24 Apr 2008 08:59:51 -0700 (PDT) Message-Id: <069E453E-62CA-406F-B984-653FA5CA5C22@archrock.com> From: Jonathan Hui To: JP Vasseur In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 24 Apr 2008 08:59:47 -0700 References: X-Mailer: Apple Mail (2.919.2) Cc: roll@ietf.org Subject: Re: [Roll] Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG 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: , Content-Type: multipart/mixed; boundary="===============0064720321==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0064720321== Content-Type: multipart/alternative; boundary=Apple-Mail-1-964837547 --Apple-Mail-1-964837547 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Kris and Pascal: First off, significant step forward from the initial draft. I'm in favor of adopting this as a WG doc. Some comments on the latest draft: - Section 2.1: Last paragraph on 'critical control', are we really trying to address this? - We need to tighten up the terminology in Section 2.2, bringing in IETF terms where we mean them and clarifying other terms where we don't. Specifically, I think it's important to clarify the network architecture needed to support industrial applications. For example, the current figure in 2.2.1 and the use of 'gateway', 'backbone router', etc. seem to imply that the network architecture operates as a single link-local scope. I hope that's not intended here, as what does it mean to do IP routing when communication is limited to a single IP link? Are the backbone routers doing IP-level routing? Does the gateway only provide application-level services? I know this is borrowed directly from ISA100.11a, but we should map the terms appropriately and define them clearly. - Section 2.2.1, last paragraph, there's a mention to 'constrained routes'. At the first ROLL WG meeting, we had a good discussion of whether or not we really mean to say 'constraint-based routing' or not. There was concern that 'constraint-based' routing, as known within the IETF, is a difficult problem. - Section 3, Periodic Data: The last sentence requires a bit more clarification. Even if the network delivered the data in bursts, the application could be appropriately designed to handle the bursts simply by buffering the data (i.e. traffic-shaping at the application- layer). - Section 3, Event Data: priority service for what? throughput? latency? - Section 3, Bulk Transfer: be a little careful with the last sentence there, it's suggesting a solution space, not characterizing the application requirements. This point is addressed in the following paragraph anyway. - Section 3.1: The wording could use some improvement. How is the first MUST really different from the second MUST? I think the second implies the first. - Section 5, last paragraph: Again, did you really mean 'constraint- based' routing? - Section 6: what is 'broadcast' addressing in IPv6? -- Jonathan Hui On Apr 23, 2008, at 9:12 AM, JP Vasseur wrote: > Dear WG, > > A new revision of draft-pister-roll-indus-routing-reqs has been > published addressing a number of comments (the authors mentioned to > us that there are still a few comments to address that require some > discussion the list). > > Could you tell us whether you are in favor or opposed to the > adoption of draft-pister-roll-indus-routing-reqs-01 (http://www.ietf.org/internet-drafts/draft-pister-roll-indus-routing-reqs-01.txt > ) as a ROLL WG document ? > > Thanks. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-1-964837547 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

Kris and = Pascal:

First off, significant step forward = from the initial draft. I'm in favor of adopting this as a WG = doc.

Some comments on the latest = draft:

- Section 2.1: Last paragraph on = 'critical control', are we really trying to address = this?

- We need to tighten up the terminology = in Section 2.2, bringing in IETF terms where we mean them and clarifying = other terms where we don't. Specifically, I think it's important to = clarify the network architecture needed to support industrial = applications. For example, the current figure in 2.2.1 and the use = of 'gateway', 'backbone router', etc. seem to imply that the network = architecture operates as a single link-local scope. I hope that's not = intended here, as what does it mean to do IP routing when communication = is limited to a single IP link? Are the backbone routers doing IP-level = routing? Does the gateway only provide application-level services? I = know this is borrowed directly from ISA100.11a, but we should map the = terms appropriately and define them clearly.

- = Section 2.2.1, last paragraph, there's a mention to 'constrained = routes'. At the first ROLL WG meeting, we had a good discussion of = whether or not we really mean to say 'constraint-based routing' or not. = There was concern that 'constraint-based' routing, as known within the = IETF, is a difficult problem.

- Section 3, = Periodic Data: The last sentence requires a bit more clarification. Even = if the network delivered the data in bursts, the application could be = appropriately designed to handle the bursts simply by buffering the data = (i.e. traffic-shaping at the = application-layer).

- Section 3, Event Data: = priority service for what? throughput? = latency?

- Section 3, Bulk Transfer: be a = little careful with the last sentence there, it's suggesting a solution = space, not characterizing the application requirements. This point is = addressed in the following paragraph anyway.

- = Section 3.1: The wording could use some improvement. How is the first = MUST really different from the second MUST? I think the second implies = the first.

- Section 5, last paragraph: Again, = did you really mean 'constraint-based' = routing?

- Section 6: what is 'broadcast' = addressing in IPv6?

--
Jonathan = Hui



On Apr 23, = 2008, at 9:12 AM, JP Vasseur wrote:

= Dear WG,

A new revision of = draft-pister-roll-indus-routing-reqs has been published = addressing a number of comments (the authors mentioned to us that there = are still a few comments to address that require some discussion the = list).

= Could you tell us whether you are in favor or opposed to the adoption of = draft-pister-roll-indus-routing-reqs-01 (http://www.ietf.org/internet-drafts/draft-pister-roll-indu= s-routing-reqs-01.txt) as a ROLL WG document ?

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

= --Apple-Mail-1-964837547-- --===============0064720321== 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 --===============0064720321==-- From roll-bounces@ietf.org Fri Apr 25 04:45:11 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6623A6DE1; Fri, 25 Apr 2008 04:45:11 -0700 (PDT) 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 E8DA628C0F3 for ; Fri, 25 Apr 2008 04:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.021 X-Spam-Level: X-Spam-Status: No, score=-3.021 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 fSCXbArhOVaT for ; Fri, 25 Apr 2008 04:45:02 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id BCC7B3A6DDA for ; Fri, 25 Apr 2008 04:45:01 -0700 (PDT) Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Apr 2008 13:45:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 25 Apr 2008 13:45:03 +0200 Message-ID: <941BA0BF46DB8F4983FF7C8AFE800BC20799E780@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re : Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG Document Thread-Index: Acimyc0OO48sBykpTPW3ewuUV2zQhg== From: To: X-OriginalArrivalTime: 25 Apr 2008 11:45:04.0862 (UTC) FILETIME=[CDA1A7E0:01C8A6C9] Subject: [Roll] Re : Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG 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: , Content-Type: multipart/mixed; boundary="===============1709444804==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============1709444804== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A6C9.CD6FC2DF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A6C9.CD6FC2DF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all, Lots of insightful info on industrial control. I'm all in favor of adoption. Dominique A few typos : 1. Terminology ; Plant Application : "to perform tasks that may..." 3. Service Requirements ; "For industrial applications, Service = parameters .." 10. Security : "In industrial plants, it must..." Also, in 2.2.1, I found the sentence starting with "Considering that = though each ..." difficult to read. It misses a few commas at least. = Might be better to rewrite. Dominique BARTHEL France T=E9l=E9com Division R&D TECH/MATIS 28 chemin du Vieux Ch=EAne e-mail : = dominique.barthel@rd.francetelecom.com 38243 Meylan Cedex voice : (+33) 4 76 76 45 22 France fax : (+33) 4 76 76 44 50 ------_=_NextPart_001_01C8A6C9.CD6FC2DF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re : Adoption of draft-pister-roll-indus-routing-reqs-01 as a = ROLL WG Document

Hello all,

Lots of insightful info on industrial = control.
I'm all in favor of adoption.

Dominique

A few typos :
1. Terminology ; Plant Application : = "to perform tasks that may…"
3. Service Requirements ; "For = industrial applications, Service parameters .."
10. Security : "In industrial = plants, it must…"

Also, in 2.2.1, I found the sentence = starting with "Considering that though each …" difficult = to read. It misses a few commas at least. Might be better to = rewrite.

Dominique BARTHEL

France = T=E9l=E9com Division = R&D     =         TECH/MATIS
28 chemin du = Vieux Ch=EAne        =         =         e-mail : dominique.barthel@rd.francetelecom.com
38243 Meylan = Cedex      =         =         voice : (+33) 4 76 76 45 = 22
France  =         =         =         =         fax :     = (+33) 4 76 76 44 50

------_=_NextPart_001_01C8A6C9.CD6FC2DF-- --===============1709444804== 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 --===============1709444804==-- From roll-bounces@ietf.org Fri Apr 25 06:16:54 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E98A528C0F4; Fri, 25 Apr 2008 06:16:54 -0700 (PDT) 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 25F823A6DC5 for ; Fri, 25 Apr 2008 06:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.127 X-Spam-Level: X-Spam-Status: No, score=0.127 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HOST_MISMATCH_COM=0.311, 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 yQGwRIlf3wUD for ; Fri, 25 Apr 2008 06:16:46 -0700 (PDT) Received: from zensys17.zensys.local (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 0740B28C308 for ; Fri, 25 Apr 2008 06:15:57 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 25 Apr 2008 15:16:01 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3EB68B2A@zensys17.zensys.local> In-Reply-To: <47F0EECB.1000605@intec.ugent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Home Requirements Feedback Thread-Index: AciTN7mSOQi6dqYPQ0SkXDMbeluxqQTmeOeQ References: <47EB5153.9000509@ens-lyon.fr> <47F0EECB.1000605@intec.ugent.be> From: "Anders Brandt" To: Subject: Re: [Roll] Home Requirements Feedback 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="===============0831897621==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============0831897621== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A6D6.8250FFCA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A6D6.8250FFCA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all =20 Thanks for all the comments Having read through the comments, I see the same line as I observed during the Philly session: =20 * MUST/SHOULD statements should be kept out of use cases * Requirements should be more precise + not too narrow where not needed * The need for Groupcast in particular should be described in more detail * "Constrained" is a very specific term in the IETF which we should use with care =20 Concerning gateways -=20 I am not sure what to think. Basically, the idea of going to IP in wireless sensors is to get transparent connectivity all these lovely devices. On the other hand, the case described of having different providers (power utilities, surveillance service, etc) or wanting to have redundant access to the PAN leads to solutions with multiple access paths. I suppose these boxes are basically routers in a full-IP environment? And the same problem applies to industrial? =20 Finally, the issue raised about the smoke alarm having to not only activate an alarm but also turn on one or more groups of lights is very interesting. It must be so plain simple that I can trust my mother in law to set it up correctly - remember this is consumer space ;-) An the same type of problem applies to energy conservation / heating control. Interesting issues, but not so simple to specify and not simpler to implement. I would love to add more to the draft in this area. Please feel free to contribute. =20 I have done a first shot on the way to an updated draft. All (significant) changes have been marked - starting with "[ABR ". Please find it below. Most of the comments posted during the last month should be addressed but please let me know what can be further improved. =20 Giorgio, I look forward to see more details from you on the healthcare section! I added a bit already. =20 Thanks, Anders ------------------------------------------------------------------- =20 Networking Working Group A. Brandt=20 Internet Draft Zensys, Inc.=20 Intended status: Informational JP. Vasseur=20 Expires: October 25, 2008 Cisco Systems, Inc.=20 April 25, 2008=20 =20 =20 Home Automation Routing Requirement in Low Power and Lossy Networks=20 draft-brandt-roll-home-routing-reqs-01=20 =20 Status of this Memo=20 =20 By submitting this Internet-Draft, each author represents that =20 any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.=20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any=20 time. It is inappropriate to use Internet-Drafts as reference=20 material or to cite them other than as "work in progress."=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt =20 =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html =20 =20 This Internet-Draft will expire on October 24, 2008.=20 =20 Copyright Notice=20 =20 Copyright (C) The IETF Trust (2008).=20 =20 Abstract=20 =20 This document presents the home control and automation application=20 specific requirements for ROuting in Low power and Lossy networks=20 (ROLL). In a modern home, a high number of wireless devices are used=20 for a wide set of purposes. Examples include lighting control=20 modules, heating control panels, light sensors, temperature sensors,=20 gas/water leak detector, motion detectors, video surveillance,=20 =20 =20 =20 Brandt Expires October 25, 2008 [Page 1]=20 =0C Internet-Draft draft-brandt-roll-home-routing-reqs April 2008=20 =20 =20 healthcare systems and advanced remote controls. Because such devices only cover a limited radio range, multi-hop routing is often=20 required. Such devices are usually highly constrained in terms of=20 resources such as battery and memory and operate in unstable=20 environments. The aim of this document is to specify the routing=20 requirements for networks comprising such constrained devices in a=20 home network environment. =20 =20 Requirements Language=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=20 document are to be interpreted as described in RFC-2119 Error!=20 Reference source not found..=20 =20 Table of Contents=20 =20 =20 1. Terminology....................................................3=20 2. Introduction...................................................3=20 3. Home automation applications...................................4=20 3.1. Turning off the house.....................................4=20 3.2. Moving a remote control around............................5=20 3.3. Adding a new lamp module to the system....................5=20 3.4. Controlling battery operated window shades................6=20 3.5. Networked smoke alarm.....................................6=20 3.6. Remote video surveillance.................................6=20 3.7. Healthcare................................................7=20 3.8. Alarm systems.............................................7=20 4. Unique requirements of home automation applications............7=20 4.1. Support of groupcast......................................8=20 4.2. Node constrained Routing..................................8=20 4.3. Support of Mobility.......................................9=20 4.4. Scalability..............................................10=20 4.5. Convergence Time.........................................10=20 4.6. Manageability............................................10=20 5. Traffic pattern...............................................11=20 6. Open issues...................................................11=20 7. Security Considerations.......................................12=20 8. IANA Considerations...........................................12=20 9. Acknowledgments...............................................12=20 10. References...................................................12=20 10.1. Normative References....................................12=20 10.2. Informative References..................................12=20 Author's Addresses...............................................12=20 Intellectual Property Statement..................................13=20 Disclaimer of Validity...........................................13=20 =20 =20 Brandt Expires October 25, 2008 [Page 2]=20 =0C Internet-Draft draft-brandt-roll-home-routing-reqs April 2008=20 =20 =20 =20 1. Terminology=20 =20 ROLL: ROuting in Low-power and Lossy networks=20 =20 Access Point: The access point is an infrastructure device that=20 connects the low power and lossy network system to the=20 Internet, possibly via a customer premises local area=20 network (LAN).=20 =20 LAN: Local Area Network.=20 =20 PAN: Personal Area Network.=20 A geographically limited wireless network based on=20 e.g. 802.15.4 or Z-Wave radio.=20 =20 Channel: RF frequency band used to transmit a modulated signal=20 carrying packets.=20 =20 Downstream: Data direction traveling from a LAN to a PAN device.=20 =20 Upstream: Data direction traveling from a PAN to a LAN device.=20 =20 RF: Radio Frequency.=20 =20 Sensor: A PAN device that measures data and/or detects an=20 event.=20 =20 HA: Home Automation.=20 =20 =20 =20 2. Introduction=20 =20 This document presents the home control and automation application=20 specific requirements for Routing in Low power and Lossy Networks=20 (ROLL). In a modern home, a high number of wireless devices are used=20 for a wide set of purposes. Examples include lighting control=20 modules, heating control panels, light sensors, temperature sensors,=20 gas/water leak detector, motion detectors, video surveillance,=20 healthcare systems and advanced remote controls. Basic home control=20 modules such as wall switches and plug-in modules may be turned into=20 an advanced home automation solution via the use of an IP-enabled=20 application responding to events generated by wall switches, motion=20 sensors, light sensors, rain sensors, and so on.=20 =20 =20 =20 Brandt Expires October 25, 2008 [Page 3]=20 =0C Internet-Draft draft-brandt-roll-home-routing-reqs April 2008=20 =20 =20 Because such devices only cover a limited radio range, multi-hop=20 routing is often required. These devices are usually highly=20 constrained in term of resources such as battery and memory and=20 operate in unstable environments. Persons moving around in a house,=20 opening or closing a door or starting a microwave oven affect=20 reception of weak radio signals. Reflection and absorption may cause=20 a reliable connection to turn unreliable for a period of time and=20 then being reusable again, thus the term "lossy".=20 =20 Unlike other categories of PANs, the connected home area is very much consumer-oriented. The implications on network nodes in this aspect,=20 is that devices are very cost sensitive, which leads to resource- constrained environments having slow CPUs and small memory=20 footprints. At the same time, nodes have to physically small which=20 puts a limit to the physical size of the battery; and thus, the=20 battery capacity. As a result, it is common for low-power sensor- style nodes to shut down radio and CPU resources for most of the=20 time. Often, the radio uses almost just as much power for listening=20 as for transmitting.=20 =20 Section X describes a few typical use cases for home automation=20 applications. Section X discusses the routing requirements for=20 networks comprising such constrained devices in a home network=20 environment. These requirements may be overlapping requirements=20 derived from other application-specific requirements documents or as=20 listed in [I-D.culler-roll-routing-reqs].=20 =20 3. Home automation applications=20 =20 Home automation applications represent a special segment of networked wireless devices with its unique set of requirements. To facilitate=20 the requirements discussion in Section 4, this section lists a few=20 typical use cases of home automation applications. New applications=20 are being developed at a high pace and this section does not mean to=20 be exhaustive. Most home automation applications tend to be running=20 some kind of command/response protocol. The command may come from=20 several places. For instance a lamp may be turned on, not only be a=20 wall switch but also from a movement sensor.=20 =20 3.1. Turning off the house=20 =20 Using the direct analogy to an electronic car key, a house owner may=20 activate the "leaving home" function from an electronic house key,=20 mobile phone, etc. For the sake of visual impression, all lights=20 should turn off at the same time. At least, it should appear to=20 happen at the same time. A well-known problem in wireless home=20 automation is the "popcorn effect": Lamps are turned on one at a=20 =20 =20 Brandt Expires October 25, 2008 [Page 4]=20 =0C Internet-Draft draft-brandt-roll-home-routing-reqs April 2008=20 =20 =20 time, at a rate so slow that it is clearly visible. This phenomenon=20 mostly applies to very low bandwidth RF systems. Some existing home=20 automation solutions use a clever mix of a "subnet groupcast" message with no acknowledgement and no forwarding before sending acknowledged singlecast messages to each lighting device.=20 =20 [ABR REMOVED: Broadcast packets cannot be used for this since some=20 lights should stay on.]=20 =20 The controller forms the groups and decides which nodes should=20 receive "turn-off" or "turn-on" requests.=20 =20 [ABR REMOVED: Thus, traditional IP multicast cannot be used for such=20 applications, since multicast relies on the receivers to subscribe to multicasted streams.]=20 =20 [ABR PROPOSED RE-WORDING: Thus, a solution is needed for addressing=20 groups of nodes without prior management of group membership in the=20 receiving nodes.]=20 =20 3.2. Moving a remote control around=20 =20 A remote control is a typical example of a mobile device in a home=20 automation network. An advanced remote control may be used for=20 dimming the light in the dining room while eating and later on,=20 turning up the music while doing the dishes in the kitchen. Reaction=20 must appear to be instant (within a few hundred milliseconds) even=20 when the remote control has moved to a new location. The remote=20 control may be communicating to either a central home automation=20 controller or directly to the lamps and the media center.=20 =20 [ABR REMOVED: The routing protocol MUST support multiple paths. The=20 routing protocol MUST be able to locate a working path within 250ms,=20 given that a working path exists and it has been used before.]=20 =20 3.3. Adding a new lamp module to the system=20 =20 [ABR REMOVED: Small-size, low-cost modules may have no user interface except for a single button. Thus, an automated inclusion process is=20 needed for light controllers to find new modules. The routing=20 protocol MUST support re-discovery of neighbors when a new device is=20 added to the network. The routing protocol MAY scan for neighbors on=20 a frequent basis. This scanning process MUST NOT use significant=20 network bandwidth resources.]=20 =20 [ABR PROPOSED RE-WORDING: Small-size, low-cost modules may have no=20 user interface except for a single button. Thus, an automated=20 =20 =20 Brandt Expires October 25, 2008 [Page 5]=20 =0C Internet-Draft draft-brandt-roll-home-routing-reqs April 2008=20 =20 =20 inclusion process is needed for controllers to find new modules.=20 Inclusion covers the detection of neighbors and assignment of a=20 unique node ID. Inclusion should be completed within a few seconds.]=20 =20 3.4. Controlling battery operated window shades=20 =20 In consumer premises, window shades are often battery-powered as=20 there is no access to mains power over the windows. For battery=20 conservation purposes, the receiver is sleeping most of the time. A=20 home automation controller sending commands to window shades via ROLL resources will have no problems delivering the packet to the router,=20 but the router will have to wait for some time before the command can be delivered to the window shades; e.g. up to 250ms.=20 =20 3.5. Networked smoke alarm=20 =20 Some smoke alarms are battery powered and at the same time mounted in a high place. Battery-powered safety devices should only be used for=20 routing if no other alternatives exist. A smoke alarm with a drained=20 battery does not provide a lot of safety. Also, it may be=20 inconvenient to exchange battery in a smoke alarm. Finally, routing=20 via battery-powered nodes may be very slow if they are sleeping most=20 of the time.=20 [ABR ADDED: All of the above-mentioned reasons suggest that routing=20 should be avoided via this category of devices.]=20 =20 3.6. Remote video surveillance=20 =20 Remote video surveillance is a fairly classic application for Home=20 networking providing the ability for the end user to get a video=20 stream from a Web Cam reached via the Internet, which can be=20 triggered by the end-user that has received an alarm from a movement=20 sensor or smoke detector - or the user simply wants to check the home status via video.=20 Note that in the former case, more than likely, there will be a form=20 of inter-device communication: indeed, upon detecting some movement=20 in the home, the movement sensor may send a request to the light=20 controller to turn-on the lights, to the Web Cam to start a video=20 stream that would then be directed to the end user (cell phone, PDA)=20 via the Internet.=20 By contrast with other application where for example a large number=20 of ROLL devices such as industrial sensors where the data would=20 mainly be originated by sensor to a sink and vice versa, in such=20 scenario there is a direct inter-device communication between ROLL=20 devices.=20 =20 =20 =20 Brandt Expires October 25, 2008 [Page 6]=20 =0C Internet-Draft draft-brandt-roll-home-routing-reqs April 2008=20 =20 =20 3.7. Healthcare=20 =20 [ABR REMOVED: This section will be documented in further revision of=20 this document.]=20 =20 3.7.1. [ABR ADDED: At-home health monitoring]=20 =20 [ABR ADDED: By adding communication capability to devices, patients=20 and elderly citizens may be able to do simple measurements at home.=20 Thanks to the online devices, the doctor can keep an eye on the=20 patient's health and receive warnings if a new trend is discovered by automated filters. =20 =20 Measurement applications might include:=20 =20 o Temperature=20 =20 o Weight=20 =20 o Blood pressure=20 =20 o Insulin level=20 =20 The abovementioned applications may be realized as wearable products=20 which frequently do a measurement and automatically deliver the=20 result to a data sink locally or over the Internet.=20 =20 Fine-grained daily measurements presented in proper ways may allow=20 the doctor to establish a more precise diagnosis.=20 =20 From a ROLL perspective, all the above-mentioned applications may be=20 expected to be battery-powered. They may also be portable and=20 therefore need to locate a new neighbor router on a frequent basis.=20 Not being powered most of the time, the devices should not be used as routing nodes.=20 Delivery of measurement data has a limited requirement for route=20 discovery time compared to a remote control.]=20 =20 3.8. Alarm systems=20 =20 This section will be documented in further revision of this document. =20 3.9. [ABR ADDED: Battery-powered devices]=20 =20 [ABR ADDED: For convenience and low operational costs, power=20 consumption of consumer products must be kept at a very low level to=20 achieve a long battery lifetime. One implication of this fact is that =20 =20 Brandt Expires October 25, 2008 [Page 7]=20 =0C Internet-Draft draft-brandt-roll-home-routing-reqs April 2008=20 =20 =20 RAM memory is limited and it may even be powered down; leaving only a few 100 bytes alive during the sleep phase.]=20 =20 4. Unique requirements of home automation applications=20 =20 Home automation applications have a number of specific requirements=20 related to the set of home networking applications and the perceived=20 operation of the system.=20 =20 4.1. Support of groupcast=20 =20 [ABR REMOVED: The routing protocol MUST support multicast routing=20 with various scopes: local subnet, all devices. In other words, ]=20 =20 The routing protocol must provide the ability to route a packet=20 towards a single device (unicast), a set of devices (also referred to as "groupcast" in this document) or all devices (multicast) in the=20 house.=20 =20 The support of unicast, groupcast and multicast also has an=20 implication on the addressing scheme and are outside the scope of=20 this document that focuses on the routing requirements aspects.=20 =20 [ABR REMOVED Note: with IP Multicast, signaling mechanisms are used=20 by a receiver to join a group and the sender does not necessarily=20 know the receivers of the group. What is required is the ability to=20 address a group of receivers known by the sender even if the=20 receivers do not need to know that they have been grouped by the=20 sender (requesting each individual node to join a multicast group=20 would be very impractical).]=20 =20 [ABR PROPOSED REWORDING: It MUST be to possible to address a group of receivers known by the sender even if the receivers do not know that=20 they have been grouped by the sender.=20 =20 Alternatively, a companion specification SHOULD define how to=20 indirectly address a group of nodes on the application layer via=20 classic broadcast in the network layer; e.g. by use of a bitmap in a=20 header extension.]=20 =20 4.2. Metric-based Routing=20 =20 [ABR NOTE: IETF-71 WG meeting indicated that the term "constrained"=20 has a very specific meaning in the routing community inside IETF. I=20 think a specific definition of "Constrained" in the IETF sense should be added to the terminology section in the beginning of the document. =20 =20 =20 Brandt Expires October 25, 2008 [Page 8]=20 =0C Internet-Draft draft-brandt-roll-home-routing-reqs April 2008=20 =20 =20 What I understood was that the draft should be using the term=20 "metric-based routing"]=20 =20 Simple battery-powered nodes such as movement sensors on garage doors and rain meters may not be able to assist in routing. Depending on=20 the node type, the node never listens at all, listens rarely or makes contact on demand to a pre-configured target node. Attempting to=20 communicate to such nodes may require long time before getting a=20 response.=20 =20 [ABR REMOVED: Other battery-powered node may have the capability to=20 participate to the routing protocol but it may be preferable to=20 choose a (potentially longer) route via non battery powered devices=20 or via battery powered that have more energy.]=20 =20 [ABR ADDED: Other battery-powered nodes may have the capability to=20 participate in routing. The routing protocol should either share the=20 load between nodes to preserve battery or only route via mains- powered nodes if possible.]=20 =20 [ABR REMOVED: The routing protocol MUST support constraint based=20 routing taking into account node properties (CPU, memory, level of=20 energy, sleep intervals, safety/convenience of changing battery).]=20 =20 [ABR ADDED: The routing protocol MUST support metric-based routing=20 taking into account node properties (CPU, memory, level of energy,=20 sleep intervals, safety/convenience of changing battery).]=20 =20 4.3. Support of Mobility=20 =20 In a home environment, although the majority of devices are fixed=20 devices, there is still a variety of mobile devices: for example a=20 multi-purpose remote control is likely to move. Another example of=20 mobile devices is wearable healthcare devices.=20 =20 [ABR ADDED: While healthcare devices delivering measurement results=20 can tolerate route discovery times measured in seconds, a remote=20 control appears unresponsive if using more than 0.5 seconds to e.g.=20 pause the music.=20 =20 While, in theory, all battery-powered devices and mains-powered plug- in modules may be moved, the predominant case is that the sending=20 node has moved while the rest of the network has not changed.]=20 =20 [ABR REMOVED: The routing protocol MUST provide mobility with=20 convergence time within a few hundred milli-seconds.]=20 =20 =20 =20 Brandt Expires October 25, 2008 [Page 9]=20 =0C Internet-Draft draft-brandt-roll-home-routing-reqs April 2008=20 =20 =20 [ABR ADDED: The routing protocol MUST provide mobility with=20 convergence time below 0.5 second.]=20 =20 [ABR ADDED: The routing protocol SHOULD make use of the fact that if=20 not being able to deliver a packet, it is most likely that the=20 sending node moved; rather than the rest of the network.]=20 =20 4.4. Scalability=20 =20 Looking at the number of wall switches, power outlets, sensor of=20 various nature, video equipment and so on in a modern house, it seems quite realistic that hundreds of low power devices may form a home=20 automation network in a fully populated "smart" home. Moving towards=20 professional building automation, the number of such devices may be=20 in the order of several thousands.=20 =20 Thus the routing protocol MUST be highly scalable supporting a large=20 number of devices (at least a few hundreds of devices).=20 =20 4.5. Convergence Time=20 =20 A home automation PAN is subject to various instability due to signal strength variation, moving persons and the like. Furthermore, as the=20 number of devices increases, the probability of node failures also=20 increases. =20 =20 [ABR ADDED: Measured from the transmission of a packet, the following convergence time requirements apply.]=20 =20 [ABR REMOVED: In all cases, response time of the order of a few=20 hundreds of milliseconds are required, implying that the routing=20 protocol MUST converge (provide alternate routes upon link or node=20 failure) within a few hundreds of milliseconds.]=20 =20 [ABR ADDED: The routing protocol MUST converge within 0.5 second if=20 no nodes have moved.]=20 =20 [ABR ADDED: The routing protocol MUST converge within 2 seconds if=20 the destination node of the packet has moved.]=20 =20 4.6. Manageability=20 =20 The ability of the home network to support auto-configuration is of=20 the utmost importance. Indeed, most end users will not have the=20 expertise and the skills to perform advanced configuration and=20 troubleshooting. Thus the routing protocol designed for home PAN MUST =20 =20 =20 Brandt Expires October 25, 2008 [Page 10]=20 =0C Internet-Draft draft-brandt-roll-home-routing-reqs April 2008=20 =20 =20 provide a set of features including 0 configuration of the routing=20 protocol for a new node to be added to the network.=20 =20 Furthermore, a failing node MUST NOT have a global impact on the=20 routing protocol. The routing protocol SHOULD support the ability to=20 isolate a misbehaving node thus preserving the correct operation of=20 overall network.=20 =20 =20 =20 5. Traffic pattern=20 =20 Depending on the philosophy of the home network, wall switches may be configured to directly control individual lamps or alternatively, all wall switches send control commands to a central lighting control=20 computer which again sends out control commands to relevant devices.=20 =20 In a distributed system, the traffic tends to be any-to-many. In a=20 centralized system, it is a mix of any-to-one and one-to-many.=20 =20 [ABR REMOVED: A centralized system may benefit from a tree topology=20 routing strategy; having the central light controller close to the=20 root.=20 =20 A tree topology may prove inefficient for nodes in a distributed=20 system. A direct path from sender to receiver may be significantly=20 shorter than a path following the tree. A shorter path means lower=20 latency and less air-time use in a wireless media. Thus, routers MUST provide efficient any-to-many routing and MUST also support any-to- any routing without having to transit via a central point (e.g. tree=20 root) which would unavoidably lead to sub-optimal path in terms of=20 latency and energy consumption.]=20 =20 6. Open issues=20 =20 Other items to be addressed in further revisions of this document=20 include:=20 =20 o Healthcare=20 =20 o Alarm systems=20 =20 o Load Balancing (Symmetrical and Asymmetrical)=20 =20 o Security=20 =20 =20 =20 =20 Brandt Expires October 25, 2008 [Page 11]=20 =0C Internet-Draft draft-brandt-roll-home-routing-reqs April 2008=20 =20 =20 7. Security Considerations=20 =20 TBD=20 =20 8. IANA Considerations=20 =20 This document includes no request to IANA.=20 =20 9. Acknowledgments=20 =20 This document was prepared using 2-Word-v2.0.template.dot.=20 =20 =20 =20 10. References=20 =20 10.1. Normative References=20 =20 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=20 Requirement Levels", BCP 14, RFC 2119, March 1997.=20 =20 10.2. Informative References=20 =20 [I-D.culler-roll-routing-reqs]=20 Vasseur, J. and D. Culler, "Routing Requirements for Low Power And Lossy Networks",=20 draft-culler-roll-routing-reqs-* (work in progress).=20 =20 Author's Addresses=20 =20 Anders Brandt=20 Zensys, Inc.=20 Emdrupvej 26=20 Copenhagen, DK-2100=20 Denmark=20 =20 Email: abr@zen-sys.com =20 =20 =20 JP Vasseur=20 Cisco Systems, Inc.=20 1414 Massachusetts Avenue=20 Boxborough, MA 01719=20 USA=20 =20 Email: jvasseur@cisco.com =20 =20 =20 =20 Brandt Expires October 25, 2008 [Page 12]=20 =0C Internet-Draft draft-brandt-roll-home-routing-reqs April 2008=20 =20 =20 Intellectual Property Statement=20 =20 The IETF takes no position regarding the validity or scope of any=20 Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in=20 this document or the extent to which any license under such rights=20 might or might not be available; nor does it represent that it has=20 made any independent effort to identify any such rights. Information=20 on the procedures with respect to rights in RFC documents can be=20 found in BCP 78 and BCP 79.=20 =20 Copies of IPR disclosures made to the IETF Secretariat and any=20 assurances of licenses to be made available, or the result of an=20 attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this=20 specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr .=20 =20 The IETF invites any interested party to bring to its attention any=20 copyrights, patents or patent applications, or other proprietary=20 rights that may cover technology that may be required to implement=20 this standard. Please address the information to the IETF at=20 ietf-ipr@ietf.org .=20 =20 Disclaimer of Validity=20 =20 This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS=20 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=20 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=20 =20 Copyright Statement=20 =20 Copyright (C) The IETF Trust (2008).=20 =20 This document is subject to the rights, licenses and restrictions=20 contained in BCP 78, and except as set forth therein, the authors=20 retain all their rights.=20 =20 Acknowledgment=20 =20 Funding for the RFC Editor function is currently provided by the=20 Internet Society.=20 =20 =20 =20 Brandt Expires October 25, 2008 [Page 13]=20 =0C Internet-Draft draft-brandt-roll-home-routing-reqs April 2008=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Brandt Expires October 25, 2008 [Page 14]=20 =0C ------_=_NextPart_001_01C8A6D6.8250FFCA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear all
 
Thanks for all the = comments
Having read through the comments, I see the = same line=20 as I observed during the Philly session:
 
*=20 MUST/SHOULD statements should be kept out of use = cases
*=20 Requirements should be more precise + not too narrow where not=20 needed
*=20 The need for Groupcast in particular should be described in more=20 detail
*=20 "Constrained" is a very specific term in the IETF which we should use = with=20 care
 
Concerning gateways=20 -
I am = not sure what=20 to think.
Basically, the idea=20 of going to IP in wireless sensors is to get transparent connectivity = all these=20 lovely devices.
On the = other hand,=20 the case described of having different providers (power=20 utilities, surveillance service, etc) or wanting to have redundant = access=20 to the PAN leads to solutions with multiple access = paths.
I = suppose these=20 boxes are basically routers in a full-IP environment? And the same = problem=20 applies to industrial?
 
Finally, the issue=20 raised about the smoke alarm having to not only activate an alarm but = also turn=20 on one or more groups of lights is very interesting.
It = must be so plain=20 simple that I can trust my mother in law to set it up correctly - = remember this=20 is consumer space ;-)
An the = same type of=20 problem applies to energy conservation / heating control. Interesting = issues,=20 but not so simple to specify and not simpler to = implement.
I = would love to add=20 more to the draft in this area. Please feel free to=20 contribute.
 
I have = done a first=20 shot on the way to an updated draft. All (significant) changes have been = marked=20 - starting with "[ABR ". Please find it below.
Most = of the comments=20 posted during the last month should be addressed but please let me know = what can=20 be further improved.
 
Giorgio, I look=20 forward to see more details from you on the healthcare section! I added = a bit=20 already.
 
Thanks,
  = Anders
-------------------------------------------------------------------<= /FONT>
 
Networking=20 Working=20 Group           &n= bsp;           &nb= sp;           &nbs= p; =20 A. Brandt
Internet=20 Draft           &n= bsp;           &nb= sp;           &nbs= p;        =20 Zensys, Inc.
Intended status:=20 Informational          =             &= nbsp;      =20 JP. Vasseur
Expires: October 25,=20 2008           &nb= sp;           &nbs= p;  =20 Cisco Systems, Inc.=20
           &nb= sp;           &nbs= p;            = ;            =         =20 April 25, 2008=20
 
          = ;            =             &= nbsp;  =20
    Home Automation Routing Requirement in Low Power = and=20 Lossy Networks=20
           &nb= sp;     =20 draft-brandt-roll-home-routing-reqs-01
 

Status of this Memo
 
   By submitting this = Internet-Draft,=20 each author represents that       =
  =20 any applicable patent or other IPR claims of which he or she=20 is      
   aware have been = or will=20 be disclosed, and any of which he or = she      =20
   becomes aware will be disclosed, in accordance with = Section 6=20 of      
   BCP 79. =
 
   Internet-Drafts are working = documents=20 of the Internet Engineering
   Task Force (IETF), its = areas, and=20 its working groups. Note that other
   groups may also = distribute=20 working documents as Internet-Drafts.
 
   Internet-Drafts are draft = documents=20 valid for a maximum of six months
   and may be updated, = replaced,=20 or obsoleted by other documents at any
   time. It is=20 inappropriate to use Internet-Drafts as reference
   = material or=20 to cite them other than as "work in progress."
 
   The list of current = Internet-Drafts=20 can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
 
   The list of Internet-Draft = Shadow=20 Directories can be accessed at
   http://www.ietf.org/shadow.html
 
   This Internet-Draft will = expire on=20 October 24, 2008.
 
Copyright Notice
 
   Copyright (C) The IETF = Trust (2008).=20
 
Abstract
 
   This document presents the = home=20 control and automation application
   specific = requirements for=20 ROuting in Low power and Lossy networks
   (ROLL). In a = modern=20 home, a high number of wireless devices are used
   for a = wide set=20 of purposes. Examples include lighting control
   modules, = heating=20 control panels, light sensors, temperature sensors,
   = gas/water=20 leak detector, motion detectors, video surveillance,=20
 
 
 
Brandt     &nb= sp;          =20 Expires October 25,=20 2008           &nb= sp;   =20 [Page 1]
=0C
Internet-Draft  =20 draft-brandt-roll-home-routing-reqs      &n= bsp; =20 April 2008
   
 
   healthcare systems and = advanced=20 remote controls. Because such devices
   only cover a = limited=20 radio range, multi-hop routing is often
   required. Such = devices=20 are usually highly constrained in terms of
   resources = such as=20 battery and memory and operate in unstable
   = environments. The=20 aim of this document is to specify the routing
   = requirements for=20 networks comprising such constrained devices in a
   home = network=20 environment. 
 
Requirements Language
 
   The key words "MUST", "MUST = NOT",=20 "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD = NOT",=20 "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document = are to be=20 interpreted as described in RFC-2119 Error!
   Reference = source=20 not found..
 
Table of Contents
 
   
   1.=20 Terminology....................................................3=20
   2.=20 Introduction...................................................3=20
   3. Home automation=20 applications...................................4=20
      3.1. Turning off the=20 house.....................................4 =
     =20 3.2. Moving a remote control around............................5=20
      3.3. Adding a new lamp module to the=20 system....................5
      3.4. = Controlling=20 battery operated window shades................6=20
      3.5. Networked smoke=20 alarm.....................................6 =
     =20 3.6. Remote video surveillance.................................6=20
      3.7.=20 Healthcare................................................7=20
      3.8. Alarm=20 systems.............................................7
   = 4. Unique=20 requirements of home automation applications............7=20
      4.1. Support of=20 groupcast......................................8=20
      4.2. Node constrained=20 Routing..................................8 =
     =20 4.3. Support of Mobility.......................................9=20
      4.4.=20 Scalability..............................................10=20
      4.5. Convergence=20 Time.........................................10=20
      4.6.=20 Manageability............................................10 =
   5.=20 Traffic pattern...............................................11=20
   6. Open=20 issues...................................................11 =
   7.=20 Security Considerations.......................................12=20
   8. IANA=20 Considerations...........................................12 =
   9.=20 Acknowledgments...............................................12=20
   10.=20 References...................................................12=20
      10.1. Normative=20 References....................................12=20
      10.2. Informative=20 References..................................12
   Author's = Addresses...............................................12 =
  =20 Intellectual Property Statement..................................13=20
   Disclaimer of=20 Validity...........................................13=20
 
 
Brandt       &= nbsp;        =20 Expires October 25,=20 2008           &nb= sp;   =20 [Page 2]
=0C
Internet-Draft  =20 draft-brandt-roll-home-routing-reqs      &n= bsp; =20 April 2008
   
 
   
1. Terminology=20
 
  =20 ROLL:        ROuting in Low-power and = Lossy=20 networks
 
   Access Point:  The = access point=20 is an infrastructure device that=20
           &nb= sp;    =20 connects the low power and lossy network system to the=20
           &nb= sp;    =20 Internet, possibly via a customer premises local area=20
           &nb= sp;    =20 network (LAN).
 
  =20 LAN:         Local Area Network. =
 
  =20 PAN:         Personal Area = Network.=20
           &nb= sp;    =20 A geographically limited wireless network based on=20
           &nb= sp;    =20 e.g. 802.15.4 or Z-Wave radio.
 
  =20 Channel:      RF frequency band used to = transmit a=20 modulated signal=20
           &nb= sp;    =20 carrying packets.
 
   Downstream:   = Data=20 direction traveling from a LAN to a PAN device.
 
   = Upstream:    =20 Data direction traveling from a PAN to a LAN device.
 
  =20 RF:          Radio = Frequency.=20
 
   = Sensor:     =20 A PAN device that measures data and/or detects an=20
           &nb= sp;    =20 event.
 
  =20 HA:          Home = Automation.=20
 
   
 
2. Introduction
 
   This document presents the = home=20 control and automation application
   specific = requirements for=20 Routing in Low power and Lossy Networks
   (ROLL). In a = modern=20 home, a high number of wireless devices are used
   for a = wide set=20 of purposes. Examples include lighting control
   modules, = heating=20 control panels, light sensors, temperature sensors,
   = gas/water=20 leak detector, motion detectors, video surveillance,
   = healthcare=20 systems and advanced remote controls. Basic home control =
  =20 modules such as wall switches and plug-in modules may be turned into=20
   an advanced home automation solution via the use of an=20 IP-enabled
   application responding to events generated = by wall=20 switches, motion
   sensors, light sensors, rain sensors, = and so=20 on.
 

 
 
Brandt       =          =20 Expires October 25,=20 2008           &nb= sp;   =20 [Page 3]
=0C
Internet-Draft  =20 draft-brandt-roll-home-routing-reqs      &n= bsp; =20 April 2008
   
 
   Because such devices only = cover a=20 limited radio range, multi-hop
   routing is often = required. These=20 devices are usually highly
   constrained in term of = resources=20 such as battery and memory and
   operate in unstable=20 environments. Persons moving around in a house,
   opening = or=20 closing a door or starting a microwave oven affect
   = reception of=20 weak radio signals. Reflection and absorption may cause
   = a=20 reliable connection to turn unreliable for a period of time and =
  =20 then being reusable again, thus the term "lossy".
 
   Unlike other categories of = PANs, the=20 connected home area is very much
   consumer-oriented. The = implications on network nodes in this aspect,
   is that = devices=20 are very cost sensitive, which leads to resource-
   = constrained=20 environments having slow CPUs and small memory
   = footprints. At=20 the same time, nodes have to physically small which
   = puts a=20 limit to the physical size of the battery; and thus, the =
  =20 battery capacity. As a result, it is common for low-power=20 sensor-
   style nodes to shut down radio and CPU resources = for=20 most of the
   time. Often, the radio uses almost just as = much=20 power for listening
   as for transmitting.
 
   Section X describes a few = typical use=20 cases for home automation
   applications. Section X = discusses the=20 routing requirements for
   networks comprising such = constrained=20 devices in a home network
   environment. These = requirements may=20 be overlapping requirements
   derived from other=20 application-specific requirements documents or as
   = listed in=20 [I-D.culler-roll-routing-reqs].
 
3. Home automation applications =
 
   Home automation = applications=20 represent a special segment of networked
   wireless = devices with=20 its unique set of requirements. To facilitate
   the = requirements=20 discussion in Section 4, this section lists a few
   = typical use=20 cases of home automation applications. New applications
   = are=20 being developed at a high pace and this section does not mean to=20
   be exhaustive. Most home automation applications tend = to be=20 running
   some kind of command/response protocol. The = command may=20 come from
   several places. For instance a lamp may be = turned on,=20 not only be a
   wall switch but also from a movement = sensor.=20
 
3.1. Turning off the house
 
   Using the direct analogy to = an=20 electronic car key, a house owner may
   activate the = "leaving=20 home" function from an electronic house key,
   mobile = phone, etc.=20 For the sake of visual impression, all lights
   should = turn off=20 at the same time. At least, it should appear to
   happen = at the=20 same time. A well-known problem in wireless home
   = automation is=20 the "popcorn effect": Lamps are turned on one at a=20
 
 
Brandt       &= nbsp;        =20 Expires October 25,=20 2008           &nb= sp;   =20 [Page 4]
=0C
Internet-Draft  =20 draft-brandt-roll-home-routing-reqs      &n= bsp; =20 April 2008
   
 
   time, at a rate so slow = that it is=20 clearly visible. This phenomenon
   mostly applies to very = low=20 bandwidth RF systems. Some existing home
   automation = solutions=20 use a clever mix of a "subnet groupcast" message
   with = no=20 acknowledgement and no forwarding before sending acknowledged =
  =20 singlecast messages to each lighting device.
 
   [ABR REMOVED: Broadcast = packets=20 cannot be used for this since some
   lights should stay = on.]=20
 
   The controller forms the = groups and=20 decides which nodes should
   receive "turn-off" or = "turn-on"=20 requests.
 
   [ABR REMOVED: Thus, = traditional IP=20 multicast cannot be used for such
   applications, since = multicast=20 relies on the receivers to subscribe to
   multicasted = streams.]=20
 
   [ABR PROPOSED RE-WORDING: = Thus, a=20 solution is needed for addressing
   groups of nodes = without prior=20 management of group membership in the
   receiving nodes.] =
 
3.2. Moving a remote control around =
 
   A remote control is a = typical example=20 of a mobile device in a home
   automation network. An = advanced=20 remote control may be used for
   dimming the light in the = dining=20 room while eating and later on,
   turning up the music = while=20 doing the dishes in the kitchen. Reaction
   must appear = to be=20 instant (within a few hundred milliseconds) even
   when = the=20 remote control has moved to a new location. The remote
   = control=20 may be communicating to either a central home automation =
  =20 controller or directly to the lamps and the media center.
 
   [ABR REMOVED: The routing = protocol=20 MUST support multiple paths. The
   routing protocol MUST = be able=20 to locate a working path within 250ms,
   given that a = working=20 path exists and it has been used before.]
 
3.3. Adding a new lamp module to the = system=20
 
   [ABR REMOVED: Small-size, = low-cost=20 modules may have no user interface
   except for a single = button.=20 Thus, an automated inclusion process is
   needed for = light=20 controllers to find new modules. The routing
   protocol = MUST=20 support re-discovery of neighbors when a new device is
   = added to=20 the network. The routing protocol MAY scan for neighbors on =
   a=20 frequent basis. This scanning process MUST NOT use significant =
  =20 network bandwidth resources.]
 
   [ABR PROPOSED RE-WORDING: = Small-size,=20 low-cost modules may have no
   user interface except for = a single=20 button. Thus, an automated=20
 
 
Brandt       &= nbsp;        =20 Expires October 25,=20 2008           &nb= sp;   =20 [Page 5]
=0C
Internet-Draft  =20 draft-brandt-roll-home-routing-reqs      &n= bsp; =20 April 2008
   
 
   inclusion process is needed = for=20 controllers to find new modules.
   Inclusion covers the = detection=20 of neighbors and assignment of a
   unique node ID. = Inclusion=20 should be completed within a few seconds.]
 
3.4. Controlling battery operated window = shades=20
 
   In consumer premises, = window shades=20 are often battery-powered as
   there is no access to = mains power=20 over the windows. For battery
   conservation purposes, = the=20 receiver is sleeping most of the time. A
   home = automation=20 controller sending commands to window shades via ROLL
   = resources=20 will have no problems delivering the packet to the router, =
   but=20 the router will have to wait for some time before the command can=20
   be delivered to the window shades; e.g. up to 250ms.=20
 
3.5. Networked smoke alarm
 
   Some smoke alarms are = battery powered=20 and at the same time mounted in
   a high place. = Battery-powered=20 safety devices should only be used for
   routing if no = other=20 alternatives exist. A smoke alarm with a drained
   = battery does=20 not provide a lot of safety. Also, it may be
   = inconvenient to=20 exchange battery in a smoke alarm. Finally, routing
   via = battery-powered nodes may be very slow if they are sleeping most=20
   of the time.
   [ABR ADDED: All of the=20 above-mentioned reasons suggest that routing
   should be = avoided=20 via this category of devices.]
 
3.6. Remote video surveillance =
 
   Remote video surveillance = is a fairly=20 classic application for Home
   networking providing the = ability=20 for the end user to get a video
   stream from a Web Cam = reached=20 via the Internet, which can be
   triggered by the = end-user that=20 has received an alarm from a movement
   sensor or smoke = detector=20 - or the user simply wants to check the home
   status via = video.=20
   Note that in the former case, more than likely, there = will be a=20 form
   of inter-device communication: indeed, upon = detecting some=20 movement
   in the home, the movement sensor may send a = request to=20 the light
   controller to turn-on the lights, to the Web = Cam to=20 start a video
   stream that would then be directed to the = end=20 user (cell phone, PDA)
   via the Internet. =
   By=20 contrast with other application where for example a large number=20
   of ROLL devices such as industrial sensors where the = data would=20
   mainly be originated by sensor to a sink and vice = versa, in=20 such
   scenario there is a direct inter-device = communication=20 between ROLL
   devices.
 

 
 
Brandt       =          =20 Expires October 25,=20 2008           &nb= sp;   =20 [Page 6]
=0C
Internet-Draft  =20 draft-brandt-roll-home-routing-reqs      &n= bsp; =20 April 2008
   
 
3.7. Healthcare
 
   [ABR REMOVED: This section = will be=20 documented in further revision of
   this document.] =
 
3.7.1.  [ABR ADDED: At-home health=20 monitoring]
 
   [ABR ADDED: By adding = communication=20 capability to devices, patients
   and elderly citizens = may be=20 able to do simple measurements at home.
   Thanks to the = online=20 devices, the doctor can keep an eye on the
   patient's = health and=20 receive warnings if a new trend is discovered by
   = automated=20 filters. 
 
   Measurement applications = might=20 include:
 
   o  Temperature =
 
   o  Weight =
 
   o  Blood pressure =
 
   o  Insulin level =
 
   The abovementioned = applications may=20 be realized as wearable products
   which frequently do a=20 measurement and automatically deliver the
   result to a = data sink=20 locally or over the Internet.
 
   Fine-grained daily = measurements=20 presented in proper ways may allow
   the doctor to = establish a=20 more precise diagnosis.
 
   From a ROLL perspective, = all the=20 above-mentioned applications may be
   expected to be=20 battery-powered. They may also be portable and
   = therefore need=20 to locate a new neighbor router on a frequent basis.
   = Not being=20 powered most of the time, the devices should not be used as =
  =20 routing nodes.
   Delivery of measurement data has a = limited=20 requirement for route
   discovery time compared to a = remote=20 control.]
 
3.8. Alarm systems
 
   This section will be = documented in=20 further revision of this document.
 
3.9. [ABR ADDED: Battery-powered = devices]=20
 
   [ABR ADDED: For convenience = and low=20 operational costs, power
   consumption of consumer = products must=20 be kept at a very low level to
   achieve a long battery = lifetime.=20 One implication of this fact is that=20
 
 
Brandt       &= nbsp;        =20 Expires October 25,=20 2008           &nb= sp;   =20 [Page 7]
=0C
Internet-Draft  =20 draft-brandt-roll-home-routing-reqs      &n= bsp; =20 April 2008
   
 
   RAM memory is limited and = it may even=20 be powered down; leaving only a
   few 100 bytes alive = during the=20 sleep phase.]
 
4. Unique requirements of home = automation=20 applications
 
   Home automation = applications have a=20 number of specific requirements
   related to the set of = home=20 networking applications and the perceived
   operation of = the=20 system.
 
4.1. Support of groupcast
 
   [ABR REMOVED: The routing = protocol=20 MUST support multicast routing
   with various scopes: = local=20 subnet, all devices. In other words, ]
 
   The routing protocol must = provide the=20 ability to route a packet
   towards a single device = (unicast), a=20 set of devices (also referred to
   as "groupcast" in this = document) or all devices (multicast) in the
   house.=20
 
   The support of unicast, = groupcast and=20 multicast also has an
   implication on the addressing = scheme and=20 are outside the scope of
   this document that focuses on = the=20 routing requirements aspects.
 
   [ABR REMOVED Note: with IP = Multicast,=20 signaling mechanisms are used
   by a receiver to join a = group and=20 the sender does not necessarily
   know the receivers of = the=20 group. What is required is the ability to
   address a = group of=20 receivers known by the sender even if the
   receivers do = not need=20 to know that they have been grouped by the
   sender = (requesting=20 each individual node to join a multicast group
   would be = very=20 impractical).]
 
   [ABR PROPOSED REWORDING: It = MUST be=20 to possible to address a group of
   receivers known by = the sender=20 even if the receivers do not know that
   they have been = grouped=20 by the sender.
 
   Alternatively, a companion=20 specification SHOULD define how to
   indirectly address a = group=20 of nodes on the application layer via
   classic broadcast = in the=20 network layer; e.g. by use of a bitmap in a
   header = extension.]=20
 
4.2. Metric-based Routing
 
   [ABR NOTE: IETF-71 WG = meeting=20 indicated that the term "constrained"
   has a very = specific=20 meaning in the routing community inside IETF. I
   think a = specific definition of "Constrained" in the IETF sense should =
  =20 be added to the terminology section in the beginning of the document.=20
 
 
 
Brandt       =          =20 Expires October 25,=20 2008           &nb= sp;   =20 [Page 8]
=0C
Internet-Draft  =20 draft-brandt-roll-home-routing-reqs      &n= bsp; =20 April 2008
   
 
   What I understood was that = the draft=20 should be using the term
   "metric-based routing"] =
 
   Simple battery-powered = nodes such as=20 movement sensors on garage doors
   and rain meters may = not be=20 able to assist in routing. Depending on
   the node type, = the node=20 never listens at all, listens rarely or makes
   contact = on demand=20 to a pre-configured target node. Attempting to
   = communicate to=20 such nodes may require long time before getting a
   = response.=20
 
   [ABR REMOVED: Other = battery-powered=20 node may have the capability to
   participate to the = routing=20 protocol but it may be preferable to
   choose a = (potentially=20 longer) route via non battery powered devices
   or via = battery=20 powered that have more energy.]
 
    [ABR ADDED: Other=20 battery-powered nodes may have the capability to
   = participate in=20 routing. The routing protocol should either share the
   = load=20 between nodes to preserve battery or only route via = mains-
  =20 powered nodes if possible.]
 
    [ABR REMOVED: The = routing=20 protocol MUST support constraint based
   routing taking = into=20 account node properties (CPU, memory, level of
   energy, = sleep=20 intervals, safety/convenience of changing battery).]
 
   [ABR ADDED: The routing = protocol MUST=20 support metric-based routing
   taking into account node=20 properties (CPU, memory, level of energy,
   sleep = intervals,=20 safety/convenience of changing battery).]
 
4.3. Support of Mobility
 
   In a home environment, = although the=20 majority of devices are fixed
   devices, there is still a = variety=20 of mobile devices: for example a
   multi-purpose remote = control=20 is likely to move. Another example of
   mobile devices is = wearable healthcare devices.
 
   [ABR ADDED: While = healthcare devices=20 delivering measurement results
   can tolerate route = discovery=20 times measured in seconds, a remote
   control appears=20 unresponsive if using more than 0.5 seconds to e.g.
   = pause the=20 music.
 
   While, in theory, all = battery-powered=20 devices and mains-powered plug-
   in modules may be moved, = the=20 predominant case is that the sending
   node has moved = while the=20 rest of the network has not changed.]
 
   [ABR REMOVED: The routing = protocol=20 MUST provide mobility with
   convergence time within a = few=20 hundred milli-seconds.]
 
 
 
Brandt       =          =20 Expires October 25,=20 2008           &nb= sp;   =20 [Page 9]
=0C
Internet-Draft  =20 draft-brandt-roll-home-routing-reqs      &n= bsp; =20 April 2008
   
 
   [ABR ADDED: The routing = protocol MUST=20 provide mobility with
   convergence time below 0.5 = second.]=20
 
   [ABR ADDED: The routing = protocol=20 SHOULD make use of the fact that if
   not being able to = deliver a=20 packet, it is most likely that the
   sending node moved; = rather=20 than the rest of the network.]
 
4.4. Scalability
 
   Looking at the number of = wall=20 switches, power outlets, sensor of
   various nature, = video=20 equipment and so on in a modern house, it seems
   quite = realistic=20 that hundreds of low power devices may form a home
   = automation=20 network in a fully populated "smart" home. Moving towards =
  =20 professional building automation, the number of such devices may be=20
   in the order of several thousands.
 
   Thus the routing protocol = MUST be=20 highly scalable supporting a large
   number of devices = (at least=20 a few hundreds of devices).
 
4.5. Convergence Time
 
   A home automation PAN is = subject to=20 various instability due to signal
   strength variation, = moving=20 persons and the like. Furthermore, as the
   number of = devices=20 increases, the probability of node failures also
  =20 increases. 
 
   [ABR ADDED: Measured from = the=20 transmission of a packet, the following
   convergence = time=20 requirements apply.]
 
   [ABR REMOVED: In all cases, = response=20 time of the order of a few
   hundreds of milliseconds are = required, implying that the routing
   protocol MUST = converge=20 (provide alternate routes upon link or node
   failure) = within a=20 few hundreds of milliseconds.]
 
   [ABR ADDED: The routing = protocol MUST=20 converge within 0.5 second if
   no nodes have moved.]=20
 
   [ABR ADDED: The routing = protocol MUST=20 converge within 2 seconds if
   the destination node of = the packet=20 has moved.]
 
4.6. Manageability
 
   The ability of the home = network to=20 support auto-configuration is of
   the utmost importance. = Indeed,=20 most end users will not have the
   expertise and the = skills to=20 perform advanced configuration and
   troubleshooting. = Thus the=20 routing protocol designed for home PAN MUST
 
 
 
Brandt       =          =20 Expires October 25,=20 2008           &nb= sp;  =20 [Page 10]
=0C
Internet-Draft  =20 draft-brandt-roll-home-routing-reqs      &n= bsp; =20 April 2008
   
 
   provide a set of features = including 0=20 configuration of the routing
   protocol for a new node to = be=20 added to the network.
 
   Furthermore, a failing node = MUST NOT=20 have a global impact on the
   routing protocol. The = routing=20 protocol SHOULD support the ability to
   isolate a = misbehaving=20 node thus preserving the correct operation of
   overall = network.=20
 
   
 
5. Traffic pattern
 
   Depending on the philosophy = of the=20 home network, wall switches may be
   configured to = directly=20 control individual lamps or alternatively, all
   wall = switches=20 send control commands to a central lighting control
   = computer=20 which again sends out control commands to relevant devices. =
 
   In a distributed system, = the traffic=20 tends to be any-to-many. In a
   centralized system, it is = a mix=20 of any-to-one and one-to-many.
 
   [ABR REMOVED: A centralized = system=20 may benefit from a tree topology
   routing strategy; = having the=20 central light controller close to the
   root. =
 
   A tree topology may prove = inefficient=20 for nodes in a distributed
   system. A direct path from = sender to=20 receiver may be significantly
   shorter than a path = following the=20 tree. A shorter path means lower
   latency and less = air-time use=20 in a wireless media. Thus, routers MUST
   provide = efficient=20 any-to-many routing and MUST also support any-to-
   any = routing=20 without having to transit via a central point (e.g. tree =
   root)=20 which would unavoidably lead to sub-optimal path in terms of =
  =20 latency and energy consumption.]
 
6. Open issues
 
   Other items to be addressed = in=20 further revisions of this document
   include: =
 
   o  Healthcare =
 
   o  Alarm systems =
 
   o  Load Balancing = (Symmetrical=20 and Asymmetrical)
 
   o  Security =
 
   =20
 
 
Brandt       &= nbsp;        =20 Expires October 25,=20 2008           &nb= sp;  =20 [Page 11]
=0C
Internet-Draft  =20 draft-brandt-roll-home-routing-reqs      &n= bsp; =20 April 2008
   
 
7. Security Considerations
 
   TBD
 
8. IANA Considerations
 
   This document includes no = request to=20 IANA.
 
9. Acknowledgments
 
   This document was prepared = using=20 2-Word-v2.0.template.dot.
 
   
 
10. References
 
10.1. Normative References
 
   [RFC2119] Bradner, S., "Key = words for=20 use in RFCs to Indicate=20
           &nb= sp;=20 Requirement Levels", BCP 14, RFC 2119, March 1997.
 
10.2. Informative References =
 
   = [I-D.culler-roll-routing-reqs]=20
           &nb= sp;=20 Vasseur, J. and D. Culler, "Routing Requirements for=20 Low           =20
           &nb= sp;=20 Power And Lossy Networks",=20
           &nb= sp;=20 draft-culler-roll-routing-reqs-* (work in progress).
 
Author's Addresses
 
   Anders Brandt =
  =20 Zensys, Inc.
   Emdrupvej 26
   Copenhagen, = DK-2100=20
   Denmark
 
   Email: abr@zen-sys.com=20
   
 
   JP Vasseur
   = Cisco=20 Systems, Inc.
   1414 Massachusetts Avenue =
  =20 Boxborough, MA 01719
   USA=20
      
   Email: = jvasseur@cisco.com =
   =20
 
 
Brandt       &= nbsp;        =20 Expires October 25,=20 2008           &nb= sp;  =20 [Page 12]
=0C
Internet-Draft  =20 draft-brandt-roll-home-routing-reqs      &n= bsp; =20 April 2008
   
 
Intellectual Property Statement =
 
   The IETF takes no position = regarding=20 the validity or scope of any
   Intellectual Property = Rights or=20 other rights that might be claimed to
   pertain to the=20 implementation or use of the technology described in
   = this=20 document or the extent to which any license under such rights =
  =20 might or might not be available; nor does it represent that it has=20
   made any independent effort to identify any such = rights.=20 Information
   on the procedures with respect to rights in = RFC=20 documents can be
   found in BCP 78 and BCP 79. =
 
   Copies of IPR disclosures = made to the=20 IETF Secretariat and any
   assurances of licenses to be = made=20 available, or the result of an
   attempt made to obtain a = general=20 license or permission for the use of
   such proprietary = rights by=20 implementers or users of this
   specification can be = obtained=20 from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.=20
 
   The IETF invites any = interested party=20 to bring to its attention any
   copyrights, patents or = patent=20 applications, or other proprietary
   rights that may = cover=20 technology that may be required to implement
   this = standard.=20 Please address the information to the IETF at
   ietf-ipr@ietf.org. =
 
Disclaimer of Validity
 
   This document and the = information=20 contained herein are provided on an
   "AS IS" basis and = THE=20 CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS = SPONSORED=20 BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   = THE=20 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS=20
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY = THAT THE=20 USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY = RIGHTS OR=20 ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS = FOR A=20 PARTICULAR PURPOSE.
 
Copyright Statement
 
   Copyright (C) The IETF = Trust (2008).=20
 
   This document is subject to = the=20 rights, licenses and restrictions
   contained in BCP 78, = and=20 except as set forth therein, the authors
   retain all = their=20 rights.
 
Acknowledgment
 
   Funding for the RFC Editor = function=20 is currently provided by the
   Internet Society. =
 
 
 
Brandt       =          =20 Expires October 25,=20 2008           &nb= sp;  =20 [Page 13]
=0C
Internet-Draft  =20 draft-brandt-roll-home-routing-reqs      &n= bsp; =20 April 2008
   
 
   
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 
 
Brandt       =          =20 Expires October 25,=20 2008           &nb= sp;  =20 [Page 14]
=0C
------_=_NextPart_001_01C8A6D6.8250FFCA-- --===============0831897621== 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 --===============0831897621==-- From roll-bounces@ietf.org Fri Apr 25 09:43:55 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A4283A6D82; Fri, 25 Apr 2008 09:43:55 -0700 (PDT) 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 C98953A6B0E for ; Fri, 25 Apr 2008 09:43:53 -0700 (PDT) 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, 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 5goNVhJEIuww for ; Fri, 25 Apr 2008 09:43:51 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9F1DD28C1E5 for ; Fri, 25 Apr 2008 09:43:50 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 25 Apr 2008 09:43:55 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3PGhtdq026356; Fri, 25 Apr 2008 09:43:55 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3PGhriI003173; Fri, 25 Apr 2008 16:43:55 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Apr 2008 09:43:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 25 Apr 2008 09:39:43 -0700 Message-ID: <52E903A38F544F46A2A6632AC66103EE05B672A4@xmb-sjc-221.amer.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05957E1E@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Comments on the Industrial Requirements Draft Thread-Index: Acig25aMZtoMlMkoTRiF/C9PXXBqnwFEXJTQAEFkn6A= References: <4807D10D.8090202@cs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC05957E1E@xmb-ams-337.emea.cisco.com> From: "Shitanshu Shah (svshah)" To: "Pascal Thubert (pthubert)" , "David E. Culler" , X-OriginalArrivalTime: 25 Apr 2008 16:43:54.0703 (UTC) FILETIME=[8CA645F0:01C8A6F3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=20091; t=1209141835; x=1210005835; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=svshah@cisco.com; z=From:=20=22Shitanshu=20Shah=20(svshah)=22=20 |Subject:=20RE=3A=20[Roll]=20Comments=20on=20the=20Industri al=20Requirements=20Draft |Sender:=20; bh=jEZVHLKv215imnCMuH1oFBfWDqA+LvuGUVYnFY985NQ=; b=YuJ0GoVGsDPl+x6JRsH1urivc4eBmHqffEDCEJiX1PbqrEly8MashVxQPS GdOrJcRDV3ijzSXjeyjGnIuXk5daW45R7BBpZym4LAn+Colyd+vix+HD1CRO W4kOtEk6xrWC0QsngLri/KVKgqBleChr0ITVaWIpmRL4ZZEQZrnIQ=; Authentication-Results: sj-dkim-1; header.From=svshah@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Roll] Comments on the Industrial Requirements 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Pascal, > Transmission priority - this seems to address forwarding, rather than = > routing. > > [Pascal] right. Maybe we need to get this out. It's just good = > information though I don't have a strong opinion but IMO it is good to take out forwarding = specifics (not only it is irrelevant to routing requirements but is = also partial specifics for service forwarding) As mentioned in my private response to you Pascal, if the purpose is to = highlight that forwarding should not even face the situation where if = such action required it may affect the service requirement then it is better to call out service requirements explicitly. Which I think you have called out very well (btw, nice work there) cheers Shitanshu = > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On = > Behalf Of Pascal Thubert (pthubert) > Sent: Thursday, April 24, 2008 2:29 AM > To: David E. Culler; roll@ietf.org > Subject: Re: [Roll] Comments on the Industrial Requirements Draft > = > = > Hi David: > = > I'm trying to summarize here what we did or did not do (yet) = > about your comments here. BTW thanks a huge deal for your = > help here. Also this response som=F9etimes reflects my opinion = > and not necessarily a consensus amonst the authors. > = > I note that there's still work to do on 3.1 and 7 for the = > chicken and an egg problem between routing and dynamic radio = > links instantiations, in section 10 about security and = > provisionning, and per your comments on rev 1. > = > Also: to avoid nested >>> I kept your text without a > and = > added mine prefixed with [Pascal] > = > --------------------------------------------------------- > = > = > = > = > = > Now that we have our first WG document, let's keep things = > rolling. The following are comments on the Industrial = > Routing Requirements draft from November 9. Hope they are helpful. > = > 1. Terminology > - defines access point, but not router. In the ROLL WG = > meeting there was a good deal of terminology discussion = > because the term gateway was used in places where router was = > intended. Here that confusion has been avoided, but it may = > make sense to be clear on where the R in ROLL is involved. > = > [Pascal] we need to find the right term. Right now L2N AP > = > = > - "host application" may be a little confusing. In IP = > terms, the field devices is also a host. = > = > [Pascal] now plant application > = > = > - Superframe - a very specific link layer mechanism. Unclear = > that it belongs in a routing requirements doc. > = > [Pascal] gone > = > - HART - belongs in Informative Reference section (where it = > does appear). Probably not in Terminology. > - ISA - same > = > [Pascal] Not done yet. I would agree though; terminology = > mostly defines new terms and refers to docs for existing terms > = > Slotted-link - specific choice of link layer media access = > control mechanism. Unclear in belongs in routing requirements doc. > Timeslot - same > = > [Pascal] still a ref in section 5 that we could remove > = > 2. Introduction > = > page 4: can access points be wireless too? Presumably not = > low power or lossy > = > [Pascal] sure but then we need to express the same = > reliability and security as in the WSN. At this point the = > term "wired" was removed. > = > "wired HART" - should other wired industrial options be = > mentioned, like foundation field bus? > = > [Pascal] still there. No big del is it? and yes we could name = > the alternate > = > capacity analysis is for a localized region. It does not = > account for spatial reuse, which is expected to be common = > place in geographically large deployments - where Routing is = > most critical. > = > [Pascal] Should routing know about spatial reuse? Is there = > text that this specifically aims at changing or is it entirely new? > = > 2.1 - class are out of sp100.11a RFP. Should it be referenced? > = > [Pascal] yes I think so. > = > Critical function... add "those that" > = > [Pascal] fixed, removed 'are' > = > Page 5 - customers =3D> users > = > [Pascal] done > = > discussion of typical data rates is important. Should that = > paragraph draw implications for route update rates? > = > [Pascal] there is now a section on route maintenance > = > Page 6 > = > Nine-9s discussion seems a bit misleading. Trues that there = > are a trillion seconds in 30 years, but that is hardly the = > point. This seems to suggest that there is no mechanism for = > error detection or recovery anywhere other than plant shutdown. > = > [Pascal] I also fail to understand this text: > "In critical control, tens of milliseconds of latency is = > typical. In > many of these systems, if a packet does not arrive within the > specified interval, the system enters an emergency shutdown state, > often with substantial financial repercussions. For a one-second > control loop in a system with a mean-time between = > shutdowns target of > 30 years, the latency requirement implies nine 9s of reliability." > = > First MUST relates to multi-topology routing. It seems like = > it would be good to develop more fully what we mean by this = > in the industrial setting. > = > [Pascal] that text is gone and the development was done in section 2.2 > = > Second MUST seems entirely out of place. "color = > slotted-links" is a particular form of a particular link = > layer mechanism. It may be a great thing, but it hardly = > seems like it belongs in a routing requirements doc. There = > is probably a requirement having to do with isolation or = > predictability or something that this particular solution was = > standing as a proxy for. We should try to state the = > requirement, rather than dictate a particular solution at this stage. > = > [Pascal] isolation is missing in that version but we are = > working on it for the next version > = > Third MUST is indeed a very important point that should = > bubble up to a requirement, but it isn't developed here. It = > wants supporting evidence, which fundamentally relates to the = > L's. Note that this is the reverse of previous MUST. This = > one takes general characteristics of the underlying link and = > the needs of applications to yield a requirement on routing. = > That is what these docs should do. = > = > [Pascal] what about this text: > = > "" > The logical topologies > ---------------------- > = > Publication > ----------- > = > Most of the traffic over the LLN is publish/subscribe of = > sensor data from the field device towards the backbone router = > or gateway that acts as the sink for the WSN. The = > destination of the sensor data is an Infrastructure devices = > that sits on the backbone and is reachable via one or more = > backbone router. Since publishing the data is the raison = > d'etre for most of the sensors, it makes sense to build = > proactively a set of default routes between the sensors and = > one or more backbone router and maintain those routes at all = > time. Also, because of the lossy nature of the network, the = > routing in place should attempt to propose multiple = > forwarding solutions, building non congruent forwarding = > topologies in the form of Directed acyclic graphs oriented = > towards the sinks. Note that for a control application, the = > jitter is just as important as latency and has a potential of = > destabilizing control algorithms. = > = > = > = > Closed loop > ----------- > = > In contrast with the general requirement of maintaining = > default routes towards the sinks, the need for field device = > to field device connectivity is only occasional, though the = > traffic associated might be of foremost importance. An = > example of field device to field device traffic is a control = > loop between a vibration sensor and an actuator that can stop = > a motor that is failing. A class 0 control loop requires = > guaranteed delivery and extremely tight response times. In = > other words, both the respect of criteria in the route = > computation and the quality of the maintenance of the route = > are critical for the field devices operation. The = > requirements vary with the operations of the field devices = > but in a general fashion field device to field device routes = > will often be the most critical, optimized and well-maintained. > = > " > = > = > QoS. > -3. Is 200 ms serving as a bound or an expected? > -4. Can we bound limited period? > = > QoS as a term is gone because it's forwarding. We used the = > term service and changed this 200 to hundereds of ms. = > = > QoS parameters > = > Transmission time seems to be calling for time correlated = > sampling, i.e., NTP, rather than coordinated transmissions. = > Are we establishing a requirement or advocating a solution? > = > = > [Pascal] is there text left to be changed for this remark? > [Pascal] Do you disagree with text about Transmission phase? = > If so would you propose an alternate text? = > = > Reliability - 99.9% - Should probably clarify that this is end-to-end. > = > [Pascal] This text is gone = > = > Transmission priority - this seems to address forwarding, = > rather than routing. > = > [Pascal] right. Maybe we need to get this out. It's just good = > information though > = > Page 7-8. We should be careful not to confuse the presence = > of a particular approach or solution with a requirement. > = > [Pascal] referenced to slotted are gone > = > Page 8. "MUST be able to set up routes that are = > directional". Is this to mean that A ----> B need not follow = > the reverse of the route B -----A. Or is this dealing with = > the asymmetry of the flows? > = > [Pascal] we added text: > " Industrial application data flows between field devices are not > necessarily symmetric. In particular, asymmetrical cost and > unidirectional routes are common for published data and = > alerts, which > represent the most part of the sensor traffic. The = > routing protocol > MUST be able to set up unidirectional or asymmetrical cost routes > that are composed of one or more non congruent paths. > " > = > 3.1 two additional MUSTs. First seems like it needs to be = > clarified. I think it is trying to get at adjusting to = > different flow rates - sampling may be very different from = > maintenance. This primarily a forwarding issue. Even with = > adaptation, it doesn't mean that it MUST be changing. > = > = > [Pascal] I would agree on this. If the routing has = > established multiple path then a forwarding protocol can = > control the bandwidth and latency in real time and that can = > be all a forwarding issue. I note that we have to work some = > more on 3.1 > = > Second MUST confuses dynamic path determination with a = > particular link layer mechanism. First is probably the = > intended requirement. Send is a particular solution. > = > = > [Pascal] I would agree on this too. There is a chicken and an = > egg problem between routing an link provisionning when links = > can be provisionned dynamically. This is nothing new if you = > consider traffic engineering. We have to figure what we = > really want. I see 2 options: > - links come and go because they are used or not and L3 makes = > the best of it > - L3 uses virtual links that are actually instantiated when = > they are really needed and L2 tries to adapt to the traffic = > that L3 causes to go over links To be honest I think that the = > later makes more sense. > = > Section 4 para 2. Appears to define MAC requirement, rather = > than routing req. Perhaps is intended to define end-to-end = > application requirement. Also a piece of a service = > requirement (NTP?). > Throughout analysis is for a particular MAC. > Graph - Access points or routers? Both? > = > [Pascal] 4 moved into 2.2. The text you refer to is all gone now. = > = > Page 10. Section 7. Seems to want to deal with transient = > loss. Is it necessary to put it in terms of a particular = > link mechanism? > = > [Pascal] Terms were fixed (no more slotted links) but the = > chicken and an egg problem also discussed in 3.1 stays > = > section 8. Demographic discussion is probably accurate, but = > is it relevant for routing? "Should support the wireless = > worker" is probably a bit too vague a requirement. > = > [Pascal]Text with requirements was added in 2.2.1 in the long = > p=E2ragraph after the picture. = > Maybe this section (that is unchanged BTW) should move = > earlier in the doc to intriduce the issue? > = > section 9 - so is this calling for Autoconf? > = > [Pascal] Certainly something to look at when considering = > solution. We can dig into MANET and MANEMO history as well. > = > Section 10 - Claims of the relative tolerance to failure in = > these industries should probably be removed. > = > [Pascal] I agree we should remove the terms link banking = > industry which point at someone in particular. > There's also the discussion about keys, perimeter of security = > and related provisionning that needs rework. > This section should bequite improved with the help of new = > authors (Sicco Dwars and Tom Phinney) who were invited in. > = > = > = > = > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > = > Pascal > >-----Original Message----- > >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] = > On Behalf Of = > >David E. Culler > >Sent: vendredi 18 avril 2008 00:37 > >To: roll@ietf.org > >Subject: [Roll] Comments on the Industrial Requirements Draft > > > >Now that we have our first WG document, let's keep things = > rolling. The = > >following are comments on the Industrial Routing Requirements draft = > >from November 9. Hope they are helpful. > > > >1. Terminology > > - defines access point, but not router. In the ROLL WG = > meeting there = > >was a good deal of terminology discussion because the term = > gateway was = > >used in places where router was intended. Here that = > confusion has been = > >avoided, but it may make sense to be clear on where the R in ROLL is = > >involved. > > > > - "host application" may be a little confusing. In IP terms, the = > >field devices is also a host. > > > >- Superframe - a very specific link layer mechanism. = > Unclear that it = > >belongs in a routing requirements doc. > > > >- HART - belongs in Informative Reference section (where it does = > >appear). Probably not in Terminology. > >- ISA - same > > > >Slotted-link - specific choice of link layer media access control = > >mechanism. Unclear in belongs in routing requirements doc. > >Timeslot - same > > > >2. Introduction > > > >page 4: can access points be wireless too? Presumably not = > low power or = > >lossy > > > >"wired HART" - should other wired industrial options be = > mentioned, like = > >foundation field bus? > > > >capacity analysis is for a localized region. It does not = > account for = > >spatial reuse, which is expected to be common place in = > geographically = > >large deployments - where Routing is most critical. > > > >2.1 - class are out of sp100.11a RFP. Should it be referenced? > > > >Critical function... add "those that" > > > >Page 5 - customers =3D> users > > > >discussion of typical data rates is important. Should that = > paragraph = > >draw implications for route update rates? > > > >Page 6 > > > >Nine-9s discussion seems a bit misleading. Trues that there are a = > >trillion seconds in 30 years, but that is hardly the point. = > This seems = > >to suggest that there is no mechanism for error detection or = > recovery = > >anywhere other than plant shutdown. > > > >First MUST relates to multi-topology routing. It seems like = > it would = > >be good to develop more fully what we mean by this in the = > industrial setting. > > > >Second MUST seems entirely out of place. "color slotted-links" is a = > >particular form of a particular link layer mechanism. It may be a = > >great thing, but it hardly seems like it belongs in a routing = > >requirements doc. There is probably a requirement having to do with = > >isolation or predictability or something that this = > particular solution = > >was standing as a proxy for. We should try to state the = > requirement, = > >rather than dictate a particular solution at this stage. > > > >Third MUST is indeed a very important point that should = > bubble up to a = > >requirement, but it isn't developed here. It wants supporting = > >evidence, which fundamentally relates to the L's. Note that this is = > >the reverse of previous MUST. This one takes general = > characteristics = > >of the underlying link and the needs of applications to yield a = > >requirement on routing. That is what these docs should do. > > > >QoS. > > -3. Is 200 ms serving as a bound or an expected? > > -4. Can we bound limited period? > > > >QoS parameters > > > >Transmission time seems to be calling for time correlated sampling, = > >i.e., NTP, rather than coordinated transmissions. Are we = > establishing = > >a requirement or advocating a solution? > > > >Reliability - 99.9% - Should probably clarify that this is = > end-to-end. > > > >Transmission priority - this seems to address forwarding, = > rather than = > >routing. > > > >Page 7-8. We should be careful not to confuse the presence of a = > >particular approach or solution with a requirement. > > > >Page 8. "MUST be able to set up routes that are = > directional". Is this = > >to mean that A ----> B need not follow the reverse of the route B = > >-----A. Or is this dealing with the asymmetry of the flows? > > > >3.1 two additional MUSTs. First seems like it needs to be = > clarified. = > >I think it is trying to get at adjusting to different flow rates - = > >sampling may be very different from maintenance. This primarily a = > >forwarding issue. Even with adaptation, it doesn't mean = > that it MUST = > >be changing. > > > >Second MUST confuses dynamic path determination with a = > particular link = > >layer mechanism. First is probably the intended = > requirement. Send is = > >a particular solution. > > > >Section 4 para 2. Appears to define MAC requirement, rather than = > >routing req. Perhaps is intended to define end-to-end application = > >requirement. Also a piece of a service requirement (NTP?). > > > >Throughout analysis is for a particular MAC. > > > >Graph - Access points or routers? Both? > > > >Page 10. Section 7. Seems to want to deal with transient = > loss. Is it = > >necessary to put it in terms of a particular link mechanism? > > > >section 8. Demographic discussion is probably accurate, but is it = > >relevant for routing? "Should support the wireless worker" = > is probably = > >a bit too vague a requirement. > > > >section 9 - so is this calling for Autoconf? > > > >Section 10 - Claims of the relative tolerance to failure in these = > >industries should probably be removed. > > > > > > > > > > > > > >_______________________________________________ > >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 Sat Apr 26 14:01:38 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5192C3A6A51; Sat, 26 Apr 2008 14:01:38 -0700 (PDT) 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 29B463A6A91 for ; Sat, 26 Apr 2008 14:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 gI4PY+0mxd6N for ; Sat, 26 Apr 2008 14:01:33 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by core3.amsl.com (Postfix) with ESMTP id 2BC853A6A51 for ; Sat, 26 Apr 2008 14:01:33 -0700 (PDT) Received: from [192.168.2.38] (c-24-4-149-226.hsd1.ca.comcast.net [24.4.149.226]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.2/8.13.5) with ESMTP id m3QL1PXP025609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 26 Apr 2008 14:01:35 -0700 (PDT) Message-ID: <4813989C.4050308@eecs.berkeley.edu> Date: Sat, 26 Apr 2008 14:03:24 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Jonathan Hui References: <069E453E-62CA-406F-B984-653FA5CA5C22@archrock.com> In-Reply-To: <069E453E-62CA-406F-B984-653FA5CA5C22@archrock.com> Cc: roll@ietf.org Subject: Re: [Roll] Adoption of draft-pister-roll-indus-routing-reqs-01 as a ROLL WG 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Jonathan - thanks for the feedback. Responses inline. Jonathan Hui wrote: > > Kris and Pascal: > > First off, significant step forward from the initial draft. I'm in > favor of adopting this as a WG doc. > > Some comments on the latest draft: > > - Section 2.1: Last paragraph on 'critical control', are we really > trying to address this? It's unclear at this point how this will shake out, but it seemed like erring on the side of breadth was the right idea at least in the early going. Two years ago I would have said that it was going to be a long time before industrial people would use wireless for any kind of control. They were so incredibly, ahh, diligent about investigating reliability for non-critical monitoring that it seemed certain that the bar would be a lot higher for control. However, it appears that now that they've vetted the technology, they actually seem quite eager to put it into control applications. We'll just have to see how far that goes, but I have heard plant managers in several different places say that they think that their wireless networks may end up being more reliable than their wired networks! > > - We need to tighten up the terminology in Section 2.2, bringing in > IETF terms where we mean them and clarifying other terms where we > don't. Specifically, I think it's important to clarify the network > architecture needed to support industrial applications. For example, > the current figure in 2.2.1 and the use of 'gateway', 'backbone > router', etc. seem to imply that the network architecture operates as > a single link-local scope. I hope that's not intended here, as what > does it mean to do IP routing when communication is limited to a > single IP link? Are the backbone routers doing IP-level routing? Does > the gateway only provide application-level services? I know this is > borrowed directly from ISA100.11a, but we should map the terms > appropriately and define them clearly. Definitely not advocating a particular solution. You're right that we're using the industrial automation terminology here, but that is not intended to constrain us to single link-local scope. We just need to get the definition mapping correct, as you point out. Any suggestions? > > - Section 2.2.1, last paragraph, there's a mention to 'constrained > routes'. At the first ROLL WG meeting, we had a good discussion of > whether or not we really mean to say 'constraint-based routing' or > not. There was concern that 'constraint-based' routing, as known > within the IETF, is a difficult problem. Can you point me to something that will help me understand the IETF definition of constrained routing, and what the concerns are? My definition may be different, but I think that constrained routing is what makes this such a challenging and interesting problem. > > - Section 3, Periodic Data: The last sentence requires a bit more > clarification. Even if the network delivered the data in bursts, the > application could be appropriately designed to handle the bursts > simply by buffering the data (i.e. traffic-shaping at the > application-layer). Agreed that we need to clarify. I think that Pascal and I have both talked with different end users and have come up with a blend of their requirements here that isn't actually faithful to either. We'll clean it up. > > - Section 3, Event Data: priority service for what? throughput? latency? Latency. > > - Section 3, Bulk Transfer: be a little careful with the last sentence > there, it's suggesting a solution space, not characterizing the > application requirements. This point is addressed in the following > paragraph anyway. I was trying to address one of David's comments here. Any suggestions? Strike the last sentence? > > - Section 3.1: The wording could use some improvement. How is the > first MUST really different from the second MUST? I think the second > implies the first. In the first case, the routing algorithm is changing the underlying provisioning. This is a MUST, since until the service is requested it's quite likely that the underlying layer will be idling along at some very low power setting. In the second case, it's the fact that after the routing algorithm has set up routes and provisioned, the L2 environment may/will change, and the protocol needs to be able to adjust to that dynamically as well. > > - Section 5, last paragraph: Again, did you really mean > 'constraint-based' routing? Again, I did. But did what I meant mean the same thing to you :) > > - Section 6: what is 'broadcast' addressing in IPv6? My understanding is that we need to avoid being specific to v4 or v6, hence the "or". ksjp > > -- > Jonathan Hui > > > > On Apr 23, 2008, at 9:12 AM, JP Vasseur wrote: > >> Dear WG, >> >> A new revision of draft-pister-roll-indus-routing-reqs has been >> published addressing a number of comments (the authors mentioned to >> us that there are still a few comments to address that require some >> discussion the list). >> >> Could you tell us whether you are in favor or opposed to the adoption >> of draft-pister-roll-indus-routing-reqs-01 >> (http://www.ietf.org/internet-drafts/draft-pister-roll-indus-routing-reqs-01.txt) >> >> as a ROLL WG document ? >> >> Thanks. >> >> JP. >> _______________________________________________ >> 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 Apr 28 08:37:43 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35C9528C2AE; Mon, 28 Apr 2008 08:37:43 -0700 (PDT) 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 C716B28C2AE for ; Mon, 28 Apr 2008 08:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.908 X-Spam-Level: X-Spam-Status: No, score=-2.908 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, 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 dHzciXBEPyT9 for ; Mon, 28 Apr 2008 08:37:41 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 1753C28C29E for ; Mon, 28 Apr 2008 08:37:41 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 28 Apr 2008 08:37:44 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m3SFbiSM010771 for ; Mon, 28 Apr 2008 08:37:44 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3SFbe2S010407 for ; Mon, 28 Apr 2008 15:37:44 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Apr 2008 11:36:38 -0400 Received: from 161.44.71.254 ([161.44.71.254]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 28 Apr 2008 15:36:38 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Mon, 28 Apr 2008 11:36:38 -0400 From: JP Vasseur To: Message-ID: Thread-Topic: Adoption of draft-pister-roll-indus-routing-reqs as a ROLL WG document Thread-Index: AcipRaXTXonWVhmbYE2jvB0y8jOnXg== Mime-version: 1.0 X-OriginalArrivalTime: 28 Apr 2008 15:36:38.0389 (UTC) FILETIME=[A60EE250:01C8A945] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2014; t=1209397064; x=1210261064; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Adoption=20of=20draft-pister-roll-indus-routing -reqs=20as=20a=20ROLL=20WG=0A=20document |Sender:=20; bh=OfXzlrOArx50rYiSRAK1hvjXPsnGI7FTITzqZtL5Ygs=; b=avnFTLA9Nu7xm+GUhJMBaMBYfHAbZtN1rwZzongZCT/EfFTBzw1LwTHh0M tE3RWa5oQZu75Nr1y/hR1NZ6bWa/7P2T6iDJlEWQRzDOaWs/bWcSIgFNPqzc n6oqVd1vXp; Authentication-Results: sj-dkim-4; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Roll] Adoption of draft-pister-roll-indus-routing-reqs as a ROLL WG 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: , Content-Type: multipart/mixed; boundary="===============0454266470==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0454266470== Content-type: multipart/alternative; boundary="B_3292227399_1238461" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3292227399_1238461 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear WG, Considering the pretty good support adopt draft-pister-roll-indus-routing-reqs is adopted as a WG. Authors, please republish as draft-ietf-roll-indus-routing-reqs-00.txt with no change other than the file names, dates, ... Note that there are still several issues being discussed about the ID, thanks to resolve them on the list, and post a new revision as soon as possible. If I remember well, you also have new text to introduce coming from new authors. Thanks. JP. --B_3292227399_1238461 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Adoption of draft-pister-roll-indus-routing-reqs as a ROLL WG docume= nt Dear WG,

Considering the pretty good support adopt draft-pister-roll-indus-routing-= reqs is adopted as a WG. Authors, please republish as = draft-= ietf-roll-indus-routing-reqs-00.txt with no change other than= the file names, dates, ...

Note that there are still several issues being discussed about the ID, than= ks to resolve them on the list, and post a new revision as soon as possible.= If I remember well, you also have new text to introduce coming from new aut= hors.

Thanks.

JP. --B_3292227399_1238461-- --===============0454266470== 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 --===============0454266470==-- From roll-bounces@ietf.org Mon Apr 28 09:15:03 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BB9928C292; Mon, 28 Apr 2008 09:15:03 -0700 (PDT) X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 265C328C28D; Mon, 28 Apr 2008 09:15:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080428161502.265C328C28D@core3.amsl.com> Date: Mon, 28 Apr 2008 09:15:02 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-indus-routing-reqs-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: , 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 : Industrial Routing Requirements in Low Power and Lossy Networks Author(s) : D. Networks, P. Thubert Filename : draft-ietf-roll-indus-routing-reqs-00.txt Pages : 17 Date : 2008-04-28 Wireless, low power field devices enable industrial users to significantly increase the amount of information collected and the number of control points that can be remotely managed. The deployment of these wireless devices will significantly improve the productivity and safety of the plants while increasing the efficiency of the plant workers. For wireless devices to have a significant advantage over wired devices in an industrial environment the wireless network needs to have three qualities: low power, high reliability, and easy installation and maintenance. The aim of this document is to analyze the requirements for the routing protocol used for low power and lossy networks (L2N) in industrial environments.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 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-indus-routing-reqs-00.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-indus-routing-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-28091316.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--