From roll-bounces@ietf.org Fri Dec 5 07:18:28 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30A543A6C7B; Fri, 5 Dec 2008 07:18:28 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFAF73A6A47 for ; Fri, 5 Dec 2008 07:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 Erkf357Adj-R for ; Fri, 5 Dec 2008 07:18:26 -0800 (PST) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id 613CD3A6867 for ; Fri, 5 Dec 2008 07:18:25 -0800 (PST) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mB5FIIrp016163 for ; Fri, 5 Dec 2008 15:18:19 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mB5FIIMI027642 for ; Fri, 5 Dec 2008 15:18:18 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Fri, 05 Dec 2008 15:18:18 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Fri, 5 Dec 2008 15:18:18 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 5 Dec 2008 15:18:15 -0000 Message-ID: In-Reply-To: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Working Group Last Call: draft-ietf-roll-protocols-survey-02 Thread-Index: AclLo4gUAz8k4z8eTwSV7LCmkn2AhQLQGn9A References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> From: "Dearlove, Christopher (UK)" To: "JP Vasseur" , X-OriginalArrivalTime: 05 Dec 2008 15:18:18.0343 (UTC) FILETIME=[B3ABEF70:01C956EC] Subject: Re: [Roll] Working Group Last Call: draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org I think this document is correct in its assessment that no existing routing protocol meets the five rigid specifications given. However on the way to that conclusion - If the sole purpose is to answer the question as to whether any existing protocol meets the very tough standards given, then the purpose is met, the answer is no. But that doesn't actually help you take the next step. Are any of these protocols adaptable to meet theses requirements, or do you have to start from scratch? (And some of these protocols have more options than may be obvious. Just because as configured in existing specifications it fails, doesn't mean it always will. And some things that may appear fundamental may not be. For example I think it's quite easy to modify NHDP to bound its neighbourhood information in a dense network - and if it's not dense, it's bounded anyway. How well that modification works is however something that would need work to test.) - And why don't these protocols meet these specifications? OK, maybe the designers could have done better (I don't know). But maybe first there are other major issues that have to be traded off (latency for example - you can really cut down on signalling overheads if you allow unbounded latency), and second, can those constraints actually all be met in a reasonable way? (If not, there's a danger of start from clean sheet, discover along the way you need to compromise, and then that someone's already been down that route.) - Along the way, not everything is undisputed. For example in the traffic bounding considerations of OLSRv2 it is clear that neither the timing backoff nor "fisheye" variable flooding of OLSRv2 is taken into account. I'm not suggesting that these are enough to achieve the required O(N) bound (at least not without probably unacceptable delays) but the simple O(N^2) before MPR adjustment isn't necessarily quite that simple. (And how much you can use those features depends on density and variability, the latter of which is also a major issue.) I'm not suggesting another round of modifying the document, just putting down that the document has a narrow purpose, and shouldn't be stretched beyond it. It's fine that someone might say that this document shows that DYMO (for example) out of the box isn't what you want. (I don't personally know that to be true however.) But that shouldn't be taken as saying DYMO doesn't work, we must start afresh. I don't know if you could start with DYMO (or the other six protocols) and get to where you want to go. I'm just saying this document doesn't answer that question, but assuming that it does is a future danger to be avoided. As a minor nit however, in section 4.4, the use of O(R log(L) + e) where e is a small constant is, while not actually wrong, is confusing. O(R log(L) + e) is exactly the same as O(R log(L)). It's only meaningful to include e if using something other than big-O notation. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri Dec 5 08:49:59 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0421128C1BD; Fri, 5 Dec 2008 08:49:59 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 392E528C1BD for ; Fri, 5 Dec 2008 08:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHDsYg-RKCYh for ; Fri, 5 Dec 2008 08:49:57 -0800 (PST) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.177]) by core3.amsl.com (Postfix) with ESMTP id E519F28C1BC for ; Fri, 5 Dec 2008 08:49:56 -0800 (PST) Received: by ik-out-1112.google.com with SMTP id c29so73128ika.5 for ; Fri, 05 Dec 2008 08:49:51 -0800 (PST) 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:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=ZvpkMk7Z+u2kcQ8UXVxCWWMx+/YpaSLEL9FCUAiryec=; b=ZpGfCDXhYCsrVJqJotc2q/QjDGTju+T3UcB3oJheoirNMZY/oCH39gnGNIM08GSoVa aJ1kUEnHZivRt1EeeDFojW2CV6OkGfqtK0m1EruBjUxlxEX8r2Llid5KnMgModlZZ2Gb PvN+dQvxs+AwRJk2mE4MViT+UpGmLNEysU8qA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=b4sEnMqAizhwgOWfnT4EAKd2uo9ELAKuOLtB6gvfMoZRShvXE0EVij5RZPOZnLYKDX 6QppxsPfjyKRTzSpfF9WS6eRnOsGY/fOMa+lvqehQM12EzIT339SxcUNyEaHwpPj/AQn 9hmhxnV6wNMvCIZVFvwUzePSqZ58H/iGB2cNU= Received: by 10.210.66.13 with SMTP id o13mr136952eba.105.1228495791040; Fri, 05 Dec 2008 08:49:51 -0800 (PST) Received: by 10.210.126.11 with HTTP; Fri, 5 Dec 2008 08:49:50 -0800 (PST) Message-ID: <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> Date: Fri, 5 Dec 2008 11:49:50 -0500 From: "Ian Chakeres" To: "Philip Levis" , arsalan@eecs.berkeley.edu In-Reply-To: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> Cc: charliep@computer.org, roll@ietf.org Subject: Re: [Roll] Working Group Last Call: draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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've reviewed draft-ietf-roll-protocols-survery. I have a few comments and nits. In the Introduction, it would be great if LLN constraints and requirements that other networks do not poses were listed/summarized before reference to the routing-req docs. The existing text left me guessing about what exactly was different. I would suggest rephrasing the DYMO discussion related to hopcount in Section 3. Perhaps stating that "distance" is the metric in DYMO, and that hopcount is the minimum distance allowed. In Section 4.2, the motivation provided is the possibly large network size (250-millions) and deep network (20 hops). Network size and routing information size do not have a direct connection when hierarchical addressing is used. Perhaps this motivation could be removed and simply the last sentence kept. Given this change maybe the suitability metric should become routing table size, instead of table scalability. Based on the suitability table and description contained in the ROLL survey document, I have updated the DYMO (v16) draft . First, I added text to indicate that distance may be influenced at multiple points in the processing of RM. This changes should allow link and node metrics to influence distance before and after RM processing. Secondly, I have made forwarding of RERR optional (through strongly suggested). This should allow a smart implementation (e.g. using an "active" precursor list) to limit the propagation of RERR messages. Thank you for pointing out these minor issues in DYMO. If you have any other suggestions for the DYMO specification that you feel would make it better fit to suit ROLL requirements, please let me know. Thanks. Ian Chakeres On Fri, Nov 21, 2008 at 1:36 AM, JP Vasseur wrote: > Dear WG, > draft-ietf-roll-protocols-survey-02 is now fully stable, the last revision > has been published after the ROLL Interim meeting in October and all > comments received so far had been addressed. > This emails start a 2-week Working Group Last Call that will end on December > 5 at noon ET. > Please send your comments to the authors and on the mailing list. > 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 Fri Dec 5 09:14:16 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 032FB28C1A6; Fri, 5 Dec 2008 09:14:16 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D0B23A6C8F for ; Fri, 5 Dec 2008 09:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.506 X-Spam-Level: X-Spam-Status: No, score=-10.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CI2g-sOFz4vJ for ; Fri, 5 Dec 2008 09:14:14 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 036623A6B27 for ; Fri, 5 Dec 2008 09:14:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,721,1220227200"; d="scan'208";a="27829799" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 05 Dec 2008 17:14:08 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mB5HE8go001832; Fri, 5 Dec 2008 18:14:08 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mB5HE8sC007464; Fri, 5 Dec 2008 17:14:08 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Dec 2008 18:14:07 +0100 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Dec 2008 18:14:07 +0100 Message-Id: <935542DB-6BFD-4335-B668-3936B2431E9B@cisco.com> From: JP Vasseur To: "Dearlove, Christopher (UK)" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 5 Dec 2008 18:14:06 +0100 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 05 Dec 2008 17:14:07.0802 (UTC) FILETIME=[E1DF39A0:01C956FC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3784; t=1228497248; x=1229361248; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Working=20Group=20Last=20Call= 3A=20draft-ietf-roll-protocols-survey-02 |Sender:=20; bh=4ISYlMAw8N9nmBmud/1FIHHmqZ8vNBchq35n679syZs=; b=o+n80qYHb0WCzuoSD/L5+uXXbyeKsVnO2ihAF/KsO3a8h9I14EwLQIrN7A +0GDkUv0hIGLITv+Kz15IJBcE/XYyX/TgW+DyKWSkOjzWiJ5+i5HxqeaB/1A NldAlG/Gcr; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] Working Group Last Call: draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Thanks for your comments Christopher. We will also make sure to address the nits mentioned below. JP. On Dec 5, 2008, at 4:18 PM, Dearlove, Christopher (UK) wrote: > > I think this document is correct in its assessment > that no existing routing protocol meets the five > rigid specifications given. However on the way to > that conclusion > > - If the sole purpose is to answer the question as to > whether any existing protocol meets the very tough > standards given, then the purpose is met, the answer > is no. But that doesn't actually help you take the > next step. Are any of these protocols adaptable to > meet theses requirements, or do you have to start > from scratch? (And some of these protocols have more > options than may be obvious. Just because as configured > in existing specifications it fails, doesn't mean it > always will. And some things that may appear fundamental > may not be. For example I think it's quite easy to > modify NHDP to bound its neighbourhood information in > a dense network - and if it's not dense, it's bounded > anyway. How well that modification works is however > something that would need work to test.) > > - And why don't these protocols meet these specifications? > OK, maybe the designers could have done better (I don't > know). But maybe first there are other major issues that > have to be traded off (latency for example - you can really > cut down on signalling overheads if you allow unbounded > latency), and second, can those constraints actually all > be met in a reasonable way? (If not, there's a danger of > start from clean sheet, discover along the way you need to > compromise, and then that someone's already been down that > route.) > > - Along the way, not everything is undisputed. For example > in the traffic bounding considerations of OLSRv2 it > is clear that neither the timing backoff nor "fisheye" > variable flooding of OLSRv2 is taken into account. > I'm not suggesting that these are enough to achieve > the required O(N) bound (at least not without probably > unacceptable delays) but the simple O(N^2) before MPR > adjustment isn't necessarily quite that simple. (And how > much you can use those features depends on density and > variability, the latter of which is also a major issue.) > > I'm not suggesting another round of modifying the document, > just putting down that the document has a narrow purpose, > and shouldn't be stretched beyond it. It's fine that someone > might say that this document shows that DYMO (for example) > out of the box isn't what you want. (I don't personally know > that to be true however.) But that shouldn't be taken as saying > DYMO doesn't work, we must start afresh. I don't know if > you could start with DYMO (or the other six protocols) and > get to where you want to go. I'm just saying this document > doesn't answer that question, but assuming that it does is a > future danger to be avoided. > > As a minor nit however, in section 4.4, the use of > O(R log(L) + e) where e is a small constant is, while not > actually wrong, is confusing. O(R log(L) + e) is exactly > the same as O(R log(L)). It's only meaningful to include > e if using something other than big-O notation. > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri Dec 5 10:37:32 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12CBF3A6BA0; Fri, 5 Dec 2008 10:37:32 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBC8C28C1E2 for ; Fri, 5 Dec 2008 10:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivmaavVZfC23 for ; Fri, 5 Dec 2008 10:37:29 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id E85473A69D1 for ; Fri, 5 Dec 2008 10:37:29 -0800 (PST) Received: from dnab4221c2.stanford.edu ([171.66.33.194]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1L8fYL-0006MC-5Z; Fri, 05 Dec 2008 10:37:25 -0800 Message-Id: <2FBB9A6C-FF44-46A4-A95C-CC1300B4EF1F@cs.stanford.edu> From: Philip Levis To: "Dearlove, Christopher (UK)" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 5 Dec 2008 10:37:24 -0800 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> X-Mailer: Apple Mail (2.929.2) X-Scan-Signature: dfe9a19d2d5d3f4658608889c96f7beb Cc: roll@ietf.org Subject: Re: [Roll] Working Group Last Call: draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Dec 5, 2008, at 7:18 AM, Dearlove, Christopher (UK) wrote: > > I think this document is correct in its assessment > that no existing routing protocol meets the five > rigid specifications given. However on the way to > that conclusion > > - If the sole purpose is to answer the question as to > whether any existing protocol meets the very tough > standards given, then the purpose is met, the answer > is no. But that doesn't actually help you take the > next step. Are any of these protocols adaptable to > meet theses requirements, or do you have to start > from scratch? (And some of these protocols have more > options than may be obvious. Just because as configured > in existing specifications it fails, doesn't mean it > always will. And some things that may appear fundamental > may not be. For example I think it's quite easy to > modify NHDP to bound its neighbourhood information in > a dense network - and if it's not dense, it's bounded > anyway. How well that modification works is however > something that would need work to test.) > > - And why don't these protocols meet these specifications? > OK, maybe the designers could have done better (I don't > know). But maybe first there are other major issues that > have to be traded off (latency for example - you can really > cut down on signalling overheads if you allow unbounded > latency), and second, can those constraints actually all > be met in a reasonable way? (If not, there's a danger of > start from clean sheet, discover along the way you need to > compromise, and then that someone's already been down that > route.) This is a great discussion to have. I think you're touching on an important point, that many of them were designed with different priorities than we encounter in LLNs. For example, if you want to run high throughput TCP, jitter and high latencies are an issue, while in LLNs this might not be as important as the energy efficiency of a low- throughput flow. These subtle differences lead to design choices which cause issues (unimagined in the general mesh case) in LLNs. That being said, there's a lot to be learned, as protocols meet some of the criteria. > - Along the way, not everything is undisputed. For example > in the traffic bounding considerations of OLSRv2 it > is clear that neither the timing backoff nor "fisheye" > variable flooding of OLSRv2 is taken into account. > I'm not suggesting that these are enough to achieve > the required O(N) bound (at least not without probably > unacceptable delays) but the simple O(N^2) before MPR > adjustment isn't necessarily quite that simple. (And how > much you can use those features depends on density and > variability, the latter of which is also a major issue.) This is probably true. But I'm sure you can understand our trepidation in stating a strong bound based on some simple simulation studies from several years ago, when the actual mechanism is itself not clearly defined. > > > I'm not suggesting another round of modifying the document, > just putting down that the document has a narrow purpose, > and shouldn't be stretched beyond it. It's fine that someone > might say that this document shows that DYMO (for example) > out of the box isn't what you want. (I don't personally know > that to be true however.) But that shouldn't be taken as saying > DYMO doesn't work, we must start afresh. I don't know if > you could start with DYMO (or the other six protocols) and > get to where you want to go. I'm just saying this document > doesn't answer that question, but assuming that it does is a > future danger to be avoided. I agree completely. The document has a very narrow scope because that is the current charter of ROLL. Also, it's important to resolve this question clearly, without conflating it with the much larger discussion of what steps the WG should take next. > > > As a minor nit however, in section 4.4, the use of > O(R log(L) + e) where e is a small constant is, while not > actually wrong, is confusing. O(R log(L) + e) is exactly > the same as O(R log(L)). It's only meaningful to include > e if using something other than big-O notation. True enough. The concern here is that *any* constant factor is elided from big-O notation. Given that many LLN devices have finite energy, one can then simply say that the cost of a protocol is bounded by a constant and... get nowhere. Maybe the thing to do is point out that this epsilon is variable dependent on the deployment and its considerations? So while it is a small constant in the context of a specific network, it is not constant across networks. Many thanks for your comments, Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Sun Dec 7 18:37:54 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D10553A69B3; Sun, 7 Dec 2008 18:37:54 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF1473A69B3 for ; Sun, 7 Dec 2008 18:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3r2ix7eyR0C for ; Sun, 7 Dec 2008 18:37:53 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id BACA33A6843 for ; Sun, 7 Dec 2008 18:37:52 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so383646ywb.83 for ; Sun, 07 Dec 2008 18:37:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=wSydZc4YBGURBHpjuWRRjiRth1U7ZpFpX9nxxWojb38=; b=JR+WeXmQoxFy3EKiaybji1fiAlASHQBue4xEvY+yBdT378DD+vTyqH/FHbUTgn5yJ5 vtvMBvhP9oxco6ekKbTamG4Q6Y4ff4/zAVv8yAVEu+4bgX+0IPW874OW62sypSiyRlyp HiSxqO4mw1TCzMj5vkrTH6KZ7r/Msfvn2PBSY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=i6a3tKCUKFITY11dvxZ1sUMEDl9rv3rp6ViomdBJLLsWRm89k1af5REl2pTOPd/d72 nezz87VUZzwAjI5I3uB8Np7QqvXlBMweNEuXY+9YQcHV6C2/MWIHpIrFQ7rQ++kj04Sf Iygl0CMYFM09vk6qhw+YB034PfAHFFnvTqyZ4= Received: by 10.90.29.17 with SMTP id c17mr1013169agc.77.1228703866669; Sun, 07 Dec 2008 18:37:46 -0800 (PST) Received: by 10.90.116.12 with HTTP; Sun, 7 Dec 2008 18:37:46 -0800 (PST) Message-ID: Date: Sun, 7 Dec 2008 18:37:46 -0800 From: "Omprakash Gnawali" To: "Ian Chakeres" In-Reply-To: <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> X-Google-Sender-Auth: b7ebded75d049ca4 Cc: charliep@computer.org, roll@ietf.org, arsalan@eecs.berkeley.edu Subject: Re: [Roll] Working Group Last Call: draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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 Fri, Dec 5, 2008 at 8:49 AM, Ian Chakeres wrote: ... > > In Section 4.2, the motivation provided is the possibly large network > size (250-millions) and deep network (20 hops). Network size and > routing information size do not have a direct connection when > hierarchical addressing is used. Perhaps this motivation could be > removed and simply the last sentence kept. Given this change maybe the > suitability metric should become routing table size, instead of table > scalability. I would go a bit further and ask if scalability and routing table size should be two different metrics. The former says, if I want to deploy a network with 2 million nodes instead of 1 million nodes, how much more memory would I need while the later should provide the absolute bound on the memory requirement. I know these two metrics are somewhat related but considering we know the size of the largest network, it makes sense to talk about both. Do people care more about scalability or bounds? Does it make more sense to be more explicit about the bounds ? For example, a node should not have to keep track of more than 2000 entries. Does it make sense to talk about amount of RAM instead? Talking about scalability is making this discussion about this particular metric more abstract than it should be. - om_p _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Dec 8 08:00:39 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 803D73A6768; Mon, 8 Dec 2008 08:00:39 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ED733A657C for ; Mon, 8 Dec 2008 08:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrP6WLrx3W7q for ; Mon, 8 Dec 2008 08:00:37 -0800 (PST) Received: from mho-01-bos.mailhop.org (mho-01-bos.mailhop.org [63.208.196.178]) by core3.amsl.com (Postfix) with ESMTP id 5DD763A6768 for ; Mon, 8 Dec 2008 08:00:36 -0800 (PST) Received: from aste-genev-bois-153-1-11-44.w83-112.abo.wanadoo.fr ([83.112.73.44] helo=[192.168.147.109]) by mho-01-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1L9iWz-0008rG-SO; Mon, 08 Dec 2008 16:00:23 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 83.112.73.44 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19G51qwygzBlJNcdEF6loqW In-Reply-To: References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <710F3638-03FD-460F-8AB2-DC4100832F3B@thomasclausen.org> From: Thomas Heide Clausen Date: Mon, 8 Dec 2008 17:00:32 +0100 To: roll@ietf.org X-Mailer: Apple Mail (2.753.1) Cc: charliep@computer.org Subject: [Roll] Review and concerns (was: Re: Working Group Last Call: draft-ietf-roll-protocols-survey-02) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Dear All, I've been reviewing the latest incarnation of this I-D, and I have a couple of general concerns with this I-D and, more specifically, with the approach it seems to be suggesting for the working group. o The document seems to set the bar of acceptance at "the holy grail of a routing protocol", i.e. defines "acceptable" to be "zero-cost [more on that in a following bullet], instant-convergence" -- thereby causing all routing protocols to almost by definition be judged "insufficient" -- which is reflected in the evaluation of the existing set of routing protocols. o As I assume ROLL is designing "for the real world", compromises and trade-offs are paramount in protocol design. By elevating a set of criteria (sec. 3 and 4 -- "table scalability", "loss response", "control cost", "link cost" and "node cost") above the rest, while pointing out that (i) an approach not meeting the bar on all of those is unacceptable and (ii) "applications introduce additional, more stringent, requirements", this I-D effectively limits the trade-offs possible for when designing protocols for these applications. o From the previous point, it is not convincing that eliminating these trade-offs is justified. While I believe that indeed *any* application would welcome "the holy grail of a routing protocol", recognizing that such may not exist, it may for some application be right to trade off, say, "higher control cost" against "low memory footprint". Something which is explicitly excluded (2nd paragraph section 4). o Going by where the bar for acceptance is set in this document, I have thought and come up with indeed two solutions that have "zero-cost-instant- convergence" properties, and they both satisfy the IP delivery semantics. One is "drop all traffic, don't even try" and the other is "flood all traffic, don't maintain a routing table". Of course, those two proposals are in jest, as I am sure that the trade-off I am making -- sacrificing delivery ratio for the former, satisfying network traffic and energy (but not as a consequence of the routing protocol relaying control traffic) for the latter are not acceptable in an absolute sense -- but the routing protocol will itself require have zero-cost, zero-memory, instant-convergence. o From the previous and first bullet, "control cost" is an insufficient measure. "Flooding all data" has zero "control cost" but a large overall cost (many retransmissions, lots of battery drain, lots of media use). A routing protocol incurring some "control cost" to gain lower "data transmission cost" likely is a better tradeoff, especially if data traffic is a common occurrence in the network. IOW, looking at "control cost" as a separate metric is not terribly useful unless the consequences in terms of the "data cost" and "data delivery ratio" are considered as well. Chris Dearlove summarize well in saying that the document does well in setting out a rigid set of "pass" criteria and observing that none of the six protocols analyzed satisfies those off-the-shel -- but that this should not be stretched to assume that an entirely new design is required. I also join Chris in his comment that, for example, OLSRv2 offers "timing backoff" and "fisheye variable flooding" without variations to the routing protocol [the specificities of how to set timers or vary flooding is a policy matter that is dependent on deployment, but can be done entirely conformant with its specification] -- and that this is not considered. I'll go further than Chris and suggest that not considering the use of such options, which are present in the protocols but where a policy specification dependent on deployment is required, casts doubt on the assessment of the protocols as presented - not just OLSRv2, but such options exist for other protocols as well. I'll send another email with "nits" to the document, however I feel that the issues above need to be discussed and resolved. Cheers, Thomas _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Dec 8 08:25:48 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 587F93A68E3; Mon, 8 Dec 2008 08:25:48 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F8CD3A68E3 for ; Mon, 8 Dec 2008 08:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 REcZhisIzfmP for ; Mon, 8 Dec 2008 08:25:45 -0800 (PST) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id 62ED53A6888 for ; Mon, 8 Dec 2008 08:25:45 -0800 (PST) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mB8GPawK025610 for ; Mon, 8 Dec 2008 16:25:37 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mB8GPahi030754 for ; Mon, 8 Dec 2008 16:25:36 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 08 Dec 2008 16:25:36 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 8 Dec 2008 16:25:35 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 8 Dec 2008 16:25:34 -0000 Message-ID: In-Reply-To: <2FBB9A6C-FF44-46A4-A95C-CC1300B4EF1F@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Working Group Last Call: draft-ietf-roll-protocols-survey-02 Thread-Index: AclXCIadNG8ak4E2Sd2Osly0AQ11+ACRfMCQ References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <2FBB9A6C-FF44-46A4-A95C-CC1300B4EF1F@cs.stanford.edu> From: "Dearlove, Christopher (UK)" To: "Philip Levis" X-OriginalArrivalTime: 08 Dec 2008 16:25:35.0893 (UTC) FILETIME=[997A6C50:01C95951] Cc: roll@ietf.org Subject: Re: [Roll] Working Group Last Call: draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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 > Christopher Dearlove >> - And why don't these protocols meet these specifications? >> OK, maybe the designers could have done better (I don't >> know). But maybe first there are other major issues that >> have to be traded off (latency for example - you can really >> cut down on signalling overheads if you allow unbounded >> latency), and second, can those constraints actually all >> be met in a reasonable way? (If not, there's a danger of >> start from clean sheet, discover along the way you need to >> compromise, and then that someone's already been down that >> route.) > This is a great discussion to have. I think you're touching on an > important point, that many of them were designed with different > priorities than we encounter in LLNs. For example, if you want to run > high throughput TCP, jitter and high latencies are an issue, while in > LLNs this might not be as important as the energy efficiency of a low- > throughput flow. Yes, but. The "but" is that although latency may not be as much as an issue in some LLNs as it may be in some other ad hoc networks, first it may be (I can certainly conceive of an LLN with a low latency requirement), but second even when it isn't, there are likely to be some latency constraints, and that's an important part of the mix. By ignoring it I may meet the three complexity constraints, but imposing it I may not - even if it is fairly lax. (I only use latency as an example.) > These subtle differences lead to design choices which > cause issues (unimagined in the general mesh case) in LLNs. I don't believe any requirement in ROLL is unimagined in the general MANET case - in the decade or so the MANET WG has been around (quite a bit of it before my time) many things have been imagined. What they may have been is considered as part of a tradeoff and possibly given a lower priority. Note that often the MANET WG has ended up with view more like "X should be minimised, as far as possible, subject to other constraints" rather than "X should be O(M), for M ...". This doesn't mean that the MANET WG hasn't thought "wouldn't it be great if such and such didn't increase as the network got larger" but rather "unfortunately such and such has to increase with the size of the network, given our other constraints, but let's try to keep it manageable". I use the MANET WG as an example. Not all the protocols considered are MANET protocols of course. But I wouldn't take a bet that exactly the same issues hadn't been considered by the designers of OSPF, even though their tradeoffs are yet again different. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Dec 8 08:57:03 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71CC13A686C; Mon, 8 Dec 2008 08:57:03 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18AD33A686C for ; Mon, 8 Dec 2008 08:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfx5V6vYU8bw for ; Mon, 8 Dec 2008 08:57:00 -0800 (PST) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id 7E8A63A67F1 for ; Mon, 8 Dec 2008 08:56:59 -0800 (PST) Received: from aste-genev-bois-153-1-11-44.w83-112.abo.wanadoo.fr ([83.112.73.44] helo=[192.168.147.109]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1L9jPe-000C0G-0A; Mon, 08 Dec 2008 16:56:51 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 83.112.73.44 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+7kS+y1RoFV3wz+i41bQs6 In-Reply-To: References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <1964D294-5322-404D-9E40-26450EED6443@thomasclausen.org> From: Thomas Heide Clausen Date: Mon, 8 Dec 2008 17:57:02 +0100 To: roll@ietf.org X-Mailer: Apple Mail (2.753.1) Cc: charliep@computer.org Subject: [Roll] Nits (was: Re: Working Group Last Call: draft-ietf-roll-protocols-survey-02) X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============1336569712==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1336569712== Content-Type: multipart/alternative; boundary=Apple-Mail-2--807364661 --Apple-Mail-2--807364661 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear All, I've been reviewing the latest incarnation of this I-D, and as promised in my previous email, I have a bunch of nits in addition to my more general concerns -- this is in addition to those general concerns, the items that made me stumble in my reviewing. Terminology: o Would it be possible to group "protocol acronyms for candidate routing protocols evaluated in this document" o LLN is specified. L2N is used in section 4.4. Is that the same? Introduction: o I am vary when crediting "Moores Law" as having caused something As Moore's Law has reduced computer prices and form factors, Would it not be as correct to omit the reference hereto and just observe that prices and form factors have reduced? o inter-networking -- why the hyphen? o Paragraph 2: as we are in "introduction-space" and as consumer devices has been presented as an example device, I wonder...my (dated) consumer cellphone runs a stock MANET routing protocol for days over WiFi without recharge -- and as a consumer, this suffices for me. Clearly, the goal is also stuff that can't be recharged once every 2-3 days (embedded sensors, say) -- could a throwaway sentence be added to strengthen the low- power requirement somewhere? Specifically, the leap from consumer devices in paragraph 1 to this is brutat: Cost points and energy limitations cause these devices to have very limited resources: a few kB of RAM and a few MHz of CPU is typical. Which are "these devices" -- not the "laptops, palmtops and cellphones" cited in paragraph 1 ;) o I would cut paragraph 2 into two paragraphs, just before In practice, wireless.... o Paragraph 3 starts: These low power and lossy networks introduce constraints and requirements that other networks typically do not possess ([I-D.ietf-roll-home-routing-reqs] and [I-D.ietf-roll-indus-routing-reqs]). As they were not designed with these requirements in mind, existing protocols may or may not work well in LLNs. (i) could we enumerate these constraints, or at least a subset hereof, to justify that "other networks" do not have those? (ii) which are those "other networks", btw? ASes in the Internet? Bluetooth network surely does have some of the same constraints. (iii) the last "As they were not designed" leaves me wondering what "they" refer to, could we not write "As such existing networks were not designed" -- Or something similar? o Paragraph 3 ends: this document simply seeks to answer the question: do LLNs require a new protocol specification document at all? This document does, in my opinion, not actually answer this question. This document rather evaluates existing protocols and identifies areas where additional study is required to determine *if* these protocols can be parametrized and deployed OR if they can be adapted OR -- failing the two previous -- new protocol specifications are required. Also see Chris Dearlove's email. Methodology: o Paragraph 2: As per my previous email to the list, I think that this paragraph is incorrect and too limiting. It should rather read that this document only evaluates with respect to the very strict set of metrics listed, but that applications or deployments may make other trade-offs, including trading off the metrics in this document in favor of other benefits. IOW, the "necessary, but not sufficient" part, I think, is inappropriate and can limit the wg's ability to make appropriate trade-offs later. o Paragraph 3: rouge space before the comma after olsrv2-citation o Paragraph 4: "considering the best implementation possible" that's a very bold statement, and likely not correct. For example, OLSRv2 offers the ability to do timer-backoff and fisheye variable flooding -- which affects the average-case performance and where the protocol can be tuned such that the average-case is the actual deployment -- yet, this is not considered in the evaluation. The same applies for the other protocols. Suitability: o Paragraph 1: "generally applicable" is a very vague statement, what does that mean? The ID said earlier that the criteria are "necessary but not sufficient", so this I-D can not state based on the criteria any "general applicability", can it? o Paragraph 2: I feel that two criteria are missing: o path lengths (length as in "sum of costs") o delivery ratio / success rate of data traffic Without those, the other metrics have little meaning. o Section 4.2: o "of devices noted of the urban" -- should that not be "of devices as noted in the urban" ??? o 2nd paragraph, it emerges that: low-power and lossy networks behave principally as data collection networks and principally communicate through routers to data collection points in the larger Internet I'm not disputing that, but if there are a set of such general characteristics, could it not be an idea listing those in a section up front ("applicability statement" or the like) with due references to the individual requirements drafts? IOW, reading the I-D leaves me starting out thinking "Generally, wireless networks", and getting "drop by drop" narrowed down to specific traffic and other characteristics. I would much prefer seeing such "up front" to understand if the considerations in this I-D applies or not to a given problem that the reader might have? o Section 4.3: o It *seems* to me that among the requirements, the "energy constraint" issue is in direct conflict with this statement: The protocol should also "always be in the process of optimizing the system in response to changing link statistics." So conserving energy by dialing down the CPU speed is not an option considered? o Section 4.4 and elsewhere: o O(R log(n) +e), assuming R and e are constants, are not std. O (...) notation (edit, I see now that I get on-line that Dearlove made the same comment) Routing Protocol Taxonomy o 2nd paragraph: o "and routers synchronize their LSDBs" I am not sure if it is intended, but I tend to think "OSPF database synchronization with DRs" when reading the above -- and note that e.g. OLSR does not employ such an operation, nor does OSPF when deployed over the MANET interface type as described in some of the current OSPF I-Ds defining the protocol behavior over these interfaces. IOW, it's not clear exactly what is meant here. o 6th paragraph: o a requirement of "4kb of RAM" appears out of the blue. Goes with the suggestion to have an "applicability statement" where such constraints are explicitly enumerated. I agree that running OSPF in 4KB of RAM is a challenge...as is IP ;) o There's a loose "Protocols Today" on top of page 11. Should that be a subsection? o 3rd paragraph on page 11: Because wireless links can suffer from significant temporal variation, link state protocols can have higher traffic loads as topology changes must propagate globally Not necessarily true. LS protocols can run in a mode wherein the control traffic overhead is independent also of the topology changes. It's a trade-off, of course, against "something else". Also: "One major protocol, DSR, does not easily fit" Why "major"? OLSR o Should the heading not be "OLSR & OLSRv2" as the text applies to both? o Neither OLSR nor OLSRv2 deploys "topology discovery packets", but propagates LSAs called TC messages. In general "discovery packets" are associated with the request-reply cycles of reactive protocols such as DYMO or AODV o OLSRv2 incorporates metrics, in addition to hop-counts. Security Considerations o I am a little uncomfortable with this being left blank, as I believe that security considerations are important for also ROLL protocols, and as I believe that the different protocol options offer different challenges and benefits wrt. security. Appendix A: o OSPF -- does it even (as you describe it) run over the kinds of networks that are studied, without modifications? I.e. DR selection and such, would it work? I ask, as in the MANET-OSPF work in OSPF, a lot of effort has been made on these topics, and I wonder if you've been following that? o OLSRv2 - 1st line, "flooding this information" -- which information? - I believe that ignoring the MPR, timer-backoff and FSR options, as present in the OLSRv2 specification, is not appropriate, and suggest that these be evaluated also in this section. Ignoring those is, at best, incorrect. - changes in the link set does not REQUIRE immediately re-flooding of LS information. One MAY do so, but the protocol specifies considerations and constraints hereof. Cheers, Thomas Cheers, Thomas --Apple-Mail-2--807364661 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Dear All,

I've been reviewing the latest = incarnation of this I-D, and as promised in my previous email, I have a = bunch of nits in addition to my more general concerns -- this is in = addition to those general concerns, the items that made me stumble in my = reviewing.

Terminology:
o Would it be possible to group = "protocol acronyms for candidate=A0
= routing protocols evaluated in this document"=A0

o LLN is = specified. L2N is used in section 4.4. Is that the same?

Introduction:

o I am vary = when crediting "Moores Law" as having caused something

= As=A0Moore's Law has reduced computer prices and form = factors,

Would it not be as = correct to omit the reference hereto and just observe=A0
that prices and form = factors have reduced?
o inter-networking -- why the = hyphen?

o Paragraph 2: as we are in = "introduction-space" and as consumer=A0
= devices has been presented as an example device, I wonder...my = (dated)
consumer=A0cellphone runs = a stock MANET routing protocol for days over WiFi
without recharge -- and = as a consumer, this suffices for me. Clearly, the goal
is also stuff that can't = be recharged once every 2-3 days (embedded sensors,
say) -- could a throwaway = sentence be added to strengthen the low-power
requirement = somewhere?

Specifically, the leap = from consumer devices in paragraph 1 to this is brutat:

= Cost points and energy limitations cause = these=A0devices=A0
= to have very limited resources: a few kB of RAM = and=A0
a few = MHz=A0of CPU is typical.
Which are "these devices" = -- not the "laptops, palmtops and cellphones" cited in
paragraph 1 = ;)

o I would cut paragraph 2 into two = paragraphs, just before
In practice, wireless....

o Paragraph 3 starts:

= These low power and lossy networks introduce = constraints and
=A0=A0 = requirements that other networks typically do not = possess
=A0=A0 = ([I-D.ietf-roll-home-routing-reqs] and
=A0=A0 = [I-D.ietf-roll-indus-routing-reqs]).=A0 As they were not designed = with
=A0=A0 these requirements in mind, = existing protocols may or may not work
=A0=A0 well in LLNs.

= (i) = could we=A0enumerate=A0these constraints, or at least a subset = hereof, to justify that
= "other networks" do not have those?

= (ii) = which are those "other networks", btw? ASes in the Internet? = Bluetooth network surely does
= have some of the same constraints.

= (iii) = the last "As they were not designed" leaves me wondering what "they" refer = to,
could we = not write "As such existing networks were not = designed"=A0
= -- Or something similar?

o Paragraph 3 ends:

= this document simply=A0seeks to answer the question: = do LLNs=A0
require a = new protocol=A0specification document at all?

= This document does, in my opinion, not actually answer this = question. This document rather=A0
= evaluates existing protocols and identifies areas where = additional study is required to
= determine *if* these protocols can be parametrized and deployed = OR if they can be adapted
= OR -- failing the two previous -- new protocol specifications are = required.

Also see Chris = Dearlove's email.

Methodology:
o Paragraph 2:

= As per my previous email to the list, I think that this paragraph = is incorrect and too limiting.
= It should rather read that this document only evaluates with = respect to the very strict set of
= metrics listed, but that applications or deployments may make = other trade-offs, including=A0
= trading off the metrics in this document in favor of other = benefits.

IOW, the = "necessary, but not sufficient" part, I think, is inappropriate and can = limit the wg's
= ability to make appropriate trade-offs later.

o Paragraph = 3:

rouge space = before the comma after olsrv2-citation
o Paragraph 4:

= "considering the best implementation=A0possible"

= that's a very bold statement, and likely not correct. For = example, OLSRv2 offers the ability
= to do timer-backoff and fisheye variable flooding -- which = affects the average-case
= performance and where the protocol can be tuned such that the = average-case is
= the actual deployment -- yet, this is not considered in the = evaluation. The same applies
= for the other protocols.
Suitability:

o Paragraph = 1:

"generally = applicable" is a very vague statement, what does that mean? The ID = said
earlier that the = criteria are "necessary but not sufficient", so this I-D can not = state
based on the = criteria any "general applicability", can it?

o Paragraph = 2:

I feel that two = criteria are missing:
o path = lengths (length as in "sum of costs")
= o = delivery ratio / success rate of data traffic

= Without those, the other metrics have little = meaning.

o Section 4.2:

= o = "of devices noted of the urban" -- should that not be
"of devices as noted in the urban" = ???


= o = 2nd paragraph, it emerges that:
low-power and lossy networks behave principally as data = collection
=A0=A0=A0networks and principally = communicate through routers to data
= =A0=A0=A0collection points in the larger = Internet

I'm not = disputing that, but if there are a set of such general characteristics, = could
it not be = an idea listing those in a section up front ("applicability statement" = or the like)
with due = references to the individual requirements drafts?

= IOW, reading the I-D leaves me starting out thinking "Generally, = wireless networks", and
= getting "drop by drop" narrowed down to specific traffic and = other characteristics. I would
= much prefer seeing such "up front" to understand if the = considerations in this I-D applies
= or not to a given problem that the reader might = have?


o Section = 4.3:

o It = *seems* to me that among the requirements, the "energy constraint" issue = is in direct
conflict = with this statement:
= The protocol should also "always be
= =A0=A0=A0 = in the process of optimizing the system in response to changing = link
=A0=A0 = statistics." =

So = conserving energy by dialing down the CPU speed is not an option = considered?

o Section 4.4 and = elsewhere:

o O(R = log(n) +e), assuming R and e are constants, are not std. O(...) = notation
(edit, I = see now that I get on-line that Dearlove made the same = comment)

Routing Protocol Taxonomy

o 2nd = paragraph:

o "and = routers synchronize their LSDBs"
=A0I am = not sure if it is intended, but I tend to think "OSPF database = synchronization with =A0DRs"
= when reading the above -- and note that e.g. OLSR does not employ = such an operation,
= nor does OSPF when deployed over the MANET interface type as = described in some of the
= current OSPF I-Ds defining the protocol behavior over these = interfaces.

IOW, it's = not clear exactly what is meant here.
o 6th paragraph:

= o = a requirement of "4kb of RAM" appears out of the blue. Goes with = the suggestion to
= have an "applicability statement" where such constraints are = explicitly enumerated.=A0
= I agree that running OSPF in 4KB of RAM is a challenge...as is IP = ;)

o There's a loose "Protocols Today" = on top of page 11. Should that be a subsection?

o 3rd = paragraph on page 11:
Because wireless
=A0=A0 = links can suffer from significant temporal variation, link = state
=A0=A0 protocols can have higher = traffic loads as topology changes must
=A0=A0 propagate = globally =
Not=A0necessarily=A0true. = LS protocols can run in a mode wherein the control traffic overhead is = independent
also of the topology = changes. It's a trade-off, of course, against "something = else".

Also:=A0
"One major protocol, DSR, does not easily fit"

= Why "major"?
OLSR

o Should = the heading not be "OLSR & OLSRv2" as the text applies to = both?

o Neither=A0OLSR nor OLSRv2 deploys = "topology discovery packets", but propagates
LSAs called TC messages. = In general "discovery packets" are associated with the
request-reply cycles of = reactive protocols such as DYMO or AODV
o OLSRv2 incorporates metrics, in = addition to hop-counts.
Security = Considerations

o I am a little uncomfortable with = this being left blank, as I believe that security = considerations
= are important for also ROLL protocols, and as I believe that the = different protocol options
= offer different challenges and benefits wrt. = security.

Appendix A:
o OSPF -- does it even (as you = describe it) run over the kinds of networks that are studied, = without
modifications? I.e. DR = selection and such, would it work? I ask, as in the MANET-OSPF work = in
OSPF, a lot of effort has = been made on these topics, and I wonder if you've been following = that?

o OLSRv2

- 1st line, = "flooding this information" -- which information?

= - = I believe that ignoring the MPR, timer-backoff and FSR options, = as present in
the = OLSRv2 specification, is not appropriate, and suggest that these be = evaluated
also in = this section. Ignoring those is, at best, incorrect.

= - = changes in the link set does not REQUIRE immediately re-flooding = of LS information.
= One MAY do so, but the protocol specifies considerations and = constraints hereof.

Cheers,
Thomas


Thomas
= --Apple-Mail-2--807364661-- --===============1336569712== 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 --===============1336569712==-- From roll-bounces@ietf.org Mon Dec 8 09:30:54 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EAC23A6951; Mon, 8 Dec 2008 09:30:54 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 437F23A6825 for ; Mon, 8 Dec 2008 09:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5cCSB2MkaFT for ; Mon, 8 Dec 2008 09:30:52 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 5942D3A67F1 for ; Mon, 8 Dec 2008 09:30:52 -0800 (PST) Received: from [74.85.100.72] (helo=host221-58.wifi.conference.usenix.org) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1L9jwU-0007LL-Vw; Mon, 08 Dec 2008 09:30:47 -0800 Message-Id: <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> From: Philip Levis To: Ian Chakeres In-Reply-To: <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 8 Dec 2008 09:02:27 -0800 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) X-Scan-Signature: b0d2d5ababd8fe43140185de29a9e1cb Cc: charliep@computer.org, roll@ietf.org, arsalan@eecs.berkeley.edu Subject: Re: [Roll] Working Group Last Call: draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Dec 5, 2008, at 8:49 AM, Ian Chakeres wrote: > I've reviewed draft-ietf-roll-protocols-survery. I have a few > comments and nits. > > In the Introduction, it would be great if LLN constraints and > requirements that other networks do not poses were listed/summarized > before reference to the routing-req docs. The existing text left me > guessing about what exactly was different. > > I would suggest rephrasing the DYMO discussion related to hopcount in > Section 3. Perhaps stating that "distance" is the metric in DYMO, and > that hopcount is the minimum distance allowed. > > In Section 4.2, the motivation provided is the possibly large network > size (250-millions) and deep network (20 hops). Network size and > routing information size do not have a direct connection when > hierarchical addressing is used. Perhaps this motivation could be > removed and simply the last sentence kept. Given this change maybe the > suitability metric should become routing table size, instead of table > scalability. > > Based on the suitability table and description contained in the ROLL > survey document, I have updated the DYMO (v16) draft . First, I added > text to indicate that distance may be influenced at multiple points in > the processing of RM. This changes should allow link and node metrics > to influence distance before and after RM processing. Secondly, I have > made forwarding of RERR optional (through strongly suggested). This > should allow a smart implementation (e.g. using an "active" precursor > list) to limit the propagation of RERR messages. Thank you for > pointing out these minor issues in DYMO. > > If you have any other suggestions for the DYMO specification that you > feel would make it better fit to suit ROLL requirements, please let me > know. Ian, I'm glad our reading of the draft was helpful. We'll be sure to update the text to reflect your edits and points. We've gone back and forth a lot on DYMO's relaxation of link cost computation, so it's great to hear DYMO's author's take. :) Your point about hierarchical addressing is interesting, and I think it relates to comments others have made on fisheye routing and other state suppression approaches. Help me out if I'm mistaken here, but I don't recall any work on address allocation/distribution in wireless networks to enable good route aggregation. This is particularly difficult in the IPv6 case because of how addresses are specified. So I'm wary of assuming hierarchical addressing, when in some cases it might not be possible. It's not quite like the wired Internet where there is some aggregation due to the administrative domain nature of how addresses are allocated. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Dec 8 09:58:36 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECB0D3A6951; Mon, 8 Dec 2008 09:58:36 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5437D28C120 for ; Mon, 8 Dec 2008 09:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.455 X-Spam-Level: X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 hIQtVG4cEoIG for ; Mon, 8 Dec 2008 09:58:35 -0800 (PST) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id 4744F3A6951 for ; Mon, 8 Dec 2008 09:58:35 -0800 (PST) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mB8HwQMs021457 for ; Mon, 8 Dec 2008 17:58:27 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mB8HwQcv005208 for ; Mon, 8 Dec 2008 17:58:26 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 08 Dec 2008 17:58:26 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 8 Dec 2008 17:58:26 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 8 Dec 2008 17:58:24 -0000 Message-ID: In-Reply-To: <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Working Group Last Call:draft-ietf-roll-protocols-survey-02 Thread-Index: AclZWrgyZNT2DiJ9S6ip4fl1DWknaAAAOUFg References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com><374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> From: "Dearlove, Christopher (UK)" To: "Philip Levis" , "Ian Chakeres" X-OriginalArrivalTime: 08 Dec 2008 17:58:26.0318 (UTC) FILETIME=[91B5D2E0:01C9595E] Cc: charliep@computer.org, roll@ietf.org, arsalan@eecs.berkeley.edu Subject: Re: [Roll] Working Group Last Call:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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 > Your point about hierarchical addressing is interesting, and I think > it relates to comments others have made on fisheye routing and other > state suppression approaches. Not quite. Hierarchical allocation is indeed a state suppression approach. However fisheye is a control message suppression approach. > Help me out if I'm mistaken here, but I > don't recall any work on address allocation/distribution in wireless > networks to enable good route aggregation. There's work in the literature, but the relevant IETF WG (autoconf) hasn't got to solutions yet. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Dec 8 10:50:40 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C56C728C13B; Mon, 8 Dec 2008 10:50:40 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E975B28C13B for ; Mon, 8 Dec 2008 10:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3jw3Wbb8VK5 for ; Mon, 8 Dec 2008 10:50:34 -0800 (PST) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id 7D99128C137 for ; Mon, 8 Dec 2008 10:50:34 -0800 (PST) Received: from aste-genev-bois-153-1-11-44.w83-112.abo.wanadoo.fr ([83.112.73.44] helo=[192.168.147.109]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1L9lBX-000JHK-QK; Mon, 08 Dec 2008 18:50:24 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 83.112.73.44 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/7IaD7tKz0DSe0aI62Yv6e In-Reply-To: References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Thomas Heide Clausen Date: Mon, 8 Dec 2008 19:50:34 +0100 To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.753.1) Cc: charliep@computer.org, roll@ietf.org, arsalan@eecs.berkeley.edu Subject: Re: [Roll] Working Group Last Call:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Dec 8, 2008, at 18:58 PM, Dearlove, Christopher (UK) wrote: > >> Your point about hierarchical addressing is interesting, and I think >> it relates to comments others have made on fisheye routing and other >> state suppression approaches. > > Not quite. Hierarchical allocation is indeed a state suppression > approach. However fisheye is a control message suppression approach. > And, it should be added that such are, of course complementing each other. Thomas _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Dec 9 01:02:34 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A45343A6887; Tue, 9 Dec 2008 01:02:34 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1331D3A6887 for ; Tue, 9 Dec 2008 01:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zu2-huyiGWoJ for ; Tue, 9 Dec 2008 01:02:32 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by core3.amsl.com (Postfix) with ESMTP id B246F3A63D3 for ; Tue, 9 Dec 2008 01:02:31 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id b39so862999ugd.15 for ; Tue, 09 Dec 2008 01:02:23 -0800 (PST) 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:cc:in-reply-to:mime-version:content-type:references; bh=vkq/RdeYdx6znrssozjqZsf3QuCpscx8jwRh27tLBQ8=; b=vp1DBuR6cqBXQ2aKTKPn0PdITEAR+tvty+aAGkreDt+b37nkaxcPtKUc5R8RHccn/Z /FwdVFtLXkVhYEepKAihDOWJWnqRlWV7SEvZhl3TZDQzUpulX40ksIWM5rXszC2wG/ma ONXPwsaUnABQOfpaCmsTiMfK+IxRr73sirDKE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=TzNwGH6wbl5ixb+DVF4GVt8w08ouAsm/bedhI72F6cjOM/ES19RL7OpWg6DAyLJ4eO Cj82cAwDblxZN4sOJ9bcFnzxO46PxDGuqkfMMPnUd0KKAWgpiWbX4bC33THPd5+iLcpa sLvcIpXxLO8uOsSjlOMzOUVrNsn7UhlOJ8veg= Received: by 10.103.40.5 with SMTP id s5mr1621289muj.4.1228813343039; Tue, 09 Dec 2008 01:02:23 -0800 (PST) Received: by 10.103.248.12 with HTTP; Tue, 9 Dec 2008 01:02:22 -0800 (PST) Message-ID: Date: Tue, 9 Dec 2008 10:02:22 +0100 From: "Emmanuel Baccelli" To: roll@ietf.org In-Reply-To: MIME-Version: 1.0 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> Cc: charliep@computer.org, Thomas Heide Clausen , arsalan@eecs.berkeley.edu Subject: Re: [Roll] Working Group Last Call:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============1067401645==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1067401645== Content-Type: multipart/alternative; boundary="----=_Part_62932_10075206.1228813343052" ------=_Part_62932_10075206.1228813343052 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, I think this draft is far from being ready to become an RFC, and such for several reasons, some of which are, unfortunately, structural. 1 - The draft is evaluating moving targets such as OLSRv2, Dymo, NHDP, which are potential solutions that are not finalized yet. These protocols could meet more requirements in the end (maybe all of them?). For this reason, the "pass/fail" table of section 5 cannot honestly list anything else but a series of "question marks" (or "pass"), for now, for these protocols. This makes this table rather useless, and thus this whole draft rather useless, presently. 2 - The ROLL charter mentions that " Existing IGPs, MANET, NEMO, DTN routing protocols will be part of evaluation." I did not see anything mentioned about DTN protocols, or Nemo in the draft, not even a justification why they are not mentioned. 3 - The draft is not constructive in its current shape. It is on the other hand extremely controversial with its judgement, and does not reflect a consensus within the community, not even a rough one. Emmanuel On Mon, Dec 8, 2008 at 7:50 PM, Thomas Heide Clausen wrote: > > On Dec 8, 2008, at 18:58 PM, Dearlove, Christopher (UK) wrote: > > >> Your point about hierarchical addressing is interesting, and I think >>> it relates to comments others have made on fisheye routing and other >>> state suppression approaches. >>> >> >> Not quite. Hierarchical allocation is indeed a state suppression >> approach. However fisheye is a control message suppression approach. >> >> > And, it should be added that such are, of course complementing each other. > > Thomas > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > ------=_Part_62932_10075206.1228813343052 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi all,

I think this draft is far from being ready to become an RFC, and such for several reasons, some of which are, unfortunately, structural.

1 - The draft is evaluating moving targets such as OLSRv2, Dymo, NHDP, which are potential solutions that are not finalized yet. These protocols could meet more requirements in the end (maybe all of them?). For this reason, the "pass/fail" table of section 5 cannot honestly list anything else but a series of "question marks" (or "pass"), for now, for these protocols. This makes this table rather useless, and thus this whole draft rather useless, presently.

2 - The ROLL charter mentions that " Existing IGPs, MANET, NEMO, DTN routing protocols will be part of evaluation." I did not see anything mentioned about DTN protocols, or Nemo in the draft, not even a justification why they are not mentioned.

3 - The draft is not constructive in its current shape. It is on the other hand extremely controversial with its judgement, and does not reflect a consensus within the community, not even a rough one.

Emmanuel


On Mon, Dec 8, 2008 at 7:50 PM, Thomas Heide Clausen <ietf@thomasclausen.org> wrote:

On Dec 8, 2008, at 18:58 PM, Dearlove, Christopher (UK) wrote:


Your point about hierarchical addressing is interesting, and I think
it relates to comments others have made on fisheye routing and other
state suppression approaches.

Not quite. Hierarchical allocation is indeed a state suppression
approach. However fisheye is a control message suppression approach.


And, it should be added that such are, of course complementing each other.

Thomas


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

------=_Part_62932_10075206.1228813343052-- --===============1067401645== 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 --===============1067401645==-- From roll-bounces@ietf.org Tue Dec 9 02:48:53 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 629D73A6A7C; Tue, 9 Dec 2008 02:48:53 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AE913A6A7C for ; Tue, 9 Dec 2008 02:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.517 X-Spam-Level: X-Spam-Status: No, score=-10.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73-CxP8k8lrq for ; Tue, 9 Dec 2008 02:48:51 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id BFA203A679C for ; Tue, 9 Dec 2008 02:48:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,740,1220227200"; d="scan'208,217";a="28077739" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Dec 2008 10:48:34 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mB9AmW3i024993; Tue, 9 Dec 2008 11:48:32 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mB9AmWvV014720; Tue, 9 Dec 2008 10:48:32 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Dec 2008 11:48:32 +0100 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Dec 2008 11:48:32 +0100 Message-Id: From: JP Vasseur To: Emmanuel Baccelli In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 9 Dec 2008 11:48:31 +0100 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 09 Dec 2008 10:48:32.0149 (UTC) FILETIME=[AD99BC50:01C959EB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8838; t=1228819712; x=1229683712; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Working=20Group=20Last=20Call= 3Adraft-ietf-roll-protocols-survey-02 |Sender:=20; bh=faA9gNND+ekSse8cqKjunwBZ679E5k+c9icPRYfcX8I=; b=W3usWKI5egenNcHjEW9SzsysPcozG5fM7GRGLZZF3pPEvt3SpBzI7DXSiz 7V24JRZ5mb+Df+8aYoZzBrncwzr5jusERvp4Dor85LPDZlcNnjV+Bf2lp1Bu T2qxkhkRtL; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: charliep@computer.org, roll@ietf.org, Thomas Heide Clausen , arsalan@eecs.berkeley.edu Subject: Re: [Roll] Working Group Last Call:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============0496535737==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0496535737== Content-Type: multipart/alternative; boundary=Apple-Mail-32--743075380 --Apple-Mail-32--743075380 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Emmanuel, I will let the authors of the draft answer the excellent comments that have been raised on the list during WG LC (and I'll add mine) but I would like to comment on your statement and hopefully clarify our objective. On Dec 9, 2008, at 10:02 AM, Emmanuel Baccelli wrote: > Hi all, > > I think this draft is far from being ready to become an RFC, and > such for several reasons, some of which are, unfortunately, > structural. > > 1 - The draft is evaluating moving targets such as OLSRv2, Dymo, > NHDP, which are potential solutions that are not finalized yet. > These protocols could meet more requirements in the end (maybe all > of them?). For this reason, the "pass/fail" table of section 5 > cannot honestly list anything else but a series of "question > marks" (or "pass"), for now, for these protocols. This makes this > table rather useless, and thus this whole draft rather useless, > presently. NO. Let me clarify something really important. The WG cannot afford to wait until all protocols are finalized to get a routing solution for LLN. The industry is waiting for a routing solution for such networks and time is absolutely critical. No we have to analyze the state of the art as of today. > > 2 - The ROLL charter mentions that " Existing IGPs, MANET, NEMO, DTN > routing protocols will be part of evaluation." I did not see > anything mentioned about DTN protocols, or Nemo in the draft, not > even a justification why they are not mentioned. > Would you want to make a contribution ? > 3 - The draft is not constructive in its current shape. I do not think that your comment is fair. The draft has been discussed in the WG for quite some time and extensive discussion took place during the interim WG and on the ML. > It is on the other hand extremely controversial with its judgement, > and does not reflect a consensus within the community, not even a > rough one. > Bear with us: we are not *judging* protocols: we are evaluating the existing routing protocols *in light* of our specific requirements. Yes one can argue for ever on a pass/fail criteria but we have to be driven by rough consensus to be able to move forward. Of course, if there is a mistake when evaluating a protocol it has to be fixed. Thanks. JP. > Emmanuel > > > On Mon, Dec 8, 2008 at 7:50 PM, Thomas Heide Clausen > wrote: > > On Dec 8, 2008, at 18:58 PM, Dearlove, Christopher (UK) wrote: > > > Your point about hierarchical addressing is interesting, and I think > it relates to comments others have made on fisheye routing and other > state suppression approaches. > > Not quite. Hierarchical allocation is indeed a state suppression > approach. However fisheye is a control message suppression approach. > > > And, it should be added that such are, of course complementing each > other. > > Thomas > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-32--743075380 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Emmanuel,

I will let the authors of the draft answer = the excellent comments that have been raised on the list during WG LC = (and I'll add mine) but I would like to comment on your statement and = hopefully clarify our objective.

On Dec 9, 2008, = at 10:02 AM, Emmanuel Baccelli wrote:

Hi = all,

I think this draft is far from being ready = to become an RFC, and such for several reasons, some of which are, = unfortunately, structural.

1 - The draft is = evaluating moving targets such as OLSRv2, Dymo, NHDP, which are = potential solutions that are not finalized yet. These protocols could = meet more requirements in the end (maybe all of them?). For this reason, = the "pass/fail" table of section 5 cannot honestly list anything else = but a series of "question marks" (or "pass"), for now, for these = protocols. This makes this table rather useless, and thus this whole = draft rather useless, = presently.

NO. Let me = clarify something really important.

The WG = cannot afford to wait until all protocols are finalized to get a routing = solution for LLN. The industry is waiting for a routing solution for = such networks and time is absolutely critical. No we have to analyze the = state of the art as of today.

=

2 - The ROLL charter mentions that " Existing = IGPs, MANET, NEMO, DTN routing protocols will be part of = evaluation." I did not see anything mentioned about DTN protocols, or = Nemo in the draft, not even a justification why they are not = mentioned.
=


Would you want to = make a contribution ?

3 = - The draft is not constructive in its current shape. =

I do not think that your = comment is fair. The draft has been discussed in the WG for quite some = time and extensive discussion took place during the interim WG and on = the ML.

It = is on the other hand extremely controversial with its judgement, and = does not reflect a consensus within the community, not even a rough = one.


Bear = with us: we are not *judging* protocols: we are evaluating the existing = routing protocols *in light* of our specific requirements. Yes one can = argue for ever on a pass/fail criteria but we have to be driven by rough = consensus to be able to move forward. Of course, if there is a mistake = when evaluating a protocol it has to be = fixed. 

Thanks.

JP.=

Emmanuel


On Mon, Dec 8, 2008 at 7:50 PM, Thomas Heide = Clausen <ietf@thomasclausen.org> = wrote:

On Dec 8, 2008, at 18:58 PM, Dearlove, Christopher = (UK) wrote:


Your point about hierarchical addressing is = interesting, and I think
it relates to comments others have made on = fisheye routing and other
state suppression approaches.
=

Not quite. Hierarchical allocation is indeed a state = suppression
approach. However fisheye is a control message = suppression approach.


And, it should = be added that such are, of course complementing each other.

Thomas


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

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

= --Apple-Mail-32--743075380-- --===============0496535737== 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 --===============0496535737==-- From roll-bounces@ietf.org Tue Dec 9 03:51:48 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EF7C3A6B0E; Tue, 9 Dec 2008 03:51:48 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD1C63A6B0E for ; Tue, 9 Dec 2008 03:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAE2fAavQADa for ; Tue, 9 Dec 2008 03:51:45 -0800 (PST) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id 79D593A6802 for ; Tue, 9 Dec 2008 03:51:45 -0800 (PST) Received: from aste-genev-bois-153-1-11-44.w83-112.abo.wanadoo.fr ([83.112.73.44] helo=[192.168.147.109]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LA17r-00035I-3F; Tue, 09 Dec 2008 11:51:39 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 83.112.73.44 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19YF1TEKgfgLbytWKrvEmDh In-Reply-To: References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <58F150DC-F6D1-4C08-97F9-3EAE292DF0FE@thomasclausen.org> From: Thomas Heide Clausen Date: Tue, 9 Dec 2008 12:51:51 +0100 To: JP Vasseur X-Mailer: Apple Mail (2.753.1) Cc: charliep@computer.org, Emmanuel Baccelli , roll@ietf.org, arsalan@eecs.berkeley.edu Subject: Re: [Roll] Working Group Last Call:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============2031978384==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============2031978384== Content-Type: multipart/alternative; boundary=Apple-Mail-7--739275414 --Apple-Mail-7--739275414 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi JP and all, A quick comment/question below.... On Dec 9, 2008, at 11:48 AM, JP Vasseur wrote: > Hi Emmanuel, > > I will let the authors of the draft answer the excellent comments > that have been raised on the list during WG LC (and I'll add mine) > but I would like to comment on your statement and hopefully clarify > our objective. > > On Dec 9, 2008, at 10:02 AM, Emmanuel Baccelli wrote: > >> Hi all, >> >> I think this draft is far from being ready to become an RFC, and >> such for several reasons, some of which are, unfortunately, >> structural. >> >> 1 - The draft is evaluating moving targets such as OLSRv2, Dymo, >> NHDP, which are potential solutions that are not finalized yet. >> These protocols could meet more requirements in the end (maybe all >> of them?). For this reason, the "pass/fail" table of section 5 >> cannot honestly list anything else but a series of "question >> marks" (or "pass"), for now, for these protocols. This makes this >> table rather useless, and thus this whole draft rather useless, >> presently. > > NO. Let me clarify something really important. > > The WG cannot afford to wait until all protocols are finalized to > get a routing solution for LLN. The industry is waiting for a > routing solution for such networks and time is absolutely critical. Without being contentious, this is as such a fair point: "industry is waiting for a solution". An argument can be made that in that case "starting from scratch" would be counter-productive, and that it'd be beneficial to start from something already in existence, or already in development, if at all possible -- with the "already in development" being an asset as it gives a head start and, potentially, can accommodate the ROLL wg suggestions still. I deduct, therefore, that the intent is to next analyze in detail the potential "tweaks and tunings and potential extensions" possible to the existing six or so protocols in the roll-protocols-survey-02? Thomas > No we have to analyze the state of the art as of today. > >> 2 - The ROLL charter mentions that " Existing IGPs, MANET, NEMO, >> DTN routing protocols will be part of evaluation." I did not see >> anything mentioned about DTN protocols, or Nemo in the draft, not >> even a justification why they are not mentioned. >> > > Would you want to make a contribution ? > >> 3 - The draft is not constructive in its current shape. > > I do not think that your comment is fair. The draft has been > discussed in the WG for quite some time and extensive discussion > took place during the interim WG and on the ML. > >> It is on the other hand extremely controversial with its >> judgement, and does not reflect a consensus within the community, >> not even a rough one. >> > > Bear with us: we are not *judging* protocols: we are evaluating the > existing routing protocols *in light* of our specific requirements. > Yes one can argue for ever on a pass/fail criteria but we have to > be driven by rough consensus to be able to move forward. Of course, > if there is a mistake when evaluating a protocol it has to be fixed. > > Thanks. > > JP. > >> Emmanuel >> >> >> On Mon, Dec 8, 2008 at 7:50 PM, Thomas Heide Clausen >> wrote: >> >> On Dec 8, 2008, at 18:58 PM, Dearlove, Christopher (UK) wrote: >> >> >> Your point about hierarchical addressing is interesting, and I think >> it relates to comments others have made on fisheye routing and other >> state suppression approaches. >> >> Not quite. Hierarchical allocation is indeed a state suppression >> approach. However fisheye is a control message suppression approach. >> >> >> And, it should be added that such are, of course complementing >> each other. >> >> Thomas >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > --Apple-Mail-7--739275414 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi JP and all,

A quick comment/question = below....

On Dec 9, 2008, at 11:48 = AM, JP Vasseur wrote:

Hi = Emmanuel,

I will let the authors of the draft answer = the excellent comments that have been raised on the list during WG LC = (and I'll add mine) but I would like to comment on your statement and = hopefully clarify our objective.

On Dec 9, 2008, = at 10:02 AM, Emmanuel Baccelli wrote:

Hi = all,

I think this draft is far from being ready = to become an RFC, and such for several reasons, some of which are, = unfortunately, structural.

1 - The draft is = evaluating moving targets such as OLSRv2, Dymo, NHDP, which are = potential solutions that are not finalized yet. These protocols could = meet more requirements in the end (maybe all of them?). For this reason, = the "pass/fail" table of section 5 cannot honestly list anything else = but a series of "question marks" (or "pass"), for now, for these = protocols. This makes this table rather useless, and thus this whole = draft rather useless, = presently.

NO. Let me = clarify something really important.

The WG = cannot afford to wait until all protocols are finalized to get a routing = solution for LLN. The industry is waiting for a routing solution for = such networks and time is absolutely = critical.

Without = being contentious, this is as such a fair point: "industry is waiting = for a solution". An argument can be made that in that case "starting = from scratch" would be counter-productive, and that it'd be beneficial = to start from something already in existence, or already in development, = if at all possible -- with the "already in development" being an asset = as it gives a head start and, potentially, can accommodate the ROLL wg = suggestions still.=A0

I deduct, therefore, that = the intent is to next analyze in detail the potential "tweaks and = tunings and potential extensions" possible to the existing six or so = protocols in the = roll-protocols-survey-02?

Thomas

=A0No we have to analyze the state of = the art as of today.

2 - The ROLL charter mentions = that "=A0Existing IGPs, MANET,=A0NEMO, DTN routing protocols will be = part of evaluation." I did not see anything mentioned about DTN = protocols, or Nemo in the draft, not even a justification why they are = not mentioned.
=


Would you want to = make a contribution ?

3 = - The draft is not constructive in its current shape. =

I do not think that your = comment is fair. The draft has been discussed in the WG for quite some = time and extensive discussion took place during the interim WG and on = the ML.

It = is on the other hand extremely controversial with its judgement, and = does not reflect a consensus within the community, not even a rough = one.


Bear = with us: we are not *judging* protocols: we are evaluating the existing = routing protocols *in light* of our specific requirements. Yes one can = argue for ever on a pass/fail criteria but we have to be driven by rough = consensus to be able to move forward. Of course, if there is a mistake = when evaluating a protocol it has to be = fixed.=A0

Thanks.

JP.
Emmanuel


On Mon, Dec 8, 2008 at 7:50 PM, Thomas Heide = Clausen <ietf@thomasclausen.org> = wrote:

On Dec 8, 2008, at 18:58 PM, Dearlove, Christopher = (UK) wrote:


Your point about hierarchical addressing is = interesting, and I think
it relates to comments others have made on = fisheye routing and other
state suppression approaches.
=

Not quite. Hierarchical allocation is indeed a state = suppression
approach. However fisheye is a control message = suppression approach.


And, it should = be added that such are, of course complementing each other.

Thomas


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

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


= --Apple-Mail-7--739275414-- --===============2031978384== 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 --===============2031978384==-- From roll-bounces@ietf.org Tue Dec 9 03:54:17 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3CD03A6B0D; Tue, 9 Dec 2008 03:54:17 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A12213A6B0D for ; Tue, 9 Dec 2008 03:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iR4+aH67mFK for ; Tue, 9 Dec 2008 03:54:15 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by core3.amsl.com (Postfix) with ESMTP id 851273A6802 for ; Tue, 9 Dec 2008 03:54:15 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b6so671194ana.4 for ; Tue, 09 Dec 2008 03:54:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=pwBfn9+FV2rjF5fb7mMVbGLe9V/WzmT1df3nHCPh+w8=; b=Y3VIzNdUwmhutLzTvU4d096o0nkYNt8tmKBwxRI8d193sqXYfkCOvFTJQXqXNF88e1 /uIYmU538dkkAaUl807fLCvJWmwtRBTCaI54ceffAVD+OaSTE6UGrfvp1vffjKditEX3 BtlQtt9kql5P7JzOUVpTSvManw0jB79LZrw/I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=ImKreZj3CDAbR0O4zck6hCrkYvq9wabbrbs3YRn71voEwUTwZI782UT9Y7uHp0DRDs BCROfOa/7coL7Nz2dotNDVtvJJqNI2/7BBnGuIlWifEWrmIQKdMYKtKwt9zKwdm2K1cW xShZHvYhq+965t7BfPLQCy+Har7+MXNNS9xiU= Received: by 10.103.241.5 with SMTP id t5mr1072mur.127.1228823646751; Tue, 09 Dec 2008 03:54:06 -0800 (PST) Received: by 10.103.248.12 with HTTP; Tue, 9 Dec 2008 03:54:05 -0800 (PST) Message-ID: Date: Tue, 9 Dec 2008 12:54:05 +0100 From: "Emmanuel Baccelli" To: roll@ietf.org In-Reply-To: MIME-Version: 1.0 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> X-Google-Sender-Auth: 501136f3ddef07ce Subject: Re: [Roll] Working Group Last Call:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============0672350277==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0672350277== Content-Type: multipart/alternative; boundary="----=_Part_64329_23781500.1228823646739" ------=_Part_64329_23781500.1228823646739 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tue, Dec 9, 2008 at 11:48 AM, JP Vasseur wrote: > > > 1 - The draft is evaluating moving targets such as OLSRv2, Dymo, NHDP, > which are potential solutions that are not finalized yet. These protocols > could meet more requirements in the end (maybe all of them?). For this > reason, the "pass/fail" table of section 5 cannot honestly list anything > else but a series of "question marks" (or "pass"), for now, for these > protocols. This makes this table rather useless, and thus this whole draft > rather useless, presently. > > > NO. *Let me clarify something really important.* > > The WG cannot afford to wait until all protocols are finalized to get a > routing solution for LLN. The industry is waiting for a routing solution for > such networks and time is absolutely critical. No we have to analyze the > state of the art as of today. > This seems incoherent to me. On one hand you say "we need a solution right now". And on the other hand, this document dismisses all existing approaches, because "we want the dream protocol". To me this sounds like we're heading towards another research phase, and you will thus not get a solution before long. > 2 - The ROLL charter mentions that " Existing IGPs, MANET, NEMO, DTN > routing protocols will be part of evaluation." I did not see anything > mentioned about DTN protocols, or Nemo in the draft, not even a > justification why they are not mentioned. > > > Would you want to make a contribution ? > I am suggesting we consider existing potential candidates before we go out there and maybe reinvent the wheel. > > 3 - The draft is not constructive in its current shape. > > > I do not think that your comment is fair. The draft has been discussed in > the WG for quite some time and extensive discussion took place during the > interim WG and on the ML. > Yes there have been some discussions, but there is no consensus on the approach taken by this document. And there is no rough consensus either. Emmanuel ------=_Part_64329_23781500.1228823646739 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Tue, Dec 9, 2008 at 11:48 AM, JP Vasseur <jvasseur@cisco.com> wrote:

1 - The draft is evaluating moving targets such as OLSRv2, Dymo, NHDP, which are potential solutions that are not finalized yet. These protocols could meet more requirements in the end (maybe all of them?). For this reason, the "pass/fail" table of section 5 cannot honestly list anything else but a series of "question marks" (or "pass"), for now, for these protocols. This makes this table rather useless, and thus this whole draft rather useless, presently.

NO. Let me clarify something really important.

The WG cannot afford to wait until all protocols are finalized to get a routing solution for LLN. The industry is waiting for a routing solution for such networks and time is absolutely critical. No we have to analyze the state of the art as of today.


This seems incoherent to me. On one hand you say "we need a solution right now". And on the other hand, this document dismisses all existing approaches, because "we want the dream protocol". To me this sounds like we're heading towards another research phase, and you will thus not get a solution before long. 
 


2 - The ROLL charter mentions that " Existing IGPs, MANET, NEMO, DTN routing protocols will be part of evaluation." I did not see anything mentioned about DTN protocols, or Nemo in the draft, not even a justification why they are not mentioned.


Would you want to make a contribution ? 


I am suggesting we consider existing potential candidates before we go out there and maybe reinvent the wheel. 


 

3 - The draft is not constructive in its current shape.

I do not think that your comment is fair. The draft has been discussed in the WG for quite some time and extensive discussion took place during the interim WG and on the ML.


Yes there have been some discussions, but there is no consensus on the approach taken by this document. And there is no rough consensus either.

Emmanuel
------=_Part_64329_23781500.1228823646739-- --===============0672350277== 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 --===============0672350277==-- From roll-bounces@ietf.org Tue Dec 9 06:43:24 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F022F28C15C; Tue, 9 Dec 2008 06:43:23 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B473728C15C for ; Tue, 9 Dec 2008 06:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.526 X-Spam-Level: X-Spam-Status: No, score=-10.526 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSzCC89uupin for ; Tue, 9 Dec 2008 06:43:21 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5AEF828C16B for ; Tue, 9 Dec 2008 06:43:20 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,741,1220227200"; d="scan'208,217";a="28113695" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Dec 2008 14:43:05 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mB9Eh5eJ011146; Tue, 9 Dec 2008 15:43:05 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mB9Eh5Fw008730; Tue, 9 Dec 2008 14:43:05 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Dec 2008 15:43:05 +0100 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Dec 2008 15:43:04 +0100 Message-Id: From: JP Vasseur To: Emmanuel Baccelli , charliep@computer.org, Thomas Heide Clausen In-Reply-To: <58F150DC-F6D1-4C08-97F9-3EAE292DF0FE@thomasclausen.org> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 9 Dec 2008 15:43:03 +0100 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> <58F150DC-F6D1-4C08-97F9-3EAE292DF0FE@thomasclausen.org> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 09 Dec 2008 14:43:04.0732 (UTC) FILETIME=[71837DC0:01C95A0C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15560; t=1228833785; x=1229697785; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20*=20Summary=20*=20Re=3A=20[Roll]=20Working=20Gr oup=20Last=20Call=3Adraft-ietf-roll-protocols-survey-02 |Sender:=20; bh=tvmU3zsRjLAyczK3+tLQAR1W0eHDwQ9hbAPXXTanKMg=; b=gXvA8OwzrRMPNs5dBJpU1FtRbYRJhLz6NhI3VoH2LVVw+dWubR+VLpBQ0y J6kURhpXFssB8sijblaiFw2WxC/hvFHT2hod+FOTg+wXoeo34/EBkAGXzZiD rqVosxvfY/; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org, arsalan@eecs.berkeley.edu Subject: [Roll] * Summary * Re: Working Group Last Call:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============1897559497==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1897559497== Content-Type: multipart/alternative; boundary=Apple-Mail-36--729002789 --Apple-Mail-36--729002789 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Thomas, On Dec 9, 2008, at 12:51 PM, Thomas Heide Clausen wrote: > Hi JP and all, > > A quick comment/question below.... > > On Dec 9, 2008, at 11:48 AM, JP Vasseur wrote: > >> Hi Emmanuel, >> >> I will let the authors of the draft answer the excellent comments >> that have been raised on the list during WG LC (and I'll add mine) >> but I would like to comment on your statement and hopefully clarify >> our objective. >> >> On Dec 9, 2008, at 10:02 AM, Emmanuel Baccelli wrote: >> >>> Hi all, >>> >>> I think this draft is far from being ready to become an RFC, and >>> such for several reasons, some of which are, unfortunately, >>> structural. >>> >>> 1 - The draft is evaluating moving targets such as OLSRv2, Dymo, >>> NHDP, which are potential solutions that are not finalized yet. >>> These protocols could meet more requirements in the end (maybe all >>> of them?). For this reason, the "pass/fail" table of section 5 >>> cannot honestly list anything else but a series of "question >>> marks" (or "pass"), for now, for these protocols. This makes this >>> table rather useless, and thus this whole draft rather useless, >>> presently. >> >> NO. Let me clarify something really important. >> >> The WG cannot afford to wait until all protocols are finalized to >> get a routing solution for LLN. The industry is waiting for a >> routing solution for such networks and time is absolutely critical. > > Without being contentious, this is as such a fair point: "industry > is waiting for a solution". An argument can be made that in that > case "starting from scratch" would be counter-productive, and that > it'd be beneficial to start from something already in existence, or > already in development, if at all possible -- with the "already in > development" being an asset as it gives a head start and, > potentially, can accommodate the ROLL wg suggestions still. > > I deduct, therefore, that the intent is to next analyze in detail > the potential "tweaks and tunings and potential extensions" possible > to the existing six or so protocols in the roll-protocols-survey-02? > Agreeing with your statement. If we can find an existing solution, adapt it and make it work, that would be by far the preferred path to take. Two comments though: 1) We all know that we can adapt lots of protocols to meet a set of requirements but we also need to make sure that we do not end up with a protocol with lots of features that we will not use and that will require extra memory, CPU, ... We are running on highly constrained environments with very limited resources. 2) Many of the active ROLL WG members participants have real world experience, thus we do not start "from scratch" per say, and we could leverage some of the experience learnt from deployed proprietary protocols. We will *no* embrace an existing proprietary protocol but we can learn lessons from deployed networks. To summarize: 1) Extensive work has been done on the requirements front for 4 identified use cases, 2) Before starting any protocol work, we had to answer to the following question: "Can we find an existing protocol that meets our requirements ?". The answer to this question is "no", which does not mean that we could not adapt an existing routing protocol (!). I think that we have a consensus here, otherwise let us know. Note that we will not continue to work on this ID (hence the WG LC), the aim of which was to answer the question above. 3) The next step is to see whether (1) we can adapt an existing routing protocol with the help of the WG "owning" these protocols or (2) design a new routing protocol (in ROLL). For this we need to recharter. And we should explore both paths in parallel. Does that make sense ? Many Thanks. JP. > Thomas > >> No we have to analyze the state of the art as of today. >> >>> 2 - The ROLL charter mentions that " Existing IGPs, MANET, NEMO, >>> DTN routing protocols will be part of evaluation." I did not see >>> anything mentioned about DTN protocols, or Nemo in the draft, not >>> even a justification why they are not mentioned. >>> >> >> Would you want to make a contribution ? >> >>> 3 - The draft is not constructive in its current shape. >> >> I do not think that your comment is fair. The draft has been >> discussed in the WG for quite some time and extensive discussion >> took place during the interim WG and on the ML. >> >>> It is on the other hand extremely controversial with its >>> judgement, and does not reflect a consensus within the community, >>> not even a rough one. >>> >> >> Bear with us: we are not *judging* protocols: we are evaluating the >> existing routing protocols *in light* of our specific requirements. >> Yes one can argue for ever on a pass/fail criteria but we have to >> be driven by rough consensus to be able to move forward. Of course, >> if there is a mistake when evaluating a protocol it has to be fixed. >> >> Thanks. >> >> JP. >> >>> Emmanuel >>> >>> >>> On Mon, Dec 8, 2008 at 7:50 PM, Thomas Heide Clausen >> > wrote: >>> >>> On Dec 8, 2008, at 18:58 PM, Dearlove, Christopher (UK) wrote: >>> >>> >>> Your point about hierarchical addressing is interesting, and I think >>> it relates to comments others have made on fisheye routing and other >>> state suppression approaches. >>> >>> Not quite. Hierarchical allocation is indeed a state suppression >>> approach. However fisheye is a control message suppression approach. >>> >>> >>> And, it should be added that such are, of course complementing >>> each other. >>> >>> Thomas >>> >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> > --Apple-Mail-36--729002789 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Thomas,

On = Dec 9, 2008, at 12:51 PM, Thomas Heide Clausen wrote:

Hi JP and = all,

A quick comment/question = below....

On Dec 9, 2008, at 11:48 = AM, JP Vasseur wrote:

Hi = Emmanuel,

I will let the authors of the draft answer = the excellent comments that have been raised on the list during WG LC = (and I'll add mine) but I would like to comment on your statement and = hopefully clarify our objective.

On Dec 9, 2008, = at 10:02 AM, Emmanuel Baccelli wrote:

Hi = all,

I think this draft is far from being ready = to become an RFC, and such for several reasons, some of which are, = unfortunately, structural.

1 - The draft is = evaluating moving targets such as OLSRv2, Dymo, NHDP, which are = potential solutions that are not finalized yet. These protocols could = meet more requirements in the end (maybe all of them?). For this reason, = the "pass/fail" table of section 5 cannot honestly list anything else = but a series of "question marks" (or "pass"), for now, for these = protocols. This makes this table rather useless, and thus this whole = draft rather useless, = presently.

NO. Let me = clarify something really important.

The WG = cannot afford to wait until all protocols are finalized to get a routing = solution for LLN. The industry is waiting for a routing solution for = such networks and time is absolutely = critical.

Without = being contentious, this is as such a fair point: "industry is waiting = for a solution". An argument can be made that in that case "starting = from scratch" would be counter-productive, and that it'd be beneficial = to start from something already in existence, or already in development, = if at all possible -- with the "already in development" being an asset = as it gives a head start and, potentially, can accommodate the ROLL wg = suggestions still. 

I deduct, therefore, = that the intent is to next analyze in detail the potential "tweaks and = tunings and potential extensions" possible to the existing six or so = protocols in the = roll-protocols-survey-02?


Agreeing with your = statement. 

If we can find an existing = solution, adapt it and make it work, that would be by far the preferred = path to take. 

Two comments = though:
1) We all know that we can adapt lots of protocols to = meet a set of requirements but we also need to make sure that we do not = end up with a protocol with lots of features that we will not use and = that will require extra memory, CPU, ... We are running on highly = constrained environments with very limited resources.
2) Many = of the active ROLL WG members participants have real world experience, = thus we do not start "from scratch" per say, and we could leverage some = of the experience learnt from deployed proprietary protocols. We will = *no* embrace an existing proprietary protocol but we can learn = lessons from deployed networks.

To = summarize:
1) Extensive work has been done on the requirements = front for 4 identified use cases,
2) Before starting any = protocol work, we had to answer to the following question: "Can we find = an existing protocol that meets our requirements ?". The answer to this = question is "no", which does not mean that we could not adapt an = existing routing protocol (!). I think that we have a consensus here, = otherwise let us know.
Note that we will not continue to work = on this ID (hence the WG LC), the aim of which was to answer the = question above.
3) The next step is to see whether (1) we can = adapt an existing routing protocol with the help of the WG "owning" = these protocols or (2) design a new routing protocol (in ROLL). For this = we need to recharter. And we should explore both paths = in parallel. 

Does that make sense = ?

Many = Thanks.

JP.


 No we have to analyze the state of the art as of = today.

2 - The ROLL charter mentions = that " Existing IGPs, MANET, NEMO, DTN routing protocols will = be part of evaluation." I did not see anything mentioned about DTN = protocols, or Nemo in the draft, not even a justification why they are = not mentioned.
=


Would you want to = make a contribution ?

3 = - The draft is not constructive in its current shape. =

I do not think that your = comment is fair. The draft has been discussed in the WG for quite some = time and extensive discussion took place during the interim WG and on = the ML.

It = is on the other hand extremely controversial with its judgement, and = does not reflect a consensus within the community, not even a rough = one.


Bear = with us: we are not *judging* protocols: we are evaluating the existing = routing protocols *in light* of our specific requirements. Yes one can = argue for ever on a pass/fail criteria but we have to be driven by rough = consensus to be able to move forward. Of course, if there is a mistake = when evaluating a protocol it has to be = fixed. 

Thanks.

JP.=

Emmanuel


On Mon, Dec 8, 2008 at 7:50 PM, Thomas Heide = Clausen <ietf@thomasclausen.org> = wrote:

On Dec 8, 2008, at 18:58 PM, Dearlove, Christopher = (UK) wrote:


Your point about hierarchical addressing is = interesting, and I think
it relates to comments others have made on = fisheye routing and other
state suppression approaches.
=

Not quite. Hierarchical allocation is indeed a state = suppression
approach. However fisheye is a control message = suppression approach.


And, it should = be added that such are, of course complementing each other.

Thomas


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

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



= --Apple-Mail-36--729002789-- --===============1897559497== 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 --===============1897559497==-- From roll-bounces@ietf.org Tue Dec 9 06:53:32 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A37D43A6821; Tue, 9 Dec 2008 06:53:32 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0730B3A6821 for ; Tue, 9 Dec 2008 06:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.533 X-Spam-Level: X-Spam-Status: No, score=-10.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjiU5jbtaD42 for ; Tue, 9 Dec 2008 06:53:30 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 18E233A67AA for ; Tue, 9 Dec 2008 06:53:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,741,1220227200"; d="scan'208,217";a="28115249" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 09 Dec 2008 14:53:23 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mB9ErN31021063; Tue, 9 Dec 2008 15:53:23 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mB9ErNoR012644; Tue, 9 Dec 2008 14:53:23 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Dec 2008 15:53:23 +0100 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Dec 2008 15:53:22 +0100 Message-Id: From: JP Vasseur To: Emmanuel Baccelli In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 9 Dec 2008 15:53:22 +0100 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 09 Dec 2008 14:53:22.0962 (UTC) FILETIME=[E201E720:01C95A0D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10142; t=1228834403; x=1229698403; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Working=20Group=20Last=20Call= 3Adraft-ietf-roll-protocols-survey-02 |Sender:=20; bh=mHVdCjoQY/m/5VghkXBQAkZDNbT4/poB6GF3Zd/5iP8=; b=SjkDdSsjvyIZj6iHVh7KD9CS3q1eX3w1JCig0T9F41ngDLf+TKWK+zQfHY GVWsbUcnlUeDmJw116CyFIoJQSbDg+FqHXvPEFeY1FNdAXJROKORurAKH4he OIajfOHQbH; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] Working Group Last Call:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============0259327388==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0259327388== Content-Type: multipart/alternative; boundary=Apple-Mail-37--728384472 --Apple-Mail-37--728384472 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Emmanuel, On Dec 9, 2008, at 12:54 PM, Emmanuel Baccelli wrote: > > > On Tue, Dec 9, 2008 at 11:48 AM, JP Vasseur > wrote: >> >> 1 - The draft is evaluating moving targets such as OLSRv2, Dymo, >> NHDP, which are potential solutions that are not finalized yet. >> These protocols could meet more requirements in the end (maybe all >> of them?). For this reason, the "pass/fail" table of section 5 >> cannot honestly list anything else but a series of "question >> marks" (or "pass"), for now, for these protocols. This makes this >> table rather useless, and thus this whole draft rather useless, >> presently. > > NO. Let me clarify something really important. > > The WG cannot afford to wait until all protocols are finalized to > get a routing solution for LLN. The industry is waiting for a > routing solution for such networks and time is absolutely critical. > No we have to analyze the state of the art as of today. > > > This seems incoherent to me. On one hand you say "we need a solution > right now". And on the other hand, this document dismisses all > existing approaches, because "we want the dream protocol". To me > this sounds like we're heading towards another research phase, and > you will thus not get a solution before long. Emmanuel, as you might have noticed, there are many solutions *deployed* out there, unfortunately not IP-based and this is why we are here. This is not research at all (not even sure why we are saying this). Yes the industry does need a solution *now*, which does not mean that we should rush out and select an existing routing protocol if it does not meet our requirements. In other words, 1- There is a lot of expertise on routing for LLN in this WG 2- There is clearly a need for a solution *today*: look at all other (deployed) non IP solutions out there 3- Detailed analysis of the routing requirements has been conducted 4- We are not talking about a "dream protocol": again this is very much realistic since solutions do exist today (not IP unfortunately :- ( ....) 5- We are not excluding to use an existing (extended) protocol at all provided that it meets our requirements and it does not carry extra overhead that will comprise their use on highly constrained device. > > >> >> 2 - The ROLL charter mentions that " Existing IGPs, MANET, NEMO, >> DTN routing protocols will be part of evaluation." I did not see >> anything mentioned about DTN protocols, or Nemo in the draft, not >> even a justification why they are not mentioned. >> > > Would you want to make a contribution ? > > > I am suggesting we consider existing potential candidates before we > go out there and maybe reinvent the wheel. > Your help is greatly appreciated. > > > >> 3 - The draft is not constructive in its current shape. > > I do not think that your comment is fair. The draft has been > discussed in the WG for quite some time and extensive discussion > took place during the interim WG and on the ML. > > > Yes there have been some discussions, but there is no consensus on > the approach taken by this document. Thanks for your feed-back here. What do you propose ? > And there is no rough consensus either. > Please refer to the WG minutes + several emails on the ML, with a good consensus. That being said, I hear you and thanks for your comments. I do register your disagreement. Having read again others' email, I do not think that this is a general feeling. Thanks. JP. > Emmanuel > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-37--728384472 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Emmanuel,

On Dec 9, 2008, at 12:54 PM, Emmanuel = Baccelli wrote:



On Tue, Dec 9, 2008 at = 11:48 AM, JP Vasseur <jvasseur@cisco.com> = wrote:
=

1 - The draft is evaluating moving targets such as = OLSRv2, Dymo, NHDP, which are potential solutions that are not finalized = yet. These protocols could meet more requirements in the end (maybe all = of them?). For this reason, the "pass/fail" table of section 5 cannot = honestly list anything else but a series of "question marks" (or = "pass"), for now, for these protocols. This makes this table rather = useless, and thus this whole draft rather useless, presently.
=

NO. Let me clarify = something really important.

The WG cannot = afford to wait until all protocols are finalized to get a routing = solution for LLN. The industry is waiting for a routing solution for = such networks and time is absolutely critical. No we have to analyze the = state of the art as of today.

=
This seems incoherent to me. On one hand you say "we need = a solution right now". And on the other hand, this document dismisses = all existing approaches, because "we want the dream protocol". To me = this sounds like we're heading towards another research phase, and you = will thus not get a solution before = long. 

Emmanuel, as you = might have noticed, there are many solutions *deployed* out there, = unfortunately not IP-based and this is why we are here. This is not = research at all (not even sure why we are saying = this). 
Yes the industry does need a solution *now*, = which does not mean that we should rush out and select an existing = routing protocol if it does not meet our = requirements.

In other words,
1- = There is a lot of expertise on routing for LLN in this WG
2- = There is clearly a need for a solution *today*: look at all other = (deployed) non IP solutions out there
3- Detailed analysis of = the routing requirements has been conducted
4- We are not = talking about a "dream protocol": again this is very much realistic = since solutions do exist today (not IP unfortunately :-( = ....)
5- We are not excluding to use an existing (extended) = protocol at all provided that it meets our requirements and it does not = carry extra overhead that will comprise their use on highly constrained = device.


 

=
2 - The ROLL charter mentions that " Existing IGPs, = MANET, NEMO, DTN routing protocols will be part of evaluation." I = did not see anything mentioned about DTN protocols, or Nemo in the = draft, not even a justification why they are not mentioned.
=


Would you = want to make a contribution = ? 


=
I am suggesting we consider existing potential candidates before we = go out there and maybe reinvent the wheel. 
=


Your help is = greatly appreciated.


 

3 - The draft is not = constructive in its current shape. =

I do not think that = your comment is fair. The draft has been discussed in the WG for quite = some time and extensive discussion took place during the interim WG and = on the ML.

=
Yes there have been some discussions, but there is no = consensus on the approach taken by this document. =

Thanks for your feed-back = here. What do you propose ?

And there is no rough consensus either.
=


Please refer to = the WG minutes + several emails on the ML, with a good consensus. That = being said, I hear you and thanks for your comments. I do register your = disagreement. Having read again others' email, I do not think that this = is a general = feeling.

Thanks.

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

= --Apple-Mail-37--728384472-- --===============0259327388== 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 --===============0259327388==-- From roll-bounces@ietf.org Tue Dec 9 07:01:40 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D87F3A687A; Tue, 9 Dec 2008 07:01:40 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C63C28C114 for ; Tue, 9 Dec 2008 07:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+FgptKobs9m for ; Tue, 9 Dec 2008 07:01:36 -0800 (PST) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id 90C743A684F for ; Tue, 9 Dec 2008 07:01:36 -0800 (PST) Received: from aste-genev-bois-153-1-11-44.w83-112.abo.wanadoo.fr ([83.112.73.44] helo=[192.168.147.109]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LA45V-000ANz-1I; Tue, 09 Dec 2008 15:01:28 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 83.112.73.44 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+g9oyYu+vdjs0ws39mczIe In-Reply-To: References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> <58F150DC-F6D1-4C08-97F9-3EAE292DF0FE@thomasclausen.org> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Thomas Heide Clausen Date: Tue, 9 Dec 2008 16:01:36 +0100 To: JP Vasseur X-Mailer: Apple Mail (2.753.1) Cc: charliep@computer.org, Emmanuel Baccelli , roll@ietf.org, arsalan@eecs.berkeley.edu Subject: Re: [Roll] * Summary * Re: Working Group Last Call:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============0735451529==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0735451529== Content-Type: multipart/alternative; boundary=Apple-Mail-10--727889819 --Apple-Mail-10--727889819 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi JP, On Dec 9, 2008, at 15:43 PM, JP Vasseur wrote: > Hi Thomas, > > On Dec 9, 2008, at 12:51 PM, Thomas Heide Clausen wrote: > >> Hi JP and all, >> >> A quick comment/question below.... >> >> On Dec 9, 2008, at 11:48 AM, JP Vasseur wrote: >> >>> Hi Emmanuel, >>> >>> I will let the authors of the draft answer the excellent comments >>> that have been raised on the list during WG LC (and I'll add >>> mine) but I would like to comment on your statement and hopefully >>> clarify our objective. >>> >>> On Dec 9, 2008, at 10:02 AM, Emmanuel Baccelli wrote: >>> >>>> Hi all, >>>> >>>> I think this draft is far from being ready to become an RFC, and >>>> such for several reasons, some of which are, unfortunately, >>>> structural. >>>> >>>> 1 - The draft is evaluating moving targets such as OLSRv2, Dymo, >>>> NHDP, which are potential solutions that are not finalized yet. >>>> These protocols could meet more requirements in the end (maybe >>>> all of them?). For this reason, the "pass/fail" table of section >>>> 5 cannot honestly list anything else but a series of "question >>>> marks" (or "pass"), for now, for these protocols. This makes >>>> this table rather useless, and thus this whole draft rather >>>> useless, presently. >>> >>> NO. Let me clarify something really important. >>> >>> The WG cannot afford to wait until all protocols are finalized to >>> get a routing solution for LLN. The industry is waiting for a >>> routing solution for such networks and time is absolutely critical. >> >> Without being contentious, this is as such a fair point: "industry >> is waiting for a solution". An argument can be made that in that >> case "starting from scratch" would be counter-productive, and that >> it'd be beneficial to start from something already in existence, >> or already in development, if at all possible -- with the "already >> in development" being an asset as it gives a head start and, >> potentially, can accommodate the ROLL wg suggestions still. >> >> I deduct, therefore, that the intent is to next analyze in detail >> the potential "tweaks and tunings and potential extensions" >> possible to the existing six or so protocols in the roll-protocols- >> survey-02? >> > > Agreeing with your statement. > > If we can find an existing solution, adapt it and make it work, > that would be by far the preferred path to take. > So far so good -- it seems sensible to explore that. > Two comments though: > 1) We all know that we can adapt lots of protocols to meet a set of > requirements but we also need to make sure that we do not end up > with a protocol with lots of features that we will not use and that > will require extra memory, CPU, ... We are running on highly > constrained environments with very limited resources. No objections to this. > 2) Many of the active ROLL WG members participants have real world > experience, thus we do not start "from scratch" per say, and we > could leverage some of the experience learnt from deployed > proprietary protocols. We will *no* embrace an existing proprietary > protocol but we can learn lessons from deployed networks. Just to clarify, I did not intend to dismiss the experience of the participants in the ROLL wg, and my references to "from scratch" referred only to "IETF heritage" -- if you catch my drift. > To summarize: > 1) Extensive work has been done on the requirements front for 4 > identified use cases, > 2) Before starting any protocol work, we had to answer to the > following question: "Can we find an existing protocol that meets > our requirements ?". The answer to this question is "no", which > does not mean that we could not adapt an existing routing protocol > (!). I think that we have a consensus here, otherwise let us know. > Note that we will not continue to work on this ID (hence the WG > LC), the aim of which was to answer the question above. This, I am not in agreement with at all. As I indicated in my long email, the survey I-D is focusing narrowly on some (easily quantified) metrics, but ignoring others. For example "control cost" is included, but "path cost" is not -- and one may in this case trade off one for another. The cited example (zero-control-cost, flood all data) was in jest, but there *are* protocols that trade off path lengths for lower control cost - and vice-versa. Note that this is a single example only, I've identified others in other emails, and I shan't rehash it all here. The point is, that making potentially constraining recommendations based on an incomplete set of non-independent evaluation metrics isn't a good starting point for the wg -- rechartering (as you indicate below) or otherwise. I'd like to suggest that the authors of the survey I-D take on board the comments produced thus far, and complemented by the evaluation metrics otherwise indicated. As such, I respectfully join Emmanuel Baccelli in suggesting that the document is not ready for publication (yet). Thomas > 3) The next step is to see whether (1) we can adapt an existing > routing protocol with the help of the WG "owning" these protocols > or (2) design a new routing protocol (in ROLL). For this we need to > recharter. And we should explore both paths in parallel. > > Does that make sense ? > > Many Thanks. > > JP. > > >> Thomas >> >>> No we have to analyze the state of the art as of today. >>> >>>> 2 - The ROLL charter mentions that " Existing IGPs, MANET, NEMO, >>>> DTN routing protocols will be part of evaluation." I did not see >>>> anything mentioned about DTN protocols, or Nemo in the draft, >>>> not even a justification why they are not mentioned. >>>> >>> >>> Would you want to make a contribution ? >>> >>>> 3 - The draft is not constructive in its current shape. >>> >>> I do not think that your comment is fair. The draft has been >>> discussed in the WG for quite some time and extensive discussion >>> took place during the interim WG and on the ML. >>> >>>> It is on the other hand extremely controversial with its >>>> judgement, and does not reflect a consensus within the >>>> community, not even a rough one. >>>> >>> >>> Bear with us: we are not *judging* protocols: we are evaluating >>> the existing routing protocols *in light* of our specific >>> requirements. Yes one can argue for ever on a pass/fail criteria >>> but we have to be driven by rough consensus to be able to move >>> forward. Of course, if there is a mistake when evaluating a >>> protocol it has to be fixed. >>> >>> Thanks. >>> >>> JP. >>> >>>> Emmanuel >>>> >>>> >>>> On Mon, Dec 8, 2008 at 7:50 PM, Thomas Heide Clausen >>>> wrote: >>>> >>>> On Dec 8, 2008, at 18:58 PM, Dearlove, Christopher (UK) wrote: >>>> >>>> >>>> Your point about hierarchical addressing is interesting, and I >>>> think >>>> it relates to comments others have made on fisheye routing and >>>> other >>>> state suppression approaches. >>>> >>>> Not quite. Hierarchical allocation is indeed a state suppression >>>> approach. However fisheye is a control message suppression >>>> approach. >>>> >>>> >>>> And, it should be added that such are, of course complementing >>>> each other. >>>> >>>> Thomas >>>> >>>> >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>>> >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>> >> > --Apple-Mail-10--727889819 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi JP,

On Dec 9, 2008, at 15:43 PM, JP Vasseur = wrote:

Hi Thomas,

On Dec 9, 2008, at 12:51 PM, = Thomas Heide Clausen wrote:

Hi JP and = all,

A quick comment/question = below....

On Dec 9, 2008, at 11:48 = AM, JP Vasseur wrote:

Hi = Emmanuel,

I will let the authors of the draft answer = the excellent comments that have been raised on the list during WG LC = (and I'll add mine) but I would like to comment on your statement and = hopefully clarify our objective.

On Dec 9, 2008, = at 10:02 AM, Emmanuel Baccelli wrote:

Hi = all,

I think this draft is far from being ready = to become an RFC, and such for several reasons, some of which are, = unfortunately, structural.

1 - The draft is = evaluating moving targets such as OLSRv2, Dymo, NHDP, which are = potential solutions that are not finalized yet. These protocols could = meet more requirements in the end (maybe all of them?). For this reason, = the "pass/fail" table of section 5 cannot honestly list anything else = but a series of "question marks" (or "pass"), for now, for these = protocols. This makes this table rather useless, and thus this whole = draft rather useless, = presently.

NO. Let me = clarify something really important.

The WG = cannot afford to wait until all protocols are finalized to get a routing = solution for LLN. The industry is waiting for a routing solution for = such networks and time is absolutely = critical.

Without = being contentious, this is as such a fair point: "industry is waiting = for a solution". An argument can be made that in that case "starting = from scratch" would be counter-productive, and that it'd be beneficial = to start from something already in existence, or already in development, = if at all possible -- with the "already in development" being an asset = as it gives a head start and, potentially, can accommodate the ROLL wg = suggestions still.=A0

I deduct, therefore, that = the intent is to next analyze in detail the potential "tweaks and = tunings and potential extensions" possible to the existing six or so = protocols in the = roll-protocols-survey-02?


Agreeing with your = statement.=A0

If we can find an existing = solution, adapt it and make it work, that would be by far the preferred = path to = take.=A0


So = far so good -- it seems sensible to explore = that.

Two = comments though:
1) We all know that we can adapt lots of = protocols to meet a set of requirements but we also need to make sure = that we do not end up with a protocol with lots of features that we will = not use and that will require extra memory, CPU, ... We are running on = highly constrained environments with very limited = resources.

No objections to = this.

2) Many of = the active ROLL WG members participants have real world experience, thus = we do not start "from scratch" per say, and we could leverage some of = the experience learnt from deployed proprietary protocols. We will *no* = embrace an existing=A0proprietary=A0protocol but we can learn lessons = from deployed = networks.

Just to clarify, = I did not intend to dismiss the experience of the participants in the = ROLL wg, and my references to "from scratch" referred only to "IETF = heritage" =A0-- if you catch my drift.

To = summarize:
1) Extensive work has been done on the = requirements front for 4 identified use cases,
2) Before = starting any protocol work, we had to answer to the following question: = "Can we find an existing protocol that meets our requirements ?". The = answer to this question is "no", which does not mean that we could not = adapt an existing routing protocol (!). I think that we have a consensus = here, otherwise let us know.
Note that we will not continue to = work on this ID (hence the WG LC), the aim of which was to answer the = question above.

This, I am = not in agreement with at all.=A0

As I indicated = in my long email, the survey I-D is focusing narrowly on some (easily = quantified) metrics, but ignoring others.=A0

For = example "control cost" is included, but "path cost" is not -- and one = may in this case trade off one for another. The cited example = (zero-control-cost, flood all data) was in jest, but there *are* = protocols that trade off path lengths for lower control cost - and = vice-versa.

Note that this is a single example = only, I've identified others in other emails, and I shan't rehash it all = here.

The point is, that making potentially = constraining recommendations based on an incomplete set of = non-independent evaluation metrics isn't a good starting point for the = =A0wg -- rechartering (as you indicate below) or = otherwise.

I'd like to suggest that the authors = of the survey I-D take on board the comments produced thus far, and = complemented by the evaluation metrics otherwise = indicated.

As such, I respectfully join = Emmanuel Baccelli in suggesting that the document is not ready for = publication = (yet).

Thomas


3) The next step is to see whether = (1) we can adapt an existing routing protocol with the help of the WG = "owning" these protocols or (2) design a new routing protocol (in ROLL). = For this we need to recharter. And we should explore both paths = in=A0parallel.=A0

Does that make sense = ?

Many = Thanks.

JP.


=A0No we have to analyze the state of the art as of = today.

2 - The ROLL charter mentions = that "=A0Existing IGPs, MANET,=A0NEMO, DTN routing protocols will be = part of evaluation." I did not see anything mentioned about DTN = protocols, or Nemo in the draft, not even a justification why they are = not mentioned.
=


Would you want to = make a contribution ?

3 = - The draft is not constructive in its current shape. =

I do not think that your = comment is fair. The draft has been discussed in the WG for quite some = time and extensive discussion took place during the interim WG and on = the ML.

It = is on the other hand extremely controversial with its judgement, and = does not reflect a consensus within the community, not even a rough = one.


Bear = with us: we are not *judging* protocols: we are evaluating the existing = routing protocols *in light* of our specific requirements. Yes one can = argue for ever on a pass/fail criteria but we have to be driven by rough = consensus to be able to move forward. Of course, if there is a mistake = when evaluating a protocol it has to be = fixed.=A0

Thanks.

JP.
Emmanuel


On Mon, Dec 8, 2008 at 7:50 PM, Thomas Heide = Clausen <ietf@thomasclausen.org> = wrote:

On Dec 8, 2008, at 18:58 PM, Dearlove, Christopher = (UK) wrote:


Your point about hierarchical addressing is = interesting, and I think
it relates to comments others have made on = fisheye routing and other
state suppression approaches.
=

Not quite. Hierarchical allocation is indeed a state = suppression
approach. However fisheye is a control message = suppression approach.


And, it should = be added that such are, of course complementing each other.

Thomas


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

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




= --Apple-Mail-10--727889819-- --===============0735451529== 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 --===============0735451529==-- From roll-bounces@ietf.org Tue Dec 9 07:04:31 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D120528C16C; Tue, 9 Dec 2008 07:04:31 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B9BC28C17B for ; Tue, 9 Dec 2008 07:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 AN+GMwvprW-K for ; Tue, 9 Dec 2008 07:04:30 -0800 (PST) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 66FED28C16B for ; Tue, 9 Dec 2008 07:04:30 -0800 (PST) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mB9F4M9U026928 for ; Tue, 9 Dec 2008 15:04:22 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mB9F4LR9015432 for ; Tue, 9 Dec 2008 15:04:21 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 09 Dec 2008 15:03:55 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Tue, 9 Dec 2008 15:03:54 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 9 Dec 2008 15:03:54 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Working Group LastCall:draft-ietf-roll-protocols-survey-02 Thread-Index: AclaDecpVS6R5cs/TA+ckuZYghzkkQAAHB1w References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com><374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com><7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> From: "Dearlove, Christopher (UK)" To: "JP Vasseur" , "Emmanuel Baccelli" X-OriginalArrivalTime: 09 Dec 2008 15:03:54.0529 (UTC) FILETIME=[5A736110:01C95A0F] Cc: roll@ietf.org Subject: Re: [Roll] Working Group LastCall:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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 > 2- There is clearly a need for a solution *today*: look at all other > (deployed) non IP solutions out there > 4- We are not talking about a "dream protocol": again this is very > much realistic since solutions do exist today (not IP unfortunately :-( ....) Can you point me to an existing (doesn't have to be IP) protocol that passes all five of the ID's tests, without some major drawback in some other area. I for one would find it interesting and useful. (Obviously it would have to have a specification, not just a claim made about a proprietary protocol.) If one or more such protocols exist, I don't see why they aren't discussed at this stage. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Dec 9 07:07:29 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4FEB28C138; Tue, 9 Dec 2008 07:07:29 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B67E928C138 for ; Tue, 9 Dec 2008 07:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJpr8DQX-7EF for ; Tue, 9 Dec 2008 07:07:28 -0800 (PST) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id 9178128C114 for ; Tue, 9 Dec 2008 07:07:28 -0800 (PST) Received: from aste-genev-bois-153-1-11-44.w83-112.abo.wanadoo.fr ([83.112.73.44] helo=[192.168.147.109]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LA4BG-000Bve-Db; Tue, 09 Dec 2008 15:07:22 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 83.112.73.44 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19uIR88Kz2ku+gHjnn3eGWA In-Reply-To: References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Thomas Heide Clausen Date: Tue, 9 Dec 2008 16:07:36 +0100 To: JP Vasseur X-Mailer: Apple Mail (2.753.1) Cc: Emmanuel Baccelli , roll@ietf.org Subject: Re: [Roll] Working Group Last Call:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi JP, Posting on a 'list, you run the risk that not just Baccelli respond. See below. On Dec 9, 2008, at 15:53 PM, JP Vasseur wrote: >> >>> 3 - The draft is not constructive in its current shape. >> >> I do not think that your comment is fair. The draft has been >> discussed in the WG for quite some time and extensive discussion >> took place during the interim WG and on the ML. >> >> >> Yes there have been some discussions, but there is no consensus on >> the approach taken by this document. > > Thanks for your feed-back here. What do you propose ? > >> And there is no rough consensus either. >> > > Please refer to the WG minutes + several emails on the ML, with a > good consensus. That being said, I hear you and thanks for your > comments. I do register your disagreement. Having read again > others' email, I do not think that this is a general feeling. > At this point, I think it fair to raise that in Minneapolis, ROLL and AUTOCONF were concurrently scheduled, and that for that reason large part of the community (myself included) were unable to attend ROLL. If scheduling would have permitted, I would have attended, and I would have made my concerns be known at the mike (and, hopefully, have had those reflected in the minutes as well). Looking back over the mailing list postings, I also see a number of concerns raised by a number of people -- all of whom I know to have some experience designing/building/deploying protocols in a space similar or identical to ROLL. So, I do not share the view expressed in your last paragraph above. Thomas _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Dec 9 07:13:25 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E763A684F; Tue, 9 Dec 2008 07:13:25 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5657E3A684F for ; Tue, 9 Dec 2008 07:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.54 X-Spam-Level: X-Spam-Status: No, score=-10.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFd4oVTPwI32 for ; Tue, 9 Dec 2008 07:13:23 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 00C833A67AA for ; Tue, 9 Dec 2008 07:13:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,741,1220227200"; d="scan'208";a="28118291" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Dec 2008 15:13:16 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mB9FDGaU022404; Tue, 9 Dec 2008 16:13:16 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mB9FDG3s020473; Tue, 9 Dec 2008 15:13:16 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Dec 2008 16:13:16 +0100 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Dec 2008 16:13:15 +0100 Message-Id: From: JP Vasseur To: "Dearlove, Christopher (UK)" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 9 Dec 2008 16:13:14 +0100 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com><374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com><7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 09 Dec 2008 15:13:15.0364 (UTC) FILETIME=[A8BC0240:01C95A10] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1568; t=1228835596; x=1229699596; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Working=20Group=20LastCall=3Ad raft-ietf-roll-protocols-survey-02 |Sender:=20; bh=vz0WHSLnVzL53Gk5CD1hZuaVHhJe+zyERph9mxQU4eQ=; b=QmG8TSLnKPIsWKPWWJA16WBaPh/8sHhxlQCMmI0fmoKyprdUzmRTXKMzTg sUPBriGnoaOfpBaEnWvlbBAgjxU4q+h2aAIG1nKDFsD9GXSC1vs7mEhiRVTg Tddrdxd8BQ; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Emmanuel Baccelli , roll@ietf.org Subject: Re: [Roll] Working Group LastCall:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Dec 9, 2008, at 4:03 PM, Dearlove, Christopher (UK) wrote: > >> 2- There is clearly a need for a solution *today*: look at all other >> (deployed) non IP solutions out there > >> 4- We are not talking about a "dream protocol": again this is very >> much realistic since solutions do exist today (not IP unfortunately > :-( ....) > > Can you point me to an existing (doesn't have to be IP) protocol > that passes all five of the ID's tests, without some major drawback > in some other area. I for one would find it interesting and useful. > (Obviously it would have to have a specification, not just a claim > made about a proprietary protocol.) You missed my point ... I did not say that there were any of them satisfying these criterion. But clearly there are non IP solutions being deployed, my point being that we need an IP solution soon and we should make it right. > > > If one or more such protocols exist, I don't see why they aren't > discussed at this stage. I do not think that it is in our charter to analyze *all* possible protocols. > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Dec 9 07:20:48 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8622D3A6B1E; Tue, 9 Dec 2008 07:20:48 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C11653A6B1E for ; Tue, 9 Dec 2008 07:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mf2qXYbps+ts for ; Tue, 9 Dec 2008 07:20:47 -0800 (PST) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id F040C3A68F1 for ; Tue, 9 Dec 2008 07:20:46 -0800 (PST) Received: from aste-genev-bois-153-1-11-44.w83-112.abo.wanadoo.fr ([83.112.73.44] helo=[192.168.147.109]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LA4O7-000Fu7-Lp; Tue, 09 Dec 2008 15:20:39 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 83.112.73.44 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+TNiEzisE7mnKxv8Y/b18j In-Reply-To: References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <61D43925-D96D-41A0-A73B-E87B586245E3@thomasclausen.org> From: Thomas Heide Clausen Date: Tue, 9 Dec 2008 16:20:53 +0100 To: JP Vasseur X-Mailer: Apple Mail (2.753.1) Cc: "Dearlove, Christopher \(UK\)" , Emmanuel Baccelli , roll@ietf.org Subject: Re: [Roll] Working Group LastCall:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Dec 9, 2008, at 16:13 PM, JP Vasseur wrote: > > On Dec 9, 2008, at 4:03 PM, Dearlove, Christopher (UK) wrote: > >> >>> 2- There is clearly a need for a solution *today*: look at all other >>> (deployed) non IP solutions out there >> >>> 4- We are not talking about a "dream protocol": again this is very >>> much realistic since solutions do exist today (not IP unfortunately >> :-( ....) >> >> Can you point me to an existing (doesn't have to be IP) protocol >> that passes all five of the ID's tests, without some major drawback >> in some other area. I for one would find it interesting and useful. >> (Obviously it would have to have a specification, not just a claim >> made about a proprietary protocol.) > > You missed my point ... I did not say that there were any of them > satisfying these criterion. > But clearly there are non IP solutions being deployed, my point > being that we need an > IP solution soon and we should make it right. I read Chris Dearlove as asking for something concrete, justifying that these five "criteria" that the survey I-D sets out are *attainable* (and without some major drawbacks on the other important metrics that the survey I-D is ignoring) and that we're not chasing a "pie in the sky". >> If one or more such protocols exist, I don't see why they aren't >> discussed at this stage. > > I do not think that it is in our charter to analyze *all* possible > protocols. No, but if a good such protocol indeed existed, IP or not, having it before us might just help quell skepticism. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Dec 9 07:20:57 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF70628C17B; Tue, 9 Dec 2008 07:20:57 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AB3328C17B for ; Tue, 9 Dec 2008 07:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.481 X-Spam-Level: X-Spam-Status: No, score=-6.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 tjAJ5SZIfYeR for ; Tue, 9 Dec 2008 07:20:56 -0800 (PST) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id A102628C173 for ; Tue, 9 Dec 2008 07:20:55 -0800 (PST) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mB9FKmAw003975 for ; Tue, 9 Dec 2008 15:20:48 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mB9FKlTg025983 for ; Tue, 9 Dec 2008 15:20:47 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 09 Dec 2008 15:20:48 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Tue, 9 Dec 2008 15:20:48 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 9 Dec 2008 15:20:48 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Working Group LastCall:draft-ietf-roll-protocols-survey-02 Thread-Index: AclaELAGkI38Q5q5TBmcpXp1O9ofowAAFyzg References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com><374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com><7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> From: "Dearlove, Christopher (UK)" To: "JP Vasseur" X-OriginalArrivalTime: 09 Dec 2008 15:20:48.0121 (UTC) FILETIME=[B6993E90:01C95A11] Cc: Emmanuel Baccelli , roll@ietf.org Subject: Re: [Roll] Working Group LastCall:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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 >>> 2- There is clearly a need for a solution *today*: look at all other >>> (deployed) non IP solutions out there > >>> 4- We are not talking about a "dream protocol": again this is very >>> much realistic since solutions do exist today (not IP unfortunately >>> :-( ....) > >> Can you point me to an existing (doesn't have to be IP) protocol >> that passes all five of the ID's tests, without some major drawback >> in some other area. > You missed my point ... I did not say that there were any of them > satisfying these criterion. If you don't have a solution that meets your criteria, then imposing your criteria (plus other essential criteria) might (I put it no stronger than that) be requiring a "dream protocol". ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Dec 9 07:30:37 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30E43A6B31; Tue, 9 Dec 2008 07:30:37 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4441B28C17B for ; Tue, 9 Dec 2008 07:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.544 X-Spam-Level: X-Spam-Status: No, score=-10.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nu0YkssoJff2 for ; Tue, 9 Dec 2008 07:30:35 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0E6223A68F1 for ; Tue, 9 Dec 2008 07:30:34 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,741,1220227200"; d="scan'208,217";a="28120643" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 09 Dec 2008 15:30:17 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mB9FUHET001963; Tue, 9 Dec 2008 16:30:17 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mB9FUHEl026439; Tue, 9 Dec 2008 15:30:17 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Dec 2008 16:30:17 +0100 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Dec 2008 16:30:16 +0100 Message-Id: <3CEA849E-22CD-4DF1-A56B-E1C38572AA77@cisco.com> From: JP Vasseur To: Thomas Heide Clausen , Philip Levis , arsalan@eecs.berkeley.edu, stevedh@eecs.berkeley.edu In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 9 Dec 2008 16:30:15 +0100 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 09 Dec 2008 15:30:16.0542 (UTC) FILETIME=[096767E0:01C95A13] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10976; t=1228836617; x=1229700617; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Working=20Group=20Last=09Call= 3Adraft-ietf-roll-protocols-survey-02 |Sender:=20; bh=azXDcQqs/sSvh8YAVauIpL+5YgtAqeSufZwtwVJXgjU=; b=g+cEZvQw/E+gaWA1V49Vs+zGSGdsxUm3JS6xVuSMzg/l3WMbbH9Q+kwx+X Ah20dnhRFXr4j6mHq7Z87f370HhBIrRF63iIOO/Os0lKmbHeDV+l4BavA1ZE OPJBQOwDrE; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Emmanuel Baccelli , roll@ietf.org Subject: Re: [Roll] Working Group Last Call:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============0329441262==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0329441262== Content-Type: multipart/alternative; boundary=Apple-Mail-40--726171142 --Apple-Mail-40--726171142 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On Dec 9, 2008, at 4:07 PM, Thomas Heide Clausen wrote: > Hi JP, > > Posting on a 'list, you run the risk that not just Baccelli respond. Which is fine, the IETF is open ;-) In line, > See below. > > On Dec 9, 2008, at 15:53 PM, JP Vasseur wrote: > > > >>> >>>> 3 - The draft is not constructive in its current shape. >>> >>> I do not think that your comment is fair. The draft has been >>> discussed in the WG for quite some time and extensive discussion >>> took place during the interim WG and on the ML. >>> >>> >>> Yes there have been some discussions, but there is no consensus on >>> the approach taken by this document. >> >> Thanks for your feed-back here. What do you propose ? >> >>> And there is no rough consensus either. >>> >> >> Please refer to the WG minutes + several emails on the ML, with a >> good consensus. That being said, I hear you and thanks for your >> comments. I do register your disagreement. Having read again >> others' email, I do not think that this is a general feeling. >> > > At this point, I think it fair to raise that in Minneapolis, ROLL > and AUTOCONF were concurrently scheduled, and that for that reason > large part of the community (myself included) were unable to attend > ROLL. > > If scheduling would have permitted, I would have attended, and I > would have made my concerns be known at the mike (and, hopefully, > have had those reflected in the minutes as well). Well, the ID was discussed in Dublin, San Jose (interim WG meeting with dial-in) and in Minneapolis. Extract of the minutes: * San Francisco * ... Subject: [Roll] Minutes of the Interim ROLL Working Group Meeting *and* WG consensus on the protocol survey conclusion Dear WG, Please find below the minutes of the ROLL Interim Working Group meeting that was help in San Jose on Oct 6. This was an excellent very productive meeting where we managed to make good progress and reached a consensus on an important question related to a key Milestone.As usual such consensus must be confirmed on the mailing list. When ROLL got chartered, one of our key milestones was to determined after some careful analysis of the routing requirements whether or not we could find an existing protocols that would meet our routing requirement with no change (with no protocol changes). All participants to the interim meeting agreed that there was no existing protocol that would meet the ROLL routing requirements *with no protocol work*. Do not hesitate to express your opinion on the mailing list before Oct 17 and then we will document the WG decision. * Minneapolis * ... 3) Update of the Interim WG ROLL Meeting in San Jose (Chairs - 5mn) [15] JP> Update on ROLL interim meeting held Oct. 2008. The meeting was devoted to discussing protocol survey document and consensus reached subsequently on mailing list that no existing protocol would meet ROLL requirements JP (to the room)> You can still comment if you disagree. Anybody disagreeing ? No comment from the room. ... *but* let's go back to a more constructive track ... what matters is to move forward and make sure that we move ahead. > > > Looking back over the mailing list postings, I also see a number of > concerns raised by a number of people -- all of whom I know to have > some experience designing/building/deploying protocols in a space > similar or identical to ROLL. > > So, I do not share the view expressed in your last paragraph above. Hopefully I clarified the WG's objectives (WG co-chair hat on). Now you expressed concerns and we do have to address them. May I ask to the authors of the ID to take one point at a time to answer them ? Thanks. JP. > > > Thomas > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-40--726171142 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi,

On Dec 9, = 2008, at 4:07 PM, Thomas Heide Clausen wrote:

Hi = JP,

Posting on a 'list, you run the risk that not just Baccelli = respond.

Which is fine, the IETF = is open ;-)

In line,

See below.

On Dec 9, 2008, at 15:53 PM, JP = Vasseur wrote:

<SNIP>


3 - = The draft is not constructive in its current = shape.

I do not think that your comment = is fair. The draft has been discussed in the WG for quite some time and = extensive discussion took place during the interim WG and on the = ML.


Yes there have been some = discussions, but there is no consensus on the approach taken by this = document.

Thanks for your = feed-back here. What do you propose ?

And there is no rough consensus = either.


Please refer to = the WG minutes + several emails on the ML, with a good consensus. That = being said, I hear you and thanks for your comments. I do register your = disagreement. Having read again others' email, I do not think that this = is a general feeling.


At this point, I think it fair to = raise that in Minneapolis, ROLL and AUTOCONF were concurrently = scheduled, and that for that reason  large part of the community = (myself included) were unable to attend ROLL.

If scheduling would = have permitted, I would have attended, and I would have made my concerns = be known at the mike (and, hopefully, have had those reflected in the = minutes as well).

Well, the ID was = discussed in Dublin, San Jose (interim WG meeting with dial-in) and in = Minneapolis.

Extract of the = minutes:

* San Francisco = *
...

[Roll] Minutes of the Interim = ROLL Working Group Meeting *and* WG consensus on the protocol survey = conclusion


Dear = WG,

Please find below the minutes of the ROLL Interim Working = Group meeting that was help in San Jose on Oct 6. 

This was = an excellent very productive meeting where we managed to make good = progress and reached a consensus on an important question related to a = key Milestone.As usual such consensus must be confirmed on the mailing = list.  

When ROLL got chartered, one of our key milestones = was to determined after some careful analysis of the routing = requirements whether or not we could find an existing protocols that = would meet our routing requirement with no change (with no protocol = changes). All participants to the interim meeting agreed that there was = no existing protocol that would meet the ROLL routing requirements *with = no protocol work*. Do not hesitate to express your opinion on the = mailing list before Oct 17 and then we will document the WG = decision.

=
* Minneapolis *
...
3) = Update of the Interim WG ROLL Meeting in San Jose (Chairs - 5mn) = [15]

JP> Update on ROLL interim = meeting held Oct. 2008.
The meeting was devoted to = discussing protocol survey document and consensus reached subsequently = on mailing list that no existing protocol would meet ROLL = requirements
JP (to the room)> You can still comment if = you disagree. Anybody disagreeing ?
No comment from the = room.
...

*but* let's go back = to a more constructive track ... what matters is to move forward and = make sure that we move ahead.



Looking back over the mailing list postings, = I also see a number of concerns raised by a number of people -- all of = whom I know to have some experience designing/building/deploying = protocols in a space similar or identical to ROLL.

So, I do not = share the view expressed in your last paragraph = above.

Hopefully I clarified the = WG's objectives (WG co-chair hat on).

Now you = expressed concerns and we do have to address = them. 

May I ask to the authors of the ID = to take one point at a time to answer them = ?

Thanks.

JP.

<= blockquote = type=3D"cite">


Thomas

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

= --Apple-Mail-40--726171142-- --===============0329441262== 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 --===============0329441262==-- From roll-bounces@ietf.org Tue Dec 9 07:38:47 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5844128C17B; Tue, 9 Dec 2008 07:38:47 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D3353A6968 for ; Tue, 9 Dec 2008 07:38:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gv0i8sngkaou for ; Tue, 9 Dec 2008 07:38:45 -0800 (PST) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id 8238C28C17B for ; Tue, 9 Dec 2008 07:38:45 -0800 (PST) Received: from aste-genev-bois-153-1-11-44.w83-112.abo.wanadoo.fr ([83.112.73.44] helo=[192.168.147.109]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LA4fS-000Lh4-PS; Tue, 09 Dec 2008 15:38:35 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 83.112.73.44 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+MUZPUSffmjURRKr3KsgBu In-Reply-To: <3CEA849E-22CD-4DF1-A56B-E1C38572AA77@cisco.com> References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> <3CEA849E-22CD-4DF1-A56B-E1C38572AA77@cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Thomas Heide Clausen Date: Tue, 9 Dec 2008 16:38:46 +0100 To: JP Vasseur X-Mailer: Apple Mail (2.753.1) Cc: Emmanuel Baccelli , roll@ietf.org, arsalan@eecs.berkeley.edu Subject: Re: [Roll] Working Group Last Call:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org JP, All, On Dec 9, 2008, at 16:30 PM, JP Vasseur wrote: > > Hopefully I clarified the WG's objectives (WG co-chair hat on). > Yes indeed, thanks. > Now you expressed concerns and we do have to address them. > > May I ask to the authors of the ID to take one point at a time to > answer them ? Thanks, I appreciate that. I'll be happy to discuss/clarify my concerns further if/when the authors may deem it needed, and review updates as they occur. Cheers, Thomas _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Dec 9 08:45:54 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 958443A6916; Tue, 9 Dec 2008 08:45:54 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EFCD3A6916 for ; Tue, 9 Dec 2008 08:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.394 X-Spam-Level: X-Spam-Status: No, score=-10.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VU95LeiD8XV2 for ; Tue, 9 Dec 2008 08:45:52 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DF47F3A67FC for ; Tue, 9 Dec 2008 08:45:51 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,741,1220227200"; d="scan'208";a="28131737" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Dec 2008 16:45:45 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mB9Gjjqa022565; Tue, 9 Dec 2008 17:45:45 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mB9GjjKx024202; Tue, 9 Dec 2008 16:45:45 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); Tue, 9 Dec 2008 17:45:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 9 Dec 2008 17:45:39 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC06ADE328@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Working GroupLast Call:draft-ietf-roll-protocols-survey-02 Thread-Index: AclaD+Bu1Iu7rypcTh2KcrhYCLuk2AADDgzQ References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com><374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com><7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> From: "Pascal Thubert (pthubert)" To: "Thomas Heide Clausen" , "JP Vasseur (jvasseur)" X-OriginalArrivalTime: 09 Dec 2008 16:45:45.0146 (UTC) FILETIME=[94A989A0:01C95A1D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2961; t=1228841145; x=1229705145; 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]=20Working=20GroupLast=09Call=3Ad raft-ietf-roll-protocols-survey-02 |Sender:=20; bh=6AnD6yCrZvgHhZXDBIenZQCPBDU9/LZWIbE6zwrvVw0=; b=Nm1ZwhvL2vM/+nq0FeU6PDOznsgudqXQ15qp0GE2mtTG50IZW4TXaDEsk2 EC6j7cfaAkkiPzhcQGxII2MoCip0Bx8zPM/Gx6LzVc4FA08sw7FReSrzRw2Q Ukq2oL+wAZ; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Emmanuel Baccelli , roll@ietf.org Subject: Re: [Roll] Working GroupLast Call:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi all: Having attended the interim, I can concur that there was a clear consensus = in the room and through the teleconf. The interim was not as crowded as the= previous IETF meeting, yet there were more people there who raised their h= ands in favor than there are in a normal meeting considering all the non-vo= ters in the room. To me that was a clear consensus, better than many I've s= een. = ROLL provides a niche where we can develop a simple and efficient mechanism= that might not have all the power and goodies of the bigger brothers but w= ould fit in a constrained device and do the minimum needed. The project mig= ht fail anyway if what we really want is a dream protocol, but it is certai= n to fail if we do not try. If enough people are willing to help, let's giv= e ROLL a chance. Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Th= omas Heide Clausen >Sent: mardi 9 d=E9cembre 2008 16:08 >To: JP Vasseur (jvasseur) >Cc: Emmanuel Baccelli; roll@ietf.org >Subject: Re: [Roll] Working GroupLast Call:draft-ietf-roll-protocols-surve= y-02 > >Hi JP, > >Posting on a 'list, you run the risk that not just Baccelli respond. >See below. > >On Dec 9, 2008, at 15:53 PM, JP Vasseur wrote: > > > >>> >>>> 3 - The draft is not constructive in its current shape. >>> >>> I do not think that your comment is fair. The draft has been >>> discussed in the WG for quite some time and extensive discussion >>> took place during the interim WG and on the ML. >>> >>> >>> Yes there have been some discussions, but there is no consensus on >>> the approach taken by this document. >> >> Thanks for your feed-back here. What do you propose ? >> >>> And there is no rough consensus either. >>> >> >> Please refer to the WG minutes + several emails on the ML, with a >> good consensus. That being said, I hear you and thanks for your >> comments. I do register your disagreement. Having read again >> others' email, I do not think that this is a general feeling. >> > >At this point, I think it fair to raise that in Minneapolis, ROLL and >AUTOCONF were concurrently scheduled, and that for that reason large >part of the community (myself included) were unable to attend ROLL. > >If scheduling would have permitted, I would have attended, and I >would have made my concerns be known at the mike (and, hopefully, >have had those reflected in the minutes as well). > >Looking back over the mailing list postings, I also see a number of >concerns raised by a number of people -- all of whom I know to have >some experience designing/building/deploying protocols in a space >similar or identical to ROLL. > >So, I do not share the view expressed in your last paragraph above. > >Thomas > >_______________________________________________ >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 Dec 9 09:03:06 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 598D03A6B08; Tue, 9 Dec 2008 09:03:06 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FAB83A6B27 for ; Tue, 9 Dec 2008 09:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxQQuPk-1hwc for ; Tue, 9 Dec 2008 09:03:04 -0800 (PST) Received: from cpmx2.mail.saic.com (cpmx2.mail.saic.com [139.121.17.172]) by core3.amsl.com (Postfix) with ESMTP id 4A5ED3A6B24 for ; Tue, 9 Dec 2008 09:03:03 -0800 (PST) Received: from 0461-ITS-SMS01 ([139.121.21.144] [139.121.21.144]) by cpmx2.mail.saic.com with ESMTP id BT-MMP-2161072; Tue, 9 Dec 2008 09:02:27 -0800 X-AuditID: 8b79118c-ab070ba000001bc9-2b-493ea4a3b80b Received: from 0599-its-exbh01.us.saic.com (unknown [139.121.21.144]) by 0461-ITS-SMS01 (Symantec Mail Security) with ESMTP id 0967D30811C; Tue, 9 Dec 2008 09:02:27 -0800 (PST) Received: from 0461-its-exmb01.us.saic.com ([10.8.67.21]) by 0599-its-exbh01.us.saic.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Dec 2008 09:02:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 9 Dec 2008 09:02:26 -0800 Message-Id: <6532E5AE1BD6FF4B989254190D6FF15102942BBB@0461-its-exmb01.us.saic.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Working Group LastCall:draft-ietf-roll-protocols-survey-02 Thread-Index: AclZ3O2n1UxiWMGeQme/0I2pZe9g5AAQmRpA References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com><374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com><7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> From: "Childress, Steve" To: "Emmanuel Baccelli" , X-OriginalArrivalTime: 09 Dec 2008 17:02:27.0073 (UTC) FILETIME=[E9DB7710:01C95A1F] X-Brightmail-Tracker: AAAAAA== Cc: charliep@computer.org, Thomas Heide Clausen , arsalan@eecs.berkeley.edu Subject: Re: [Roll] Working Group LastCall:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============1392708691==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============1392708691== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C95A1F.E97CFC5A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C95A1F.E97CFC5A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Have you folks previously considered SRI's TBRPF for mesh routing? =20 Steve Childress steve.childress@saic.com =20 ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Emmanuel Baccelli Sent: Tuesday, December 09, 2008 1:02 AM To: roll@ietf.org Cc: charliep@computer.org; Thomas Heide Clausen; arsalan@eecs.berkeley.edu Subject: Re: [Roll] Working Group LastCall:draft-ietf-roll-protocols-survey-02 Hi all, I think this draft is far from being ready to become an RFC, and such for several reasons, some of which are, unfortunately, structural. 1 - The draft is evaluating moving targets such as OLSRv2, Dymo, NHDP, which are potential solutions that are not finalized yet. These protocols could meet more requirements in the end (maybe all of them?). For this reason, the "pass/fail" table of section 5 cannot honestly list anything else but a series of "question marks" (or "pass"), for now, for these protocols. This makes this table rather useless, and thus this whole draft rather useless, presently. 2 - The ROLL charter mentions that " Existing IGPs, MANET, NEMO, DTN routing protocols will be part of evaluation." I did not see anything mentioned about DTN protocols, or Nemo in the draft, not even a justification why they are not mentioned. 3 - The draft is not constructive in its current shape. It is on the other hand extremely controversial with its judgement, and does not reflect a consensus within the community, not even a rough one. Emmanuel On Mon, Dec 8, 2008 at 7:50 PM, Thomas Heide Clausen wrote: On Dec 8, 2008, at 18:58 PM, Dearlove, Christopher (UK) wrote: =09 =09 Your point about hierarchical addressing is interesting, and I think it relates to comments others have made on fisheye routing and other state suppression approaches. =09 Not quite. Hierarchical allocation is indeed a state suppression approach. However fisheye is a control message suppression approach. =09 =09 And, it should be added that such are, of course complementing each other. =09 Thomas=20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =09 ------_=_NextPart_001_01C95A1F.E97CFC5A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Have you folks previously considered SRI's = TBRPF for=20 mesh routing?
 
Steve Childress
steve.childress@saic.com
 

From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On Behalf Of Emmanuel=20 Baccelli
Sent: Tuesday, December 09, 2008 1:02 = AM
To:=20 roll@ietf.org
Cc: charliep@computer.org; Thomas Heide Clausen; = arsalan@eecs.berkeley.edu
Subject: Re: [Roll] Working Group=20 LastCall:draft-ietf-roll-protocols-survey-02

Hi all,

I think this draft is far from being ready to become an RFC, and = such for=20 several reasons, some of which are, unfortunately, structural.

1 - The draft is evaluating moving targets such as OLSRv2, Dymo, = NHDP,=20 which are potential solutions that are not finalized yet. These = protocols could=20 meet more requirements in the end (maybe all of them?). For this reason, = the=20 "pass/fail" table of section 5 cannot honestly list anything else but a = series=20 of "question marks" (or "pass"), for now, for these protocols. This = makes this=20 table rather useless, and thus this whole draft rather useless, = presently.

2 - The ROLL charter mentions that " Existing IGPs, = MANET, NEMO,=20 DTN routing protocols will be part of evaluation." I did not see = anything=20 mentioned about DTN protocols, or Nemo in the draft, not even a = justification=20 why they are not mentioned.

3 - The draft is not constructive in its current shape. It is on = the other=20 hand extremely controversial with its judgement, and does not reflect a=20 consensus within the community, not even a rough one.

Emmanuel


On Mon, Dec 8, 2008 at 7:50 PM, Thomas Heide = Clausen=20 <ietf@thomasclausen.org>=20 wrote:

On Dec 8, 2008, at 18:58 PM, Dearlove, = Christopher (UK)=20 wrote:


Your=20 point about hierarchical addressing is interesting, and I = think
it=20 relates to comments others have made on fisheye routing and = other
state=20 suppression approaches.

Not quite. = Hierarchical=20 allocation is indeed a state suppression
approach. However = fisheye is a=20 control message suppression = approach.


And, it=20 should be added that such are, of course complementing each = other.

Thomas


_______________________________________________Roll=20 mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
<= /DIV>

------_=_NextPart_001_01C95A1F.E97CFC5A-- --===============1392708691== 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 --===============1392708691==-- From roll-bounces@ietf.org Tue Dec 9 09:16:42 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C1983A6B11; Tue, 9 Dec 2008 09:16:42 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8412E3A67E9 for ; Tue, 9 Dec 2008 09:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufhvEasZVayf for ; Tue, 9 Dec 2008 09:16:40 -0800 (PST) Received: from mail-fx0-f19.google.com (mail-fx0-f19.google.com [209.85.220.19]) by core3.amsl.com (Postfix) with ESMTP id D598B3A68A2 for ; Tue, 9 Dec 2008 09:16:39 -0800 (PST) Received: by fxm12 with SMTP id 12so60905fxm.13 for ; Tue, 09 Dec 2008 09:16:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=x2yeOOACXi/+1zj1f1nLgoPnewOrU4RunAActD/yg6w=; b=fTy/YSL4NRC5AW9zgldUFZs3Ff5MaGJ8POceyXE0GCt/8xieqTS41pq33K4+GfwM6F lYDFksqNv9si1To3q+R0l+yH0X7HB0FTZ0/ARNM8maEEpLcF3YTfVcXZB6L9TEHTQPqe PqS3J19Wv9SNqAscJRmw7zLDYwpLt6KsaZR3k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=BBXAaZoBhK50qkGnbPqJKwSpovM6GFQydruKQqkislIyFSyNocpSxD2/6wGrAGIkOU /be1dkCfzySihx0Xbpi+YhAD1piuRgJATOyU8i2vSgmnQeTDNKyJWamJYNMMdMxwOAvE WrXLg4ZbtHagyvNSR4FtlWeg2tEEbO7VNOE2c= Received: by 10.103.102.17 with SMTP id e17mr143732mum.136.1228842993613; Tue, 09 Dec 2008 09:16:33 -0800 (PST) Received: by 10.103.248.12 with HTTP; Tue, 9 Dec 2008 09:16:33 -0800 (PST) Message-ID: Date: Tue, 9 Dec 2008 18:16:33 +0100 From: "Emmanuel Baccelli" To: roll@ietf.org In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC06ADE328@xmb-ams-337.emea.cisco.com> MIME-Version: 1.0 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> <7892795E1A87F04CADFCCF41FADD00FC06ADE328@xmb-ams-337.emea.cisco.com> X-Google-Sender-Auth: d446a2e55d9147b3 Subject: Re: [Roll] Working GroupLast Call:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============1211004101==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1211004101== Content-Type: multipart/alternative; boundary="----=_Part_68913_5391360.1228842993609" ------=_Part_68913_5391360.1228842993609 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Well I guess a lot of interested people could not attend the interim in California, and a lot of people could not attend the last ROLL meeting in Minneapolis either because Autoconf was scheduled simultaneously (which was really unfortunate, I hope it does not happen again).Emmanuel On Tue, Dec 9, 2008 at 5:45 PM, Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > Hi all: > > Having attended the interim, I can concur that there was a clear consensu= s > in the room and through the teleconf. The interim was not as crowded as t= he > previous IETF meeting, yet there were more people there who raised their > hands in favor than there are in a normal meeting considering all the > non-voters in the room. To me that was a clear consensus, better than man= y > I've seen. > > ROLL provides a niche where we can develop a simple and efficient mechani= sm > that might not have all the power and goodies of the bigger brothers but > would fit in a constrained device and do the minimum needed. The project > might fail anyway if what we really want is a dream protocol, but it is > certain to fail if we do not try. If enough people are willing to help, > let's give ROLL a chance. > > Pascal > > >-----Original Message----- > >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Thomas Heide Clausen > >Sent: mardi 9 d=E9cembre 2008 16:08 > >To: JP Vasseur (jvasseur) > >Cc: Emmanuel Baccelli; roll@ietf.org > >Subject: Re: [Roll] Working GroupLast > Call:draft-ietf-roll-protocols-survey-02 > > > >Hi JP, > > > >Posting on a 'list, you run the risk that not just Baccelli respond. > >See below. > > > >On Dec 9, 2008, at 15:53 PM, JP Vasseur wrote: > > > > > > > >>> > >>>> 3 - The draft is not constructive in its current shape. > >>> > >>> I do not think that your comment is fair. The draft has been > >>> discussed in the WG for quite some time and extensive discussion > >>> took place during the interim WG and on the ML. > >>> > >>> > >>> Yes there have been some discussions, but there is no consensus on > >>> the approach taken by this document. > >> > >> Thanks for your feed-back here. What do you propose ? > >> > >>> And there is no rough consensus either. > >>> > >> > >> Please refer to the WG minutes + several emails on the ML, with a > >> good consensus. That being said, I hear you and thanks for your > >> comments. I do register your disagreement. Having read again > >> others' email, I do not think that this is a general feeling. > >> > > > >At this point, I think it fair to raise that in Minneapolis, ROLL and > >AUTOCONF were concurrently scheduled, and that for that reason large > >part of the community (myself included) were unable to attend ROLL. > > > >If scheduling would have permitted, I would have attended, and I > >would have made my concerns be known at the mike (and, hopefully, > >have had those reflected in the minutes as well). > > > >Looking back over the mailing list postings, I also see a number of > >concerns raised by a number of people -- all of whom I know to have > >some experience designing/building/deploying protocols in a space > >similar or identical to ROLL. > > > >So, I do not share the view expressed in your last paragraph above. > > > >Thomas > > > >_______________________________________________ > >Roll mailing list > >Roll@ietf.org > >https://www.ietf.org/mailman/listinfo/roll > ------=_Part_68913_5391360.1228842993609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Well I guess a lot of interested people could not attend the interim in Cal= ifornia, and a lot of people could not attend the last ROLL meeting in Minn= eapolis either because Autoconf was scheduled simultaneously (whi= ch was really unfortunate, I hope it does not happen again).
Emmanuel

On Tue, Dec 9, 2008 at 5:45 PM, = Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
Hi all:

Having attended the interim, I can concur that there was a clear consensus = in the room and through the teleconf. The interim was not as crowded as the= previous IETF meeting, yet there were more people there who raised their h= ands in favor than there are in a normal meeting considering all the non-vo= ters in the room. To me that was a clear consensus, better than many I'= ve seen.

ROLL provides a niche where we can develop a simple and efficient mechanism= that might not have all the power and goodies of the bigger brothers but w= ould fit in a constrained device and do the minimum needed. The project mig= ht fail anyway if what we really want is a dream protocol, but it is certai= n to fail if we do not try. If enough people are willing to help, let's= give ROLL a chance.

Pascal

>-----Original Message-----
>From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Thomas Heide Clausen
>Sent: mardi 9 d=E9cembre 2008 16:08
>To: JP Vasseur (jvasseur)
>Cc: Emmanuel Baccelli; roll@ietf.org
>Subject: Re: [Roll] Working GroupLast Call:draft-ietf-roll-protocols-su= rvey-02
>
>Hi JP,
>
>Posting on a 'list, you run the risk that not just Baccelli respond= .
>See below.
>
>On Dec 9, 2008, at 15:53 PM, JP Vasseur wrote:
>
><SNIP>
>
>>>
>>>> 3 - The draft is not constructive in its current shape. >>>
>>> I do not think that your comment is fair. The draft has been >>> discussed in the WG for quite some time and extensive discussi= on
>>> took place during the interim WG and on the ML.
>>>
>>>
>>> Yes there have been some discussions, but there is no consensu= s on
>>> the approach taken by this document.
>>
>> Thanks for your feed-back here. What do you propose ?
>>
>>> And there is no rough consensus either.
>>>
>>
>> Please refer to the WG minutes + several emails on the ML, with a<= br> >> good consensus. That being said, I hear you and thanks for your >> comments. I do register your disagreement. Having read again
>> others' email, I do not think that this is a general feeling.<= br> >>
>
>At this point, I think it fair to raise that in Minneapolis, ROLL and >AUTOCONF were concurrently scheduled, and that for that reason  la= rge
>part of the community (myself included) were unable to attend ROLL.
>
>If scheduling would have permitted, I would have attended, and I
>would have made my concerns be known at the mike (and, hopefully,
>have had those reflected in the minutes as well).
>
>Looking back over the mailing list postings, I also see a number of
>concerns raised by a number of people -- all of whom I know to have
>some experience designing/building/deploying protocols in a space
>similar or identical to ROLL.
>
>So, I do not share the view expressed in your last paragraph above.
>
>Thomas
>

------=_Part_68913_5391360.1228842993609-- --===============1211004101== 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 --===============1211004101==-- From roll-bounces@ietf.org Tue Dec 9 09:32:22 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 350523A6923; Tue, 9 Dec 2008 09:32:22 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 875673A6923 for ; Tue, 9 Dec 2008 09:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.404 X-Spam-Level: X-Spam-Status: No, score=-10.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nmp85aI0lJ+7 for ; Tue, 9 Dec 2008 09:32:19 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 115D03A67E9 for ; Tue, 9 Dec 2008 09:32:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,742,1220227200"; d="scan'208";a="28137412" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Dec 2008 17:32:12 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mB9HWBCU004864; Tue, 9 Dec 2008 18:32:11 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mB9HWBQI008900; Tue, 9 Dec 2008 17:32:11 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); Tue, 9 Dec 2008 18:32:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 9 Dec 2008 18:32:06 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC06ADE37A@xmb-ams-337.emea.cisco.com> In-Reply-To: <61D43925-D96D-41A0-A73B-E87B586245E3@thomasclausen.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] WorkingGroup LastCall:draft-ietf-roll-protocols-survey-02 Thread-Index: AclaEbsQ68mu7I+oQ6OfHtr5NcA9dAADWsIA References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com><374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com><7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> <61D43925-D96D-41A0-A73B-E87B586245E3@thomasclausen.org> From: "Pascal Thubert (pthubert)" To: "Thomas Heide Clausen" , "JP Vasseur (jvasseur)" X-OriginalArrivalTime: 09 Dec 2008 17:32:11.0627 (UTC) FILETIME=[1188CBB0:01C95A24] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3717; t=1228843932; x=1229707932; 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]=20WorkingGroup=09LastCall=3Adraf t-ietf-roll-protocols-survey-02 |Sender:=20; bh=EkbMfVMAw3RHGp00Auxk0ugEuoAT+zM1+2A8QP/XumE=; b=wmCBiyY5BhMch46r0lMAe04KQsbJYb4om7+E+aGqj/ERDxtOis3p5mcgUT YmafdLDzYKdxdDkyQrv3fnhhUBm0zA/mgZwqWySuWKQ4aUyD4tuM3kch4+3g uLaT7FXjb+; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "Dearlove, Christopher \(UK\)" , Emmanuel Baccelli , roll@ietf.org Subject: Re: [Roll] WorkingGroup LastCall:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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 Thomas: Every evaluation picks criteria and applies them. This doc has been around = for awhile with its own clear list of criteria, which take their source in = the requirements drafts. Someone could propose another doc with another set= of criteria that would make perfect sense for a different set of requireme= nts. We could make a moving target of this doc and pursue the quest of the perfe= ct evaluation of life, the universe and everything. But that's not the moti= vation nor the best interest of this group. In any case, do we expect a per= fect one-fit-it-all protocol? I guess not. We'll have to trade off and prio= ritize, so while the evaluation draft has mostly served its purpose, we are= far from being done with the requirement drafts themselves. = For instance, in the case of industrial, there is an emphasys on reliabilit= y vs. path cost, which *is actually* achieved in the real (non-IP) world by= building graphs that tend to enable multiple forwarding solutions at each = hop, with the capability to revise the forwarding decision on a frame by fr= ame basis after a few L2 retries. = There are deployed IP protocols that enable similar non-equal-cost path com= putation, for instance in the DV world with EIGRP feasible successors. Ther= e is a huge amount of reusable art in traffic engineering. There is also in= teresting art in academia such as Tora that might fit the bill. What we nee= d to do is build on this experience and start the work on real solutions to= figure what optimum we can actually achieve for our requirements. = Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Th= omas Heide Clausen >Sent: mardi 9 d=E9cembre 2008 16:21 >To: JP Vasseur (jvasseur) >Cc: Dearlove, Christopher (UK); Emmanuel Baccelli; roll@ietf.org >Subject: Re: [Roll] WorkingGroup LastCall:draft-ietf-roll-protocols-survey= -02 > > >On Dec 9, 2008, at 16:13 PM, JP Vasseur wrote: > >> >> On Dec 9, 2008, at 4:03 PM, Dearlove, Christopher (UK) wrote: >> >>> >>>> 2- There is clearly a need for a solution *today*: look at all other >>>> (deployed) non IP solutions out there >>> >>>> 4- We are not talking about a "dream protocol": again this is very >>>> much realistic since solutions do exist today (not IP unfortunately >>> :-( ....) >>> >>> Can you point me to an existing (doesn't have to be IP) protocol >>> that passes all five of the ID's tests, without some major drawback >>> in some other area. I for one would find it interesting and useful. >>> (Obviously it would have to have a specification, not just a claim >>> made about a proprietary protocol.) >> >> You missed my point ... I did not say that there were any of them >> satisfying these criterion. >> But clearly there are non IP solutions being deployed, my point >> being that we need an >> IP solution soon and we should make it right. > >I read Chris Dearlove as asking for something concrete, justifying >that these five "criteria" that the survey I-D sets out are >*attainable* (and without some major drawbacks on the other important >metrics that the survey I-D is ignoring) and that we're not chasing a >"pie in the sky". > >>> If one or more such protocols exist, I don't see why they aren't >>> discussed at this stage. >> >> I do not think that it is in our charter to analyze *all* possible >> protocols. > >No, but if a good such protocol indeed existed, IP or not, having it >before us might just help quell skepticism. >_______________________________________________ >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 Dec 9 09:46:34 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA3843A6B17; Tue, 9 Dec 2008 09:46:34 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 977623A6B29 for ; Tue, 9 Dec 2008 09:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.414 X-Spam-Level: X-Spam-Status: No, score=-10.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id le16qtQ-i5aZ for ; Tue, 9 Dec 2008 09:46:32 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 986273A690B for ; Tue, 9 Dec 2008 09:46:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,742,1220227200"; d="scan'208";a="28138228" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 09 Dec 2008 17:46:22 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mB9HkM79013705; Tue, 9 Dec 2008 18:46:22 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mB9Hf5Qu010015; Tue, 9 Dec 2008 17:46:22 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); Tue, 9 Dec 2008 18:44:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 9 Dec 2008 18:43:55 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC06ADE38A@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Working GroupLastCall:draft-ietf-roll-protocols-survey-02 Thread-Index: AclaIfBDE7ngsZUtSD2xvU3+9HCzlwAAj0TA References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com><7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu><7892795E1A87F04CADFCCF41FADD00FC06ADE328@xmb-ams-337.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Emmanuel Baccelli" , X-OriginalArrivalTime: 09 Dec 2008 17:44:00.0018 (UTC) FILETIME=[B7C4AF20:01C95A25] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4347; t=1228844782; x=1229708782; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20Working=20GroupLastCall=3Adraf t-ietf-roll-protocols-survey-02 |Sender:=20; bh=y3eeTB8UZFlHJKzNZ2pd4mBt4CTmdo5u1M+G8ryjZSI=; b=NNfEYmJ6cyI9NN5FuRW93PwZyCMbNzYfG15keBSxRrV18/EiyzZelX0Wx6 GkRb/eD881MWURJWl+lgkPy6C2lZwscdeIITe1JDHACUqGHBko70y53KOm/6 kgaFAK280B; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [Roll] Working GroupLastCall:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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 Emmanuel, I do agree that was particularily infortunate, considering that in practice= , autoconf can very well be a building block of the environment where ROLL = is deployed to perform the routing. We need to alert the A-Ds to avoid such= mishap in the future. I do not necessarily reckon that this lot of people you are talking about w= ould have necessarily voted against the consensus nor dramatically impacted= the vote. I certainly trust that having to choose between the two sessions= was a difficult decision for many, but we do need people willing to work i= n ROLL and for those people, ROLL can hardly be a second priority consideri= ng the milestones we need to achieve. Pascal ________________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Emm= anuel Baccelli Sent: mardi 9 d=E9cembre 2008 18:17 To: roll@ietf.org Subject: Re: [Roll] Working GroupLastCall:draft-ietf-roll-protocols-survey-= 02 Well I guess a lot of interested people could not attend the interim in Cal= ifornia, and a lot of people could not attend the last ROLL meeting in Minn= eapolis either because Autoconf was scheduled=A0simultaneously=A0(which was= really unfortunate, I hope it does not happen again). Emmanuel On Tue, Dec 9, 2008 at 5:45 PM, Pascal Thubert (pthubert) wrote: Hi all: Having attended the interim, I can concur that there was a clear consensus = in the room and through the teleconf. The interim was not as crowded as the= previous IETF meeting, yet there were more people there who raised their h= ands in favor than there are in a normal meeting considering all the non-vo= ters in the room. To me that was a clear consensus, better than many I've s= een. ROLL provides a niche where we can develop a simple and efficient mechanism= that might not have all the power and goodies of the bigger brothers but w= ould fit in a constrained device and do the minimum needed. The project mig= ht fail anyway if what we really want is a dream protocol, but it is certai= n to fail if we do not try. If enough people are willing to help, let's giv= e ROLL a chance. Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Th= omas Heide Clausen >Sent: mardi 9 d=E9cembre 2008 16:08 >To: JP Vasseur (jvasseur) >Cc: Emmanuel Baccelli; roll@ietf.org >Subject: Re: [Roll] Working GroupLast Call:draft-ietf-roll-protocols-surve= y-02 > >Hi JP, > >Posting on a 'list, you run the risk that not just Baccelli respond. >See below. > >On Dec 9, 2008, at 15:53 PM, JP Vasseur wrote: > > > >>> >>>> 3 - The draft is not constructive in its current shape. >>> >>> I do not think that your comment is fair. The draft has been >>> discussed in the WG for quite some time and extensive discussion >>> took place during the interim WG and on the ML. >>> >>> >>> Yes there have been some discussions, but there is no consensus on >>> the approach taken by this document. >> >> Thanks for your feed-back here. What do you propose ? >> >>> And there is no rough consensus either. >>> >> >> Please refer to the WG minutes + several emails on the ML, with a >> good consensus. That being said, I hear you and thanks for your >> comments. I do register your disagreement. Having read again >> others' email, I do not think that this is a general feeling. >> > >At this point, I think it fair to raise that in Minneapolis, ROLL and >AUTOCONF were concurrently scheduled, and that for that reason =A0large >part of the community (myself included) were unable to attend ROLL. > >If scheduling would have permitted, I would have attended, and I >would have made my concerns be known at the mike (and, hopefully, >have had those reflected in the minutes as well). > >Looking back over the mailing list postings, I also see a number of >concerns raised by a number of people -- all of whom I know to have >some experience designing/building/deploying protocols in a space >similar or identical to ROLL. > >So, I do not share the view expressed in your last paragraph above. > >Thomas > >_______________________________________________ >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 Dec 9 09:59:08 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 665233A6ABD; Tue, 9 Dec 2008 09:59:08 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E51A3A68C5 for ; Tue, 9 Dec 2008 09:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEl+iMReL8pF for ; Tue, 9 Dec 2008 09:59:06 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 311003A6ABD for ; Tue, 9 Dec 2008 09:59:06 -0800 (PST) Received: from [74.85.100.71] (helo=host221-58.wifi.conference.usenix.org) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1LA6rM-0003NR-5B; Tue, 09 Dec 2008 09:59:00 -0800 Message-Id: <95CE6683-9834-430C-937D-32A034C87175@cs.stanford.edu> From: Philip Levis To: Thomas Heide Clausen In-Reply-To: <710F3638-03FD-460F-8AB2-DC4100832F3B@thomasclausen.org> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 9 Dec 2008 09:58:58 -0800 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <710F3638-03FD-460F-8AB2-DC4100832F3B@thomasclausen.org> X-Mailer: Apple Mail (2.929.2) X-Scan-Signature: 5c9dfd019177c26b760c516f66c2bd07 Cc: charliep@computer.org, roll@ietf.org Subject: Re: [Roll] Review and concerns (was: Re: Working Group Last Call: draft-ietf-roll-protocols-survey-02) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Dec 8, 2008, at 8:00 AM, Thomas Heide Clausen wrote: > Dear All, > > I've been reviewing the latest incarnation of this I-D, and I have a > couple of general concerns with this I-D and, more specifically, > with the approach it seems to be suggesting for the working group. Well, the approach is the general consensus the working group reached after discussing the topic over the past year or so. > > > o The document seems to set the bar of acceptance at "the holy > grail of a routing protocol", > i.e. defines "acceptable" to be "zero-cost [more on that in a > following bullet], > instant-convergence" -- thereby causing all routing protocols to > almost by definition be > judged "insufficient" -- which is reflected in the evaluation of > the existing set of routing > protocols. I don't quite follow "zero cost" and "instant-convergence;" the cost metrics noted are clearly non-zero (and there are others not described), while convergence is not placed as a criterion. > > > o As I assume ROLL is designing "for the real world", compromises > and trade-offs are > paramount in protocol design. By elevating a set of criteria (sec. > 3 and 4 -- "table scalability", > "loss response", "control cost", "link cost" and "node cost") > above the rest, while pointing out > that (i) an approach not meeting the bar on all of those is > unacceptable and (ii) "applications > introduce additional, more stringent, requirements", this I-D > effectively limits the trade-offs > possible for when designing protocols for these applications. I'm not sure I'd agree with your claim that the criteria set are not reasonable "for the real world." In particular, there are several members of the WG who have designed, implemented, and deployed protocols in products, scientific deployments, and other real-world uses of L2Ns. They seem to think the criteria are reasonable. Tradeoffs are a critical part of any real system. Note, however, that the criteria specified should not be interpreted as MUST NOT ever do more than X; rather, MUST work with only X. As a trivial example, simply because a protocol's routing table needs to be able to scale with O(D) doesn't mean a protocol can't maintain a table larger than O(D). The former ensures that the design mechanisms are reasonable for the low-power devices L2Ns necessitate; the latter provides actual deployment and implementation flexibility. For these classes of networks, making the minimum resource requirements low is critical. > > o Going by where the bar for acceptance is set in this document, I > have thought and come > up with indeed two solutions that have "zero-cost-instant- > convergence" properties, and > they both satisfy the IP delivery semantics. One is "drop all > traffic, don't even try" and the > other is "flood all traffic, don't maintain a routing table". > > Of course, those two proposals are in jest, as I am sure that the > trade-off I am making > -- sacrificing delivery ratio for the former, satisfying network > traffic and energy (but not > as a consequence of the routing protocol relaying control traffic) > for the latter are not > acceptable in an absolute sense -- but the routing protocol will > itself require have > zero-cost, zero-memory, instant-convergence. I thought the document was pretty clear: there could be protocols which meet the criteria in the document yet are not sufficient. There are obviously other considerations. But as the question the document seeks to answer -- "Can ROLL use existing standards unchanged" -- is much narrower than "What should a protocol look like?" The purpose of this narrow scope is to allow the WG to answer the question without debating minutia on whether a particular criterion is more or less important. That is something for later WG discussion. > > > o From the previous and first bullet, "control cost" is an > insufficient measure. "Flooding all > data" has zero "control cost" but a large overall cost (many > retransmissions, lots of battery > drain, lots of media use). A routing protocol incurring some > "control cost" to gain lower > "data transmission cost" likely is a better tradeoff, especially > if data traffic is a common > occurrence in the network. > > IOW, looking at "control cost" as a separate metric is not > terribly useful unless the > consequences in terms of the "data cost" and "data delivery ratio" > are considered > as well. > I think you're reading this document in a way in which it was never intended, pretty explicitly so. This draft does not say "if a protocol meets these requirements, then it is OK." Otherwise, we end up in an adversarial situation, like the one you outline above, where we're trying to find holes in the criteria. Adding criteria such as "delivers data" would be a bit silly, adding complexity to the document when we all know that's of course important. > Chris Dearlove summarize well in saying that the document does well > in setting out a rigid set of "pass" criteria and observing that > none of the six protocols analyzed satisfies those off-the-shel -- > but that this should not be stretched to assume that an entirely > new design is required. Please read through the mail archives. At no point has the document ever claimed so, and I've tried to be very very explicit in this. At the interim meeting, I was asked the question of "so what should we do next," and I demurred. The introduction is VERY explicit: "Whether or not such a protocol involves modifications to an existing protocol or a new protocol entirely is outside the scope of this document: this document simply seeks to answer the question: do LLNs require a new protocol specification document at all?" This concern with the document comes up again and again, and I cite the same points. For some reason readers come away with an impression of the document's claims which are completely contrary to its text. Do you have any suggestions on how we could make the document clearer? > > > I also join Chris in his comment that, for example, OLSRv2 offers > "timing backoff" and "fisheye variable flooding" without variations > to the routing protocol [the specificities of how to set timers or > vary flooding is a policy matter that is dependent on deployment, > but can be done entirely conformant with its specification] -- and > that this is not considered. I'll go further than Chris and suggest > that not considering the use of such options, which are present in > the protocols but where a policy specification dependent on > deployment is required, casts doubt on the assessment of the > protocols as presented - not just OLSRv2, but such options exist for > other protocols as well. Unfortunately, neither of these are specified in RFCs or mature drafts. Mario Gerla is wonderful and has great ideas, but it's tough to argue that analytical papers from almost a decade ago definitively establish the efficacy of a protocol mechanism well enough to determine IETF protocol specification. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Dec 9 11:48:48 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 833C93A67EC; Tue, 9 Dec 2008 11:48:48 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53D333A67E4 for ; Tue, 9 Dec 2008 11:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WvbhxS6iu-l for ; Tue, 9 Dec 2008 11:48:46 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 050DB3A67EC for ; Tue, 9 Dec 2008 11:48:46 -0800 (PST) Received: from [74.85.100.71] (helo=host221-58.wifi.conference.usenix.org) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1LA8Z8-0007AR-9F; Tue, 09 Dec 2008 11:48:37 -0800 Message-Id: <6A3B39C4-8126-47D0-B29A-752191F4F487@cs.stanford.edu> From: Philip Levis To: JP Vasseur In-Reply-To: <3CEA849E-22CD-4DF1-A56B-E1C38572AA77@cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 9 Dec 2008 11:47:42 -0800 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> <3CEA849E-22CD-4DF1-A56B-E1C38572AA77@cisco.com> X-Mailer: Apple Mail (2.929.2) X-Scan-Signature: 06ac0f501ed97ee7d2a3c5af22b79f06 Cc: Emmanuel Baccelli , roll@ietf.org, arsalan@eecs.berkeley.edu Subject: Re: [Roll] Working Group Last Call:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Dec 9, 2008, at 7:30 AM, JP Vasseur wrote: > > Please find below the minutes of the ROLL Interim Working Group > meeting that was help in San Jose on Oct 6. > > This was an excellent very productive meeting where we managed to > make good progress and reached a consensus on an important question > related to a key Milestone.As usual such consensus must be confirmed > on the mailing list. > > When ROLL got chartered, one of our key milestones was to determined > after some careful analysis of the routing requirements whether or > not we could find an existing protocols that would meet our routing > requirement with no change (with no protocol changes). All > participants to the interim meeting agreed that there was no > existing protocol that would meet the ROLL routing requirements > *with no protocol work*. Do not hesitate to express your opinion on > the mailing list before Oct 17 and then we will document the WG > decision. I think this is the key point. The #1 question is whether the concerns on structure, criteria, etc. will change the conclusion of the document. If someone has strong evidence that existing protocols, as specified, can meet the requirements of ROLL, then that information would be of fantastic use and value to ROLL. But we seem to have consensus on this point: existing IETF specifications do not meet the requirements L2Ns introduce. More specifically, if there's a disagreement with the conclusion of the document, then this means one of two things: 1) The analysis of an existing protocol is incorrect 2) A criterion is too harsh and should be weaker The domain experts who have written the application drafts are the best commentators on 2); in fact, one of the criteria (control cost) did relax slightly based on feedback at the interim meeting. So this leaves 1). The authors of TBRPF made some very helpful comments on the TBRPF analysis early in the document's lifetime, and we amended it appropriately. If there are other entries that are incorrect, then a statement of the correct analysis would be the best way to make the document more accurate. Everything else besides this is really ancillary; we can debate at length whether there should be 4, 5, or 8 criteria, but if the conclusion is the same, then all this debate does is stifle ROLL from doing useful work. Of course the document can be improved and comments are welcome. In the last revision, a few readers pointed out many things which were unclear, and which Stephen, Arsalan, and I tried to clarify. For example, it's critical that the document be very transparent on the methodology it uses and how it reaches its conclusions. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Dec 9 13:19:34 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9CE03A6B61; Tue, 9 Dec 2008 13:19:34 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4830A3A6B6B for ; Tue, 9 Dec 2008 13:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLqkAqSYrPaZ for ; Tue, 9 Dec 2008 13:19:32 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 0EAE23A6B05 for ; Tue, 9 Dec 2008 13:19:31 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so33785eyd.31 for ; Tue, 09 Dec 2008 13:19:24 -0800 (PST) Received: by 10.210.62.12 with SMTP id k12mr686155eba.140.1228857563668; Tue, 09 Dec 2008 13:19:23 -0800 (PST) Received: from ?10.104.215.94? (62-50-194-245.client.stsn.net [62.50.194.245]) by mx.google.com with ESMTPS id z40sm684593ikz.8.2008.12.09.13.19.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Dec 2008 13:19:23 -0800 (PST) Message-ID: <493EE0CE.8040405@polytechnique.edu> Date: Tue, 09 Dec 2008 21:19:10 +0000 From: Ulrich Herberg Organization: Ecole Polytechnique User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: roll@ietf.org X-Enigmail-Version: 0.95.7 Subject: Re: [Roll] Working Group Last Call: draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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, Unfortunately, I did not attend IETF in California, and in Minneapolis I was attending the autoconf WG meeting, so I was absent in both ROLL meetings. I have some concerns about this document. - I think that the set of criteria chosen for the evaluation is not complete. As Thomas Clausen said, criteria like delivery ratio and path length seem to be important in addition to control cost, as they can be contradictory. I can design routing protocols with an extremely low control cost, but with a very bad delivery ratio or a high path length. As in most networks data traffic will take more bandwith than control traffic, the selection of only "control cost" as criterion does not seem to be fair. I understand that the authors do not claim to have presented a complete set of criteria, but just a subset. However, many routing protocols intentionally do a trade-off between control cost and delivery ratio/path length, so just putting a "fail" for control cost does not seem to be adequate for me. - In the introduction, the authors state: "this document simply seeks to answer the question: do LLNs require a new protocol specification document at all?" I cannot find an answer to that question. What is the conclusion of this document? Yes, there is no routing protocol in the IETF that -- according to these evaluation criteria -- fulfills all requirements. Does that mean that we need to rewrite routing protocols from the scratch? Or just tweak existing protocols? What is the consequence of this document? In what way does it help us to continue to work on routing protocols for LLNs considering the limited set of routing protocols and criteria selected in this ID? Nits: - Section 3, "The five criteria, presented in Section 3" Shouldn't that be section 4? - Section 1 MANET: Mobile Ad-hoc Networks I think that MANET is mostly used in singular, not in the plural "networks" (see also your unnumbered section "Protocols Today") Best regards, Ulrich Herberg _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Dec 9 13:19:45 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F156D3A6B72; Tue, 9 Dec 2008 13:19:44 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE9963A6B72 for ; Tue, 9 Dec 2008 13:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, 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 x-T9xxBjsv1s for ; Tue, 9 Dec 2008 13:19:42 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id E77253A6B6C for ; Tue, 9 Dec 2008 13:19:42 -0800 (PST) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id mB9LJYIE023994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Dec 2008 13:19:35 -0800 (PST) Message-ID: <493EE0E0.2070406@eecs.berkeley.edu> Date: Tue, 09 Dec 2008 13:19:28 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> In-Reply-To: Cc: roll@ietf.org Subject: Re: [Roll] Working Group LastCall:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============1135017112==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============1135017112== Content-Type: multipart/alternative; boundary="------------060503040703000903080900" This is a multi-part message in MIME format. --------------060503040703000903080900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Christopher - the fact that existing protocols are proprietary makes it difficult to deliver on your request. Proprietary protocols are generally not publicly documented, hence the desire to have an IETF standard. I can point you to IEC PAS (Publicly Available Specification) 62591, which describes the Wireless HART protocol, but 1) despite the name it's still a few months away from actually being "public", and 2) it describes all of the mechanisms for gathering and disseminating routing information but does not actually specify how the routing engine makes it's decisions. That information is at this point truly proprietary. The proof that it works has been in the field for almost two years now, and there are many companies building and shipping it. I believe that at least one implementation satisfies all of the RoLL IDs tests, not just the five in the protocol survey document. This protocol is not discussed in the survey document because 1) it's not an IETF protocol, 2) reasons 2 through N are irrelevant, reason #1 is enough. Protocols exist that do what we want, they just haven't made it into RFCs yet. ksjp Dearlove, Christopher (UK) wrote: >> 2- There is clearly a need for a solution *today*: look at all other >> (deployed) non IP solutions out there >> > > >> 4- We are not talking about a "dream protocol": again this is very >> much realistic since solutions do exist today (not IP unfortunately >> > :-( ....) > > Can you point me to an existing (doesn't have to be IP) protocol > that passes all five of the ID's tests, without some major drawback > in some other area. I for one would find it interesting and useful. > (Obviously it would have to have a specification, not just a claim > made about a proprietary protocol.) > > If one or more such protocols exist, I don't see why they aren't > discussed at this stage. > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --------------060503040703000903080900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Christopher -
 the fact that existing protocols are proprietary makes it difficult to deliver on your request.
Proprietary protocols are generally not publicly documented, hence the desire to have an
IETF standard.
 I can point you to IEC PAS (Publicly Available Specification) 62591, which describes the
Wireless HART protocol, but 1) despite the name it's still a few months away from actually
being "public", and 2) it describes all of the mechanisms for gathering and disseminating
routing information but does not actually specify how the routing engine makes it's decisions.
That information is at this point truly proprietary.

The proof that it works has been in the field for almost two years now, and there are many
companies building and shipping it.  I believe that at least one implementation satisfies all of the
RoLL IDs tests, not just the five in the protocol survey document.
This protocol is not discussed in the survey document because 1) it's not an IETF protocol,
2) reasons 2 through N are irrelevant, reason #1 is enough.

Protocols exist that do what we want, they just haven't made it into RFCs yet.

ksjp

Dearlove, Christopher (UK) wrote: 
2- There is clearly a need for a solution *today*: look at all other
(deployed) non IP solutions out there 
    
 
  
4- We are not talking about a "dream protocol": again this is very
much realistic since solutions do exist today (not IP unfortunately
    
:-( ....)

Can you point me to an existing (doesn't have to be IP) protocol
that passes all five of the ID's tests, without some major drawback
in some other area. I for one would find it interesting and useful.
(Obviously it would have to have a specification, not just a claim
made about a proprietary protocol.)

If one or more such protocols exist, I don't see why they aren't
discussed at this stage.

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

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--------------060503040703000903080900-- --===============1135017112== 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 --===============1135017112==-- From roll-bounces@ietf.org Tue Dec 9 13:48:15 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E2F728C195; Tue, 9 Dec 2008 13:48:15 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33EE828C195 for ; Tue, 9 Dec 2008 13:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.552 X-Spam-Level: X-Spam-Status: No, score=-10.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-W5C-Wa8q-y for ; Tue, 9 Dec 2008 13:48:13 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id F105428C192 for ; Tue, 9 Dec 2008 13:48:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,743,1220227200"; d="scan'208";a="28154053" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Dec 2008 21:47:59 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mB9Llx7A024176; Tue, 9 Dec 2008 22:47:59 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mB9Llxg1025519; Tue, 9 Dec 2008 21:47:59 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Dec 2008 22:47:59 +0100 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Dec 2008 22:47:58 +0100 Message-Id: <5A65356C-847A-4A56-B476-25D8806A1246@cisco.com> From: JP Vasseur To: Ulrich Herberg In-Reply-To: <493EE0CE.8040405@polytechnique.edu> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 9 Dec 2008 22:47:57 +0100 References: <493EE0CE.8040405@polytechnique.edu> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 09 Dec 2008 21:47:58.0450 (UTC) FILETIME=[CCF42520:01C95A47] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2622; t=1228859279; x=1229723279; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Working=20Group=20Last=20Call= 3A=20draft-ietf-roll-protocols-survey-02 |Sender:=20; bh=OVtnjokZOGNPmX0NeC3Qwch8iJXL/HpXSw/vAlnnyNM=; b=TFOkXuj5CUlJy57Ng85tlEBPvV0Nfmkf4yeC33/g+pRhnBl9EkSKcMAbxU VgWMeDzHrqMNwOg9naKXr47wFKaeXPhbzVjNhh2ZI9ALhn7tf3VGW3gdib3R tIGFu84YfN; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] Working Group Last Call: draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Ulrich, On Dec 9, 2008, at 10:19 PM, Ulrich Herberg wrote: > Hi, > > Unfortunately, I did not attend IETF in California, and in > Minneapolis I > was attending the autoconf WG meeting, so I was absent in both ROLL > meetings. > > I have some concerns about this document. > > - I think that the set of criteria chosen for the evaluation is not > complete. As Thomas Clausen said, criteria like delivery ratio and > path > length seem to be important in addition to control cost, as they can > be > contradictory. I can design routing protocols with an extremely low > control cost, but with a very bad delivery ratio or a high path > length. > As in most networks data traffic will take more bandwith than control > traffic, the selection of only "control cost" as criterion does not > seem > to be fair. I understand that the authors do not claim to have > presented > a complete set of criteria, but just a subset. However, many routing > protocols intentionally do a trade-off between control cost and > delivery > ratio/path length, so just putting a "fail" for control cost does not > seem to be adequate for me. > Please bear in mind that the objective is not to look at all possible criterion but a required subset in light of the four routing requirement documents produced by the WG. > - In the introduction, the authors state: > > "this document simply seeks to answer the question: do LLNs require a > new protocol specification document at all?" > > I cannot find an answer to that question. What is the conclusion of > this > document? Yes, there is no routing protocol in the IETF that -- > according to these evaluation criteria -- fulfills all requirements. > Does that mean that we need to rewrite routing protocols from the > scratch? Or just tweak existing protocols? What is the consequence of > this document? In what way does it help us to continue to work on > routing protocols for LLNs considering the limited set of routing > protocols and criteria selected in this ID? > Hopefully I answered these questions on the list today. > Nits: > - Section 3, > "The five criteria, presented in Section 3" > Shouldn't that be section 4? > - Section 1 > MANET: Mobile Ad-hoc Networks > I think that MANET is mostly used in singular, not in the plural > "networks" (see also your unnumbered section "Protocols Today") Thanks. JP. > > > Best regards, > Ulrich Herberg > _______________________________________________ > 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 Dec 9 14:28:45 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF78528C0F6; Tue, 9 Dec 2008 14:28:45 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE1683A6B20 for ; Tue, 9 Dec 2008 14:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMkmmAss7sD0 for ; Tue, 9 Dec 2008 14:28:42 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id A72483A6A5E for ; Tue, 9 Dec 2008 14:28:42 -0800 (PST) Received: from [192.168.7.43] (69-12-164-138.sfo.archrock.com [69.12.164.138]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id mB9MSYbd025138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 9 Dec 2008 14:28:36 -0800 (PST) Message-ID: <493EF103.7050908@eecs.berkeley.edu> Date: Tue, 09 Dec 2008 14:28:19 -0800 From: "David E. Culler" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: roll@ietf.org Subject: Re: [Roll] Review and concerns (was: Re: Working Group Last Call: draft-ietf-roll-protocols-survey-02) X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============1111518860==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1111518860== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I would like to emphasize a few points in the thread.

Phil correctly observes that we reached consensus on the process long ago.  After taking feedback on a early version of the draft we agreed on (1) the definition of the universe of candidates (so the process would terminate), (2)  that we would build a tableau of candidates versus criteria and (3) that we would conduct a detailed analysis in order to obtain a rough scoring of pass, fail, ?.  We discussed and consensed on the criteria.  These are fundamentally related to the charter - routing on (a) low-power and (b) lossy links.  We debated small discrepancies in the analysis since the summer IETF.  We recognized that such analysis and such criteria were imperfect, but necessary.  We all recognized that scaling characteristics  are essential  and yet the constants  also matter.  We recognized that even passing all the criteria may not be sufficient for having a completely satisfactory solution.  Thus, they are viewed as necessary, but not sufficient.  We recognized that there would be regimes where the constants all worked out, even if the general case did not.  But, it would be fruitless for the whole discussion to degenerate into debates about the exact value of innumerable tuning and scaling constants.

Some of the concerns center on the difficulty of meeting these criteria.  Indeed, the working group was formed because there are real problems to solve.  The application routing requirements drafts make clear that the criteria are real, not spurious.  So, whether they hard or not they serve well to define the goal.  At the same time, there are several existence proofs of solutions in the market and in the research community that meet these criteria or are very very close.  So they do not appear to be "holy grails" but rather pragmatic guidelines for solid design and engineering effort.

Other comments observe that the criteria do not address every possible concern.  Indeed, they are viewed as necessary but not sufficient.  At the same time, they go a very long way to addressing the full problem, as substantiated by the application drafts.  So it appears that they do serve to reasonably define a "sweet spot" goal.  Meeting the criteria makes it extremely likely that real needs can be met with reasonable engineering of solutions developed around this goal.

Many other concerns recognize that modifications of existing protocols in a manner that is focused on these criteria would make them far more suitable.  That suggests that the criteria and the analysis in the draft serve their goal.  We are not chartered to consider such modifications until after this ID is done.

Some concerns recognize that there are protocols outside the defined universe that should be considered and that appear to be far better suited to meeting the criteria than the set of IETF protocols that were considered - since those protocols were developed without these criteria.  Again, that suggests that the criteria are a reasonable guide, that they do not appear to be unobtainable, and that the analysis has provided a suitable guide.

None of the comments seem to be claiming that there is a solution within the universe that we were chartered to consider that meets the criteria.

These were the reasons that we reached consensus on the draft, its criteria, and its analysis.  We could spend forever on the debate, but if it does not change the conclusion it is only time lost. 

At best it might be that if the criteria were suitably weakened there might be an existing solution that met those relaxed criteria.  Again, no one has proposed such a lowering of the bar and it is unclear that such lowering would meet the application requirements.

These were the factors that led to consensus, thus enabling us to move forward.



Re: [Roll] Working Group LastCall:draft-ietf-roll-protocols-survey-02

On Dec 9, 2008, at 16:13 PM, JP Vasseur wrote:


On Dec 9, 2008, at 4:03 PM, Dearlove, Christopher (UK) wrote:

  
2- There is clearly a need for a solution *today*: look at all other
(deployed) non IP solutions out there
      
4- We are not talking about a "dream protocol": again this is very
much realistic since solutions do exist today (not IP unfortunately
      
:-( ....)

Can you point me to an existing (doesn't have to be IP) protocol
that passes all five of the ID's tests, without some major drawback
in some other area. I for one would find it interesting and useful.
(Obviously it would have to have a specification, not just a claim
made about a proprietary protocol.)
You missed my point ... I did not say that there were any of them satisfying these criterion. But clearly there are non IP solutions being deployed, my point being that we need an 
IP solution soon and we should make it right.
I read Chris Dearlove as asking for something concrete, justifying that these five "criteria" that the survey I-D sets out are *attainable* (and without some major drawbacks on the other important metrics that the survey I-D is ignoring) and that we're not chasing a "pie in the sky". 
If one or more such protocols exist, I don't see why they aren't
discussed at this stage.
I do not think that it is in our charter to analyze *all* possible protocols.
No, but if a good such protocol indeed existed, IP or not, having it before us might just help quell skepticism. 
_______________________________________________
Roll mailing list
Roll at ietf.org
https://www.ietf.org/mailman/listinfo/roll
--===============1111518860== 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 --===============1111518860==-- From roll-bounces@ietf.org Tue Dec 9 14:33:31 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 588E83A6B20; Tue, 9 Dec 2008 14:33:31 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85E8428C13A for ; Tue, 9 Dec 2008 14:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.87 X-Spam-Level: X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=0.729, 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 7rWHptWifBYB for ; Tue, 9 Dec 2008 14:33:29 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id A18593A6B0C for ; Tue, 9 Dec 2008 14:33:29 -0800 (PST) Received: from [192.168.7.43] (69-12-164-138.sfo.archrock.com [69.12.164.138]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id mB9MXMXt025255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 9 Dec 2008 14:33:23 -0800 (PST) Message-ID: <493EF222.1030701@eecs.berkeley.edu> Date: Tue, 09 Dec 2008 14:33:06 -0800 From: "David E. Culler" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: roll@ietf.org Subject: Re: [Roll] Review and concerns - the missing text in the post X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org I would like to emphasize a few points in the thread - Working Group Last Call: draft-ietf-roll-protocols-survey-02 Phil correctly observes that we reached consensus on the process long ago. After taking feedback on a early version of the draft we agreed on (1) the definition of the universe of candidates (so the process would terminate), (2) that we would build a tableau of candidates versus criteria and (3) that we would conduct a detailed analysis in order to obtain a rough scoring of pass, fail, ?. We discussed and consensed on the criteria. These are fundamentally related to the charter - routing on (a) low-power and (b) lossy links. We debated small discrepancies in the analysis since the summer IETF. We recognized that such analysis and such criteria were imperfect, but necessary. We all recognized that scaling characteristics are essential and yet the constants also matter. We recognized that even passing all the criteria may not be sufficient for having a completely satisfactory solution. Thus, they are viewed as necessary, but not sufficient. We recognized that there would be regimes where the constants all worked out, even if the general case did not. But, it would be fruitless for the whole discussion to degenerate into debates about the exact value of innumerable tuning and scaling constants. Some of the concerns center on the difficulty of meeting these criteria. Indeed, the working group was formed because there are real problems to solve. The application routing requirements drafts make clear that the criteria are real, not spurious. So, whether they hard or not they serve well to define the goal. At the same time, there are several existence proofs of solutions in the market and in the research community that meet these criteria or are very very close. So they do not appear to be "holy grails" but rather pragmatic guidelines for solid design and engineering effort. Other comments observe that the criteria do not address every possible concern. Indeed, they are viewed as necessary but not sufficient. At the same time, they go a very long way to addressing the full problem, as substantiated by the application drafts. So it appears that they do serve to reasonably define a "sweet spot" goal. Meeting the criteria makes it extremely likely that real needs can be met with reasonable engineering of solutions developed around this goal. Many other concerns recognize that modifications of existing protocols in a manner that is focused on these criteria would make them far more suitable. That suggests that the criteria and the analysis in the draft serve their goal. We are not chartered to consider such modifications until after this ID is done. Some concerns recognize that there are protocols outside the defined universe that should be considered and that appear to be far better suited to meeting the criteria than the set of IETF protocols that were considered - since those protocols were developed without these criteria. Again, that suggests that the criteria are a reasonable guide, that they do not appear to be unobtainable, and that the analysis has provided a suitable guide. None of the comments seem to be claiming that there is a solution within the universe that we were chartered to consider that meets the criteria. These were the reasons that we reached consensus on the draft, its criteria, and its analysis. We could spend forever on the debate, but if it does not change the conclusion it is only time lost. At best it might be that if the criteria were suitably weakened there might be an existing solution that met those relaxed criteria. Again, no one has proposed such a lowering of the bar and it is unclear that such lowering would meet the application requirements. These were the factors that led to consensus, thus enabling us to move forward. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Dec 9 15:02:02 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 314EE3A6B39; Tue, 9 Dec 2008 15:02:02 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7A693A6B29 for ; Tue, 9 Dec 2008 15:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcKYZAXcaPQ0 for ; Tue, 9 Dec 2008 15:01:59 -0800 (PST) Received: from mail-gx0-f12.google.com (mail-gx0-f12.google.com [209.85.217.12]) by core3.amsl.com (Postfix) with ESMTP id 17E993A6999 for ; Tue, 9 Dec 2008 15:01:59 -0800 (PST) Received: by gxk5 with SMTP id 5so237514gxk.18 for ; Tue, 09 Dec 2008 15:01:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=2Ni2uBA4iSDLYclZPqg5CyUAd5frwuHL6yXbleDWkVs=; b=XquwWbKtjfdP2ab/uBS9P6jTLNPHRMCvvzAZE4GcKfefrcTyRiH5lh4xvDqniMjN1k CivxEssflpLbImQS1+gl0JobIqOS1onRon2UgDZVhgt/qSdXU7ShsdvsJZ+8xITXKa81 ANWqdttyneq5TX68NUvfF54Y8nkp7fA32D2IQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=Yjlh0nV57m/NYpN3VS19U3nTngKGAidiaQ1JQhtsll1/vVzmwnB04FXpM8gzxKc9/E phHHFYN2wvI4ySSNsUqBzyriDAdzY3yEBKJlJltlvhhVNTXWyX7O1BfjY1Mwj7/aHz5Z T8V8OKi56s09ht7KC+uQyEUJBdYxqcPRMj1tM= Received: by 10.151.113.5 with SMTP id q5mr845806ybm.134.1228863567712; Tue, 09 Dec 2008 14:59:27 -0800 (PST) Received: by 10.150.152.5 with HTTP; Tue, 9 Dec 2008 14:59:27 -0800 (PST) Message-ID: <44680fe70812091459n2eadbcddjc9a5a5f30aa2acb4@mail.gmail.com> Date: Tue, 9 Dec 2008 14:59:27 -0800 From: "Stephen Dawson-Haggerty" To: "Thomas Heide Clausen" In-Reply-To: <710F3638-03FD-460F-8AB2-DC4100832F3B@thomasclausen.org> MIME-Version: 1.0 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <710F3638-03FD-460F-8AB2-DC4100832F3B@thomasclausen.org> X-Google-Sender-Auth: b30c7625dd1ce3c9 Cc: charliep@computer.org, roll@ietf.org Subject: Re: [Roll] Review and concerns (was: Re: Working Group Last Call: draft-ietf-roll-protocols-survey-02) X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============0658062665==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0658062665== Content-Type: multipart/alternative; boundary="----=_Part_45295_14217143.1228863567738" ------=_Part_45295_14217143.1228863567738 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks for all the constructive comments. I think the general objections are either that the document does too little, but well, or it does too much, but poorly. We have tried and will continue to try to address any technical objections to the document; however as the chairs have pointed out, the document is by nature insufficient to make a great number of statements about this sort of networking. It does seem that there is a rough consensus (irrespective of this document) that no existing IP-based networking specification is actually going to work in these networks, and so more work is needed. On Mon, Dec 8, 2008 at 8:00 AM, Thomas Heide Clausen wrote: > Dear All, > > I've been reviewing the latest incarnation of this I-D, and I have a couple > of general concerns with this I-D and, more specifically, with the approach > it seems to be suggesting for the working group. > > o The document seems to set the bar of acceptance at "the > holy grail of a routing protocol", > i.e. defines "acceptable" to be "zero-cost [more on that in > a following bullet], > instant-convergence" -- thereby causing all routing > protocols to almost by definition be > judged "insufficient" -- which is reflected in the > evaluation of the existing set of routing > protocols. Agreeing with Phil's comments, I'm also not sure I've heard other people voice concerns that the criteria of this draft are impossible; this may have actually been the case before the infirm meeting, but I don't think is the case now. I don't see any reason we can't build or modify (I'm not taking a position on which one) a protocol to meet these goals, since several existing protocols seem to come close, and techniques to meet each goal seem to be relatively well understood. > > > o As I assume ROLL is designing "for the real world", > compromises and trade-offs are > paramount in protocol design. By elevating a set of criteria > (sec. 3 and 4 -- "table scalability", > "loss response", "control cost", "link cost" and "node > cost") above the rest, while pointing out > that (i) an approach not meeting the bar on all of those is > unacceptable and (ii) "applications > introduce additional, more stringent, requirements", this > I-D effectively limits the trade-offs > possible for when designing protocols for these > applications. > > o From the previous point, it is not convincing that > eliminating these trade-offs is justified. > While I believe that indeed *any* application would welcome > "the holy grail of a routing > protocol", recognizing that such may not exist, it may for > some application be right to > trade off, say, "higher control cost" against "low memory > footprint". Something which is > explicitly excluded (2nd paragraph section 4). > > o Going by where the bar for acceptance is set in this > document, I have thought and come > up with indeed two solutions that have > "zero-cost-instant-convergence" properties, and > they both satisfy the IP delivery semantics. One is "drop > all traffic, don't even try" and the > other is "flood all traffic, don't maintain a routing > table". > > Of course, those two proposals are in jest, as I am sure > that the trade-off I am making > -- sacrificing delivery ratio for the former, satisfying > network traffic and energy (but not > as a consequence of the routing protocol relaying control > traffic) for the latter are not > acceptable in an absolute sense -- but the routing protocol > will itself require have > zero-cost, zero-memory, instant-convergence. > > o From the previous and first bullet, "control cost" is an > insufficient measure. "Flooding all > data" has zero "control cost" but a large overall cost (many > retransmissions, lots of battery > drain, lots of media use). A routing protocol incurring some > "control cost" to gain lower > "data transmission cost" likely is a better tradeoff, > especially if data traffic is a common > occurrence in the network. > > IOW, looking at "control cost" as a separate metric is not > terribly useful unless the > consequences in terms of the "data cost" and "data delivery > ratio" are considered > as well. > > Chris Dearlove summarize well in saying that the document does well in > setting out a rigid set of "pass" criteria and observing that none of the > six protocols analyzed satisfies those off-the-shel -- but that this should > not be stretched to assume that an entirely new design is required. No, it should not be stretched to say this. > > > I also join Chris in his comment that, for example, OLSRv2 offers "timing > backoff" and "fisheye variable flooding" without variations to the routing > protocol [the specificities of how to set timers or vary flooding is a > policy matter that is dependent on deployment, but can be done entirely > conformant with its specification] -- and that this is not considered. I'll > go further than Chris and suggest that not considering the use of such > options, which are present in the protocols but where a policy specification > dependent on deployment is required, casts doubt on the assessment of the > protocols as presented - not just OLSRv2, but such options exist for other > protocols as well. > > I'll send another email with "nits" to the document, however I feel that > the issues above need to be discussed and resolved. > > Cheers, > > Thomas > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > ------=_Part_45295_14217143.1228863567738 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks for all the constructive comments.  I think the general objections are either that the document does too little, but well, or it does too much, but poorly.  We have tried and will continue to try to address any technical objections to the document; however as the chairs have pointed out, the document is by nature insufficient to make a great number of statements about this sort of networking.  It does seem that there is a rough consensus (irrespective of this document) that no existing IP-based networking specification is actually going to work in these networks, and so more work is needed. 

On Mon, Dec 8, 2008 at 8:00 AM, Thomas Heide Clausen <ietf@thomasclausen.org> wrote:
Dear All,

I've been reviewing the latest incarnation of this I-D, and I have a couple of general concerns with this I-D and, more specifically, with the approach it seems to be suggesting for the working group.

       o       The document seems to set the bar of acceptance at  "the holy grail of a routing protocol",
               i.e. defines "acceptable" to be "zero-cost [more on that in a following bullet],
               instant-convergence" -- thereby causing all routing protocols to almost by definition be
               judged "insufficient" -- which is reflected in the evaluation of the existing set of routing
               protocols.
 
Agreeing with Phil's comments, I'm also not sure I've heard other people voice concerns that the criteria of this draft are impossible; this may have actually been the case before the infirm meeting, but I don't think is the case now.  I don't see any reason we can't build or modify (I'm not taking a position on which one) a protocol to meet these goals, since several existing protocols seem to come close, and techniques to meet each goal seem to be relatively well understood. 
 

       
       o       As I assume ROLL is designing "for the real world", compromises and trade-offs are
               paramount in protocol design. By elevating a set of criteria (sec. 3 and 4 -- "table scalability",
               "loss response", "control cost", "link cost" and "node cost") above the rest, while pointing out
               that (i) an approach not meeting the bar on all of those is unacceptable and (ii) "applications
               introduce additional, more stringent, requirements", this I-D effectively limits the trade-offs
               possible for when designing protocols for these applications.

       o       From the previous point, it is not convincing that eliminating these trade-offs is justified.
               While I believe that indeed *any* application would welcome "the holy grail of a routing
               protocol", recognizing that such may not exist, it may for some application be right to
               trade off, say, "higher control cost" against  "low memory footprint". Something which is
               explicitly excluded (2nd paragraph section 4).

       o       Going by where the bar for acceptance is set in this document, I have thought and come
               up with indeed two solutions that have "zero-cost-instant-convergence" properties, and
               they both satisfy the IP delivery semantics. One is "drop all traffic, don't even try" and the
               other is "flood all traffic, don't maintain a routing table".

               Of course, those two proposals are in jest, as I am sure that the trade-off I am making
               -- sacrificing delivery ratio for the former, satisfying network traffic and energy (but not
               as a consequence of the routing protocol relaying control traffic) for the latter are not
               acceptable in an absolute sense -- but the routing protocol will itself require have
               zero-cost, zero-memory, instant-convergence.

       o       From the previous and first bullet, "control cost" is an insufficient measure. "Flooding all
               data" has zero "control cost" but a large overall cost (many retransmissions, lots of battery
               drain, lots of media use). A routing protocol incurring some "control cost" to gain lower
               "data  transmission cost" likely is a better tradeoff, especially if data traffic is a common
               occurrence in the network.

               IOW, looking at "control cost" as a separate metric is not terribly useful unless the
               consequences in terms of the "data cost" and "data delivery ratio" are considered
               as well.

Chris Dearlove summarize well in saying that the document does well in setting out a rigid set of "pass" criteria and observing that none of the six protocols analyzed satisfies those off-the-shel -- but that this should not be stretched to  assume that an entirely new design is required.

No, it should not be stretched to say this.
 


I also join Chris in his comment that, for example, OLSRv2 offers "timing backoff" and "fisheye variable flooding" without variations to the routing protocol [the specificities of how to set timers or vary flooding is a policy matter that is dependent on deployment, but can be done entirely conformant with its specification] -- and that this is not considered. I'll go further than Chris and suggest that not considering the use of such options, which are present in the protocols but where a policy specification dependent on deployment is required, casts doubt on the assessment of the protocols as presented - not just OLSRv2, but such options exist for other protocols as well.

I'll send another email with "nits" to the document, however I feel that the issues above need to be discussed and resolved.

Cheers,

Thomas

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

------=_Part_45295_14217143.1228863567738-- --===============0658062665== 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 --===============0658062665==-- From roll-bounces@ietf.org Tue Dec 9 15:23:07 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7F733A687B; Tue, 9 Dec 2008 15:23:07 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 005CC3A687B for ; Tue, 9 Dec 2008 15:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPLvZwpuPa0P for ; Tue, 9 Dec 2008 15:23:05 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by core3.amsl.com (Postfix) with ESMTP id 73EEE3A680B for ; Tue, 9 Dec 2008 15:23:04 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id b11so61011nfh.39 for ; Tue, 09 Dec 2008 15:22:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=ANL/IQ/jxFL74ngdoqX0uC9s+8ddvC/AKxh2bQZsqRQ=; b=w/dgnFFRRQnBGMJ9IHDzK2Z3PLThLYh5f0O/UliYJxC1st+r9qMCdMrNTPdzZvIVjH XwhJ7k0JamO3v7PJdlmlbagYJSjX/9nWJRjO+ivFErJYEhGiEHCdnw1wsD49ZBlEu2G3 ItrtGvQo0lCpfwJPPTBZDmTu4EM8oAxtLL+VM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=LtHOxj3Gy4gwxg6r3U8LdgbBO20UjhLHxhJtb2fMeccHFA2VUsSmDdBtqSiLSf/rVr yL9/bz8VwWOJTbAOkmlGGXk1ZNEF2jVzZKbmeasHlEWQFhqSz0v1KKFbrItMnKhtdMMq jpjeNd7ydo5cEQq4BqldWMSBZWxq6M9PUvWYA= Received: by 10.210.131.6 with SMTP id e6mr839644ebd.77.1228864977848; Tue, 09 Dec 2008 15:22:57 -0800 (PST) Received: by 10.210.58.16 with HTTP; Tue, 9 Dec 2008 15:22:57 -0800 (PST) Message-ID: <69306dde0812091522s43ee9e09p773173e22926af41@mail.gmail.com> Date: Tue, 9 Dec 2008 15:22:57 -0800 From: "Arsalan Tavakoli" To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC06ADE38A@xmb-ams-337.emea.cisco.com> MIME-Version: 1.0 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC06ADE328@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC06ADE38A@xmb-ams-337.emea.cisco.com> X-Google-Sender-Auth: ba0f1bf6f37e6213 Cc: roll@ietf.org Subject: Re: [Roll] Working GroupLastCall:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============1447189468==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1447189468== Content-Type: multipart/alternative; boundary="----=_Part_99904_11674571.1228864977835" ------=_Part_99904_11674571.1228864977835 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Just saw David's email after I'd written this, so mine definitely has some overlap with that, but thought I'd still send it out. --------------------------------------- Sorry to get into the fray so late. I feel that some of the conversations that we are having at this point seem to be like deja-vu, as we had debated them (and I thought reached a consensus) previously. I join Phil in welcoming suggestions as to change in text in the document needed to more explicitly state our purpose. >From an evaluation criteria standpoint, as is the case with an survey document, there are additional metrics that could have been considered. Bu= t we were very precise about this: this document lays out the requirements that are necessary, but may not be sufficient for any protocol in the space= . The derivation of these metrics came from a set of requirements documents, written by authors with design/implementation/deployment experience in each of the application domains. While these application domains don't portend to encompass all possible L2N deployments, they do compose a significant majority, and hence serve as a valid derivation source for our metrics. A lot of the comments have harped on the 'control cost' criteria, saying that there is an inherent trade-off between delivery ratio/path latency and the amount of control traffic. This would be a valid complaint if we had rejected all current protocols as untenable, and introduced a new protocol from scratch that meets the control cost criteria and say this is the protocol for ROLL. However, first of all, the document specifically states that the set of criteria is necessary, not sufficient. Furthermore, when the next step looks at selecting a protocol (either through extension/tweak or from scratch), closer attention will be paid to other criteria, potentially on a per-application-domain basis, at which point a given existing protocol's trade-off decision can be revisited, tweaked, and submitted as an applicable protocol that meets the criteria, if possible. That is NOT, and I repeat not, the purpose of this document. In terms of the set of protocols chosen, this list was set out, pruned, and agreed upon by members of the working group. The specific requirements for any protocol to be considered (as laid out by the charter), is that it has to be an IETF protocol with an accompanying RFC (or in one or two cases, a very mature internet draft). We realize that there are actual implementations that have been tweaked, extensions documented as conference publications, and the like; however, as the ROLL charter points out, the protocol that is adopted must be in the form of an RFC specification. Now, one of the comments made was that there might be some other protocols. Eve= n given that we achieved consensus as a WG on this list or protocols, if ther= e is a protocol that meets all the criteria (and is specified in an RFC), the= n obviously we would be glad to consider it and make this process simpler. However, if not, then that does not affect this I-D at all, and rather is more pertinent to the subsequent step. I feel that a great deal of debate has revolved around a misunderstanding o= f what this document is intended to do. This document simply seeks to identify a set of quantifiable evaluation criteria, based on criteria specifically laid out by application-domain experts, as necessary for any ROLL routing protocol. A set of existing IETF IP-based protocols must then be evaluated against these criteria, using only strict interpretations of RFC specifications (as required by the ROLL charter), to determine if any existing protocol satisfies these requirements as-is. That is it. Any other implications are being drawn mistakenly and are not part of this document (only showing that the document is in fact serving its purpose of providing a foundation to debate next steps). The consensus reached by thi= s WG on the mailing list and in meetings, is that none of the protocols meet all the requirements, as-is. What this simply means, is that a new RFC specification will need to be written for a ROLL protocol, and hence we nee= d to recharter. However, we absolutely take NO position in the document in terms of whether an existing protocol can be modified/extended or whether a completely new protocol from scratch is needed. That is a debate that determines the future direction of the WG, but is not pertinent to this document. When a protocol 'fails', this does not imply that it is untenable; rather, it implies that there are shortcomings in protocol (as currently specified) in regards to the requirements of ROLL (which makes sense, since these protocols were designed for different metrics in different environments); addressing these shortcomings to allow the protoco= l to meet the ROLL criteria are a completely viable, but future, option, that should not hinder the progress of this ID. Arsalan On Tue, Dec 9, 2008 at 9:43 AM, Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > Hi Emmanuel, > > I do agree that was particularily infortunate, considering that in > practice, autoconf can very well be a building block of the environment > where ROLL is deployed to perform the routing. We need to alert the A-Ds = to > avoid such mishap in the future. > > I do not necessarily reckon that this lot of people you are talking about > would have necessarily voted against the consensus nor dramatically impac= ted > the vote. I certainly trust that having to choose between the two session= s > was a difficult decision for many, but we do need people willing to work = in > ROLL and for those people, ROLL can hardly be a second priority consideri= ng > the milestones we need to achieve. > > Pascal > ________________________________________ > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Emmanuel Baccelli > Sent: mardi 9 d=E9cembre 2008 18:17 > To: roll@ietf.org > Subject: Re: [Roll] Working > GroupLastCall:draft-ietf-roll-protocols-survey-02 > > Well I guess a lot of interested people could not attend the interim in > California, and a lot of people could not attend the last ROLL meeting in > Minneapolis either because Autoconf was scheduled simultaneously (which w= as > really unfortunate, I hope it does not happen again). > Emmanuel > On Tue, Dec 9, 2008 at 5:45 PM, Pascal Thubert (pthubert) < > pthubert@cisco.com> wrote: > Hi all: > > Having attended the interim, I can concur that there was a clear consensu= s > in the room and through the teleconf. The interim was not as crowded as t= he > previous IETF meeting, yet there were more people there who raised their > hands in favor than there are in a normal meeting considering all the > non-voters in the room. To me that was a clear consensus, better than man= y > I've seen. > > ROLL provides a niche where we can develop a simple and efficient mechani= sm > that might not have all the power and goodies of the bigger brothers but > would fit in a constrained device and do the minimum needed. The project > might fail anyway if what we really want is a dream protocol, but it is > certain to fail if we do not try. If enough people are willing to help, > let's give ROLL a chance. > > Pascal > > >-----Original Message----- > >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Thomas Heide Clausen > >Sent: mardi 9 d=E9cembre 2008 16:08 > >To: JP Vasseur (jvasseur) > >Cc: Emmanuel Baccelli; roll@ietf.org > >Subject: Re: [Roll] Working GroupLast > Call:draft-ietf-roll-protocols-survey-02 > > > >Hi JP, > > > >Posting on a 'list, you run the risk that not just Baccelli respond. > >See below. > > > >On Dec 9, 2008, at 15:53 PM, JP Vasseur wrote: > > > > > > > >>> > >>>> 3 - The draft is not constructive in its current shape. > >>> > >>> I do not think that your comment is fair. The draft has been > >>> discussed in the WG for quite some time and extensive discussion > >>> took place during the interim WG and on the ML. > >>> > >>> > >>> Yes there have been some discussions, but there is no consensus on > >>> the approach taken by this document. > >> > >> Thanks for your feed-back here. What do you propose ? > >> > >>> And there is no rough consensus either. > >>> > >> > >> Please refer to the WG minutes + several emails on the ML, with a > >> good consensus. That being said, I hear you and thanks for your > >> comments. I do register your disagreement. Having read again > >> others' email, I do not think that this is a general feeling. > >> > > > >At this point, I think it fair to raise that in Minneapolis, ROLL and > >AUTOCONF were concurrently scheduled, and that for that reason large > >part of the community (myself included) were unable to attend ROLL. > > > >If scheduling would have permitted, I would have attended, and I > >would have made my concerns be known at the mike (and, hopefully, > >have had those reflected in the minutes as well). > > > >Looking back over the mailing list postings, I also see a number of > >concerns raised by a number of people -- all of whom I know to have > >some experience designing/building/deploying protocols in a space > >similar or identical to ROLL. > > > >So, I do not share the view expressed in your last paragraph above. > > > >Thomas > > > >_______________________________________________ > >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 > ------=_Part_99904_11674571.1228864977835 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Just saw David's email after I'd written this, so mine definit= ely has some overlap with that, but thought I'd still send it out.

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

Sorry to get into the fray so late.  I feel that some of the con= versations that we are having at this point seem to be like deja-vu, as we = had debated them (and I thought reached a consensus) previously.  I jo= in Phil in welcoming suggestions as to change in text in the document neede= d to more explicitly state our purpose.

From an evaluation criteria standpoint, as is the case with = an survey document, there are additional metrics that could have been consi= dered.  But we were very precise about this: this document lays out th= e requirements that are necessary, but may not be sufficient for any protoc= ol in the space.  The derivation of these metrics came from a set of r= equirements documents, written by authors with design/implementation/deploy= ment experience in each of the application domains.  While these appli= cation domains don't portend to encompass all possible L2N deployments,= they do compose a significant majority, and hence serve as a valid derivat= ion source for our metrics.  

A lot of the comments have harped on the 'control c= ost' criteria, saying that there is an inherent trade-off between deliv= ery ratio/path latency and the amount of control traffic.  This would = be a valid complaint if we had rejected all current protocols as untenable,= and introduced a new protocol from scratch that meets the control cost cri= teria and say this is the protocol for ROLL.  However, first of all, t= he document specifically states that the set of criteria is necessary, not = sufficient.  Furthermore, when the next step looks at selecting a prot= ocol (either through extension/tweak or from scratch), closer attention wil= l be paid to other criteria, potentially on a per-application-domain basis,= at which point a given existing protocol's trade-off decision can be r= evisited, tweaked, and submitted as an applicable protocol that meets the c= riteria, if possible.  That is NOT, and I repeat not, the purpose of t= his document.

In terms of the set of protocols chosen, this list was = set out, pruned, and agreed upon by members of the working group.  The= specific requirements for any protocol to be considered (as laid out by th= e charter), is that it has to be an IETF protocol with an accompanying RFC = (or in one or two cases, a very mature internet draft).  We realize th= at there are actual implementations that have been tweaked, extensions docu= mented as conference publications, and the like; however, as the ROLL chart= er points out, the protocol that is adopted must be in the form of an RFC s= pecification.  Now, one of the comments made was that there might be s= ome other protocols.  Even given that we achieved consensus as a WG on= this list or protocols, if there is a protocol that meets all the criteria= (and is specified in an RFC), then obviously we would be glad to consider = it and make this process simpler.  However, if not, then that does not= affect this I-D at all, and rather is more pertinent to the subsequent ste= p.

I feel that a great deal of debate has revolved around = a misunderstanding of what this document is intended to do.  This docu= ment simply seeks to identify a set of quantifiable evaluation criteria, ba= sed on criteria specifically laid out by application-domain experts, as nec= essary for any ROLL routing protocol.  A set of existing IETF IP-based= protocols must then be evaluated against these criteria, using only strict= interpretations of RFC specifications (as required by the ROLL charter), t= o determine if any existing protocol satisfies these requirements as-is. &n= bsp;That is it.  Any other implications are being drawn mistakenly and= are not part of this document (only showing that the document is in fact s= erving its purpose of providing a foundation to debate next steps).  T= he consensus reached by this WG on the mailing list and in meetings, is tha= t none of the protocols meet all the requirements, as-is.  What this s= imply means, is that a new RFC specification will need to be written for a = ROLL protocol, and hence we need to recharter.  However, we absolutely= take NO position in the document in terms of whether an existing protocol = can be modified/extended or whether a completely new protocol from scratch = is needed.  That is a debate that determines the future direction of t= he WG, but is not pertinent to this document.  When a protocol 'fa= ils', this does not imply that it is untenable; rather, it implies that= there are shortcomings in protocol (as currently specified) in regards to = the requirements of ROLL (which makes sense, since these protocols were des= igned for different metrics in different environments); addressing these sh= ortcomings to allow the protocol to meet the ROLL criteria are a completely= viable, but future, option, that should not hinder the progress of this ID= .

Arsalan



On Tue, Dec 9, 2008 at 9:43 AM, Pascal Thube= rt (pthubert) <pthubert@cisco.com> wrote:
Hi Emmanuel,

I do agree that was particularily infortunate, considering that in practice= , autoconf can very well be a building block of the environment where ROLL = is deployed to perform the routing. We need to alert the A-Ds to avoid such= mishap in the future.

I do not necessarily reckon that this lot of people you are talking about w= ould have necessarily voted against the consensus nor dramatically impacted= the vote. I certainly trust that having to choose between the two sessions= was a difficult decision for many, but we do need people willing to work i= n ROLL and for those people, ROLL can hardly be a second priority consideri= ng the milestones we need to achieve.

Pascal
________________________________________
From: roll-bounc= es@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Emmanuel Baccelli
Sent: mardi 9 d=E9cembre 2008 18:17
To: roll@ietf.org Subject: Re: [Roll] Working GroupLastCall:draft-ietf-roll-protocols-survey-= 02

Well I guess a lot of interested people could not attend the interim in Cal= ifornia, and a lot of people could not attend the last ROLL meeting in Minn= eapolis either because Autoconf was scheduled simultaneously (whi= ch was really unfortunate, I hope it does not happen again).
Emmanuel
On Tue, Dec 9, 2008 at 5:45 PM, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote= :
Hi all:

Having attended the interim, I can concur that there was a clear consensus = in the room and through the teleconf. The interim was not as crowded as the= previous IETF meeting, yet there were more people there who raised their h= ands in favor than there are in a normal meeting considering all the non-vo= ters in the room. To me that was a clear consensus, better than many I'= ve seen.

ROLL provides a niche where we can develop a simple and efficient mechanism= that might not have all the power and goodies of the bigger brothers but w= ould fit in a constrained device and do the minimum needed. The project mig= ht fail anyway if what we really want is a dream protocol, but it is certai= n to fail if we do not try. If enough people are willing to help, let's= give ROLL a chance.

Pascal

>-----Original Message-----
>From: roll-b= ounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Thomas Heide Clausen >Sent: mardi 9 d=E9cembre 2008 16:08
>To: JP Vasseur (jvasseur)
>Cc: Emmanuel Baccelli; roll@ietf.org
>Subject: Re: [Roll] Working GroupLast Call:draft-ietf-roll-protocols-su= rvey-02
>
>Hi JP,
>
>Posting on a 'list, you run the risk that not just Baccelli respond= .
>See below.
>
>On Dec 9, 2008, at 15:53 PM, JP Vasseur wrote:
>
><SNIP>
>
>>>
>>>> 3 - The draft is not constructive in its current shape. >>>
>>> I do not think that your comment is fair. The draft has been >>> discussed in the WG for quite some time and extensive discussi= on
>>> took place during the interim WG and on the ML.
>>>
>>>
>>> Yes there have been some discussions, but there is no consensu= s on
>>> the approach taken by this document.
>>
>> Thanks for your feed-back here. What do you propose ?
>>
>>> And there is no rough consensus either.
>>>
>>
>> Please refer to the WG minutes + several emails on the ML, with a<= br> >> good consensus. That being said, I hear you and thanks for your >> comments. I do register your disagreement. Having read again
>> others' email, I do not think that this is a general feeling.<= br> >>
>
>At this point, I think it fair to raise that in Minneapolis, ROLL and >AUTOCONF were concurrently scheduled, and that for that reason  la= rge
>part of the community (myself included) were unable to attend ROLL.
>
>If scheduling would have permitted, I would have attended, and I
>would have made my concerns be known at the mike (and, hopefully,
>have had those reflected in the minutes as well).
>
>Looking back over the mailing list postings, I also see a number of
>concerns raised by a number of people -- all of whom I know to have
>some experience designing/building/deploying protocols in a space
>similar or identical to ROLL.
>
>So, I do not share the view expressed in your last paragraph above.
>
>Thomas
>
>_______________________________________________
>Roll mailing list
>Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll

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

------=_Part_99904_11674571.1228864977835-- --===============1447189468== 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 --===============1447189468==-- From roll-bounces@ietf.org Tue Dec 9 15:37:23 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACAAF3A6B53; Tue, 9 Dec 2008 15:37:23 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD7783A6B4E for ; Tue, 9 Dec 2008 15:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ha9-CP0VF0FK for ; Tue, 9 Dec 2008 15:37:21 -0800 (PST) Received: from smtp110.biz.mail.re2.yahoo.com (smtp110.biz.mail.re2.yahoo.com [206.190.53.9]) by core3.amsl.com (Postfix) with SMTP id F2E373A6B24 for ; Tue, 9 Dec 2008 15:37:20 -0800 (PST) Received: (qmail 20304 invoked from network); 9 Dec 2008 23:37:14 -0000 Received: from unknown (HELO ?192.168.0.207?) (anand@209.48.242.70 with plain) by smtp110.biz.mail.re2.yahoo.com with SMTP; 9 Dec 2008 23:37:13 -0000 X-YMail-OSG: LRG8am8VM1mKYTgJxkxNpaXkpRMt0RpLzsspVmLFUq936L4BxkZjKQxJ4ncACKep05E.Ie2UgaYwP17GX7fYvyTokSO7zw5rjhHUk4edBks5X3Br7dubA7JLQdtZlSDH6tM- X-Yahoo-Newman-Property: ymail-3 Message-ID: <493F02C9.1060001@ekasystems.com> Date: Tue, 09 Dec 2008 18:44:09 -0500 From: "M. B. Anand" User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: roll@ietf.org References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> In-Reply-To: Subject: Re: [Roll] Working Group Last Call:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Emmanuel Baccelli wrote: > > > > Yes there have been some discussions, but there is no consensus on the > approach taken by this document. And there is no rough consensus either. > I think rather that there was actually clear consensus on the mailing list. I think the document serves adequately its narrow purpose of evaluating the suitability of existing IETF protocols for their suitability for intersection of ROLL requirements. I think there may be extrapolations/impressions that are formed based on this document that lead us into discussions of dream protocols and such but the intent of the document is not to dictate what the next steps should be. I think on this basis there was consensus and I will re-iterate here my support for this document. - Anand. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Dec 9 15:44:33 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A96D63A687E; Tue, 9 Dec 2008 15:44:33 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2CCD3A687E for ; Tue, 9 Dec 2008 15:44:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, WEIRD_PORT=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 jyQeF-5NvbPO for ; Tue, 9 Dec 2008 15:44:31 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 5C52E3A687B for ; Tue, 9 Dec 2008 15:44:31 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id C1870AF8BB; Tue, 9 Dec 2008 15:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrl72Wa22PYE; Tue, 9 Dec 2008 15:44:25 -0800 (PST) Received: from [192.168.7.78] (69-12-164-140.sfo.archrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id CA500AF867; Tue, 9 Dec 2008 15:44:24 -0800 (PST) Message-Id: <1FE7701C-340A-4226-8235-A2A228FA3096@archrock.com> From: Jonathan Hui To: Kris Pister In-Reply-To: <493EE0E0.2070406@eecs.berkeley.edu> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 9 Dec 2008 15:44:23 -0800 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> <493EE0E0.2070406@eecs.berkeley.edu> X-Mailer: Apple Mail (2.929.2) Cc: roll@ietf.org Subject: Re: [Roll] Working Group LastCall:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org I'd also add that IP-based solutions that meet the criteria in the survey doc have also been shipping commercially for over two years. You can find a high-level description of one such solution as well as empirical results from a real application deployment in [1]. Open- source solutions exist as well [2]. They are not standardized nor are they specified in RFCs, and for that reason, they are not discussed in the survey doc. [1] http://www.cs.berkeley.edu/~jwhui/pubs/jhui-sensys08-ipv6.pdf [2] http://smote.cs.berkeley.edu:8000/tracenv/wiki/b6loWPAN -- Jonathan Hui On Dec 9, 2008, at 1:19 PM, Kris Pister wrote: > Christopher - > the fact that existing protocols are proprietary makes it difficult > to deliver on your request. > Proprietary protocols are generally not publicly documented, hence > the desire to have an > IETF standard. > I can point you to IEC PAS (Publicly Available Specification) > 62591, which describes the > Wireless HART protocol, but 1) despite the name it's still a few > months away from actually > being "public", and 2) it describes all of the mechanisms for > gathering and disseminating > routing information but does not actually specify how the routing > engine makes it's decisions. > That information is at this point truly proprietary. > > The proof that it works has been in the field for almost two years > now, and there are many > companies building and shipping it. I believe that at least one > implementation satisfies all of the > RoLL IDs tests, not just the five in the protocol survey document. > This protocol is not discussed in the survey document because 1) > it's not an IETF protocol, > 2) reasons 2 through N are irrelevant, reason #1 is enough. > > Protocols exist that do what we want, they just haven't made it into > RFCs yet. > > ksjp > > Dearlove, Christopher (UK) wrote: >> >>> 2- There is clearly a need for a solution *today*: look at all other >>> (deployed) non IP solutions out there >>> >> >> >>> 4- We are not talking about a "dream protocol": again this is very >>> much realistic since solutions do exist today (not IP unfortunately >>> >> :-( ....) >> >> Can you point me to an existing (doesn't have to be IP) protocol >> that passes all five of the ID's tests, without some major drawback >> in some other area. I for one would find it interesting and useful. >> (Obviously it would have to have a specification, not just a claim >> made about a proprietary protocol.) >> >> If one or more such protocols exist, I don't see why they aren't >> discussed at this stage. >> >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Dec 10 08:36:00 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43DBA28C161; Wed, 10 Dec 2008 08:36:00 -0800 (PST) X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 952AF3A690D; Wed, 10 Dec 2008 08:35:57 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20081210163557.952AF3A690D@core3.amsl.com> Date: Wed, 10 Dec 2008 08:35:57 -0800 (PST) Cc: roll@ietf.org Subject: [Roll] Last Call: draft-ietf-roll-home-routing-reqs (Home Automation Routing Requirements in Low Power and Lossy Networks) to Informational RFC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org The IESG has received a request from the Routing Over Low power and Lossy networks WG (roll) to consider the following document: - 'Home Automation Routing Requirements in Low Power and Lossy Networks ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-12-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-reqs-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17265&rfc_flag=0 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Dec 10 08:43:52 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F24CA3A6955; Wed, 10 Dec 2008 08:43:51 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D9473A690D for ; Wed, 10 Dec 2008 08:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQlVdC1NRFyO for ; Wed, 10 Dec 2008 08:43:49 -0800 (PST) Received: from smtp102.biz.mail.re2.yahoo.com (smtp102.biz.mail.re2.yahoo.com [68.142.229.216]) by core3.amsl.com (Postfix) with SMTP id 14B583A68DD for ; Wed, 10 Dec 2008 08:43:48 -0800 (PST) Received: (qmail 61997 invoked from network); 10 Dec 2008 16:43:42 -0000 Received: from unknown (HELO zeke.ekasystems.com) (tim.winter@209.48.242.70 with plain) by smtp102.biz.mail.re2.yahoo.com with SMTP; 10 Dec 2008 16:43:41 -0000 X-YMail-OSG: 0fq2loMVM1kd1FOxo05.VpidZ8szipYqsYAJi8nCAw78kiZRujTVtNwBztSBbnmHP6EvSgZzmNXRAryRFb5dOHiN2MbPFOB6aTWfW34ZtQq_AgRlZlYKhAk0aRv4l0lxdprj5cWyGrZ1mqiPJgqeB6WewjsuJIZcGkVaeJT_7dmdKyoj2pLMcKnlr7PD X-Yahoo-Newman-Property: ymail-3 Message-ID: <493FF1B9.3080507@ekasystems.com> Date: Wed, 10 Dec 2008 11:43:37 -0500 From: Tim Winter User-Agent: Thunderbird 2.0.0.18 (X11/20081105) MIME-Version: 1.0 To: roll@ietf.org References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> <3CEA849E-22CD-4DF1-A56B-E1C38572AA77@cisco.com> <6A3B39C4-8126-47D0-B29A-752191F4F487@cs.stanford.edu> In-Reply-To: <6A3B39C4-8126-47D0-B29A-752191F4F487@cs.stanford.edu> Subject: Re: [Roll] Working Group Last Call:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org I think Phil has phrased it very concisely and I second his statements. Existing (as is) IETF protocols are the extent of the scope of the survey. Whether or not (unspecified) "tweaks and tunings and potential extensions" can change the conclusion of with regard to an existing protocol is beyond the scope and intent of the survey. I am not aware of a fault in the analysis of existing protocols as such, and I agree with the criteria that have been established. Given this, and the intended scope, I reiterate my support of draft-ietf-roll-protocols-survey-02. If you have some ideas on how to tweak/tune/extend to existing protocols, or know of non-IETF protocols with desirable traits, please keep around... Such input may be needed in the future (to see if recommendations can be made to other WG such that existing protocols can be adapted, or if new protocol needs to be designed/incorporated into IETF). I can attest to the fact that the industry needs a standard routing solution. Proprietary LLNs are being deployed *now*. I would like to see a viable, open, and standard IETF protocol emerge that is capable of meeting industry needs in a timely manner. -Tim Philip Levis wrote: > > On Dec 9, 2008, at 7:30 AM, JP Vasseur wrote: >> >> Please find below the minutes of the ROLL Interim Working Group >> meeting that was help in San Jose on Oct 6. >> >> This was an excellent very productive meeting where we managed to >> make good progress and reached a consensus on an important question >> related to a key Milestone.As usual such consensus must be confirmed >> on the mailing list. >> >> When ROLL got chartered, one of our key milestones was to determined >> after some careful analysis of the routing requirements whether or >> not we could find an existing protocols that would meet our routing >> requirement with no change (with no protocol changes). All >> participants to the interim meeting agreed that there was no existing >> protocol that would meet the ROLL routing requirements *with no >> protocol work*. Do not hesitate to express your opinion on the >> mailing list before Oct 17 and then we will document the WG decision. > > I think this is the key point. > > The #1 question is whether the concerns on structure, criteria, etc. > will change the conclusion of the document. If someone has strong > evidence that existing protocols, as specified, can meet the > requirements of ROLL, then that information would be of fantastic use > and value to ROLL. But we seem to have consensus on this point: > existing IETF specifications do not meet the requirements L2Ns introduce. > > More specifically, if there's a disagreement with the conclusion of > the document, then this means one of two things: > > 1) The analysis of an existing protocol is incorrect > 2) A criterion is too harsh and should be weaker > > The domain experts who have written the application drafts are the > best commentators on 2); in fact, one of the criteria (control cost) > did relax slightly based on feedback at the interim meeting. > > So this leaves 1). The authors of TBRPF made some very helpful > comments on the TBRPF analysis early in the document's lifetime, and > we amended it appropriately. If there are other entries that are > incorrect, then a statement of the correct analysis would be the best > way to make the document more accurate. > > Everything else besides this is really ancillary; we can debate at > length whether there should be 4, 5, or 8 criteria, but if the > conclusion is the same, then all this debate does is stifle ROLL from > doing useful work. > > Of course the document can be improved and comments are welcome. In > the last revision, a few readers pointed out many things which were > unclear, and which Stephen, Arsalan, and I tried to clarify. For > example, it's critical that the document be very transparent on the > methodology it uses and how it reaches its conclusions. > > 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 Dec 10 10:49:33 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D05713A6885; Wed, 10 Dec 2008 10:49:33 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D4EB3A6862 for ; Wed, 10 Dec 2008 10:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCNiG3XFrPRu for ; Wed, 10 Dec 2008 10:49:31 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id EE0423A63EC for ; Wed, 10 Dec 2008 10:49:30 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so288423yxg.49 for ; Wed, 10 Dec 2008 10:49:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=Q6FOJPlNx6HmncnoR+c5dbk8mXj19drfj3PPdkpL9R8=; b=DFbKXq+p89p5cxG0Y4Wt6RM2LnmaScL8IEqwnS4pnFvvaQpeZom5if4D9mfmV9pOb4 MualPHNeGm4DuxPxxXIu4Hkvk+xiuKY2Kx0Zdkd6ya2ac6N9rmtisExZ1xZMv4F/4ER0 7mg5Ogi6zjlfRDgkAAOPQaNzkzUH06GHuy118= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=wP3jMeHBRUJjrAwEFx8FkTDFuKNw00yCebMZqSE8v1GEgCLxmJbRVDmLn9QDWqOgi4 UMwdbA55QKvKMUH6BwuANZBiWVdhA0F+mVcuPqPaIkWtYPm1mAN2mlsAaSskjuZc+bt+ TOQxAIU6kpltmlaVAmrB+/qEUsb0aZL6VvJH4= Received: by 10.90.65.5 with SMTP id n5mr1050008aga.14.1228934962978; Wed, 10 Dec 2008 10:49:22 -0800 (PST) Received: by 10.90.116.12 with HTTP; Wed, 10 Dec 2008 10:49:22 -0800 (PST) Message-ID: Date: Wed, 10 Dec 2008 10:49:22 -0800 From: "Omprakash Gnawali" To: "Tim Winter" In-Reply-To: <493FF1B9.3080507@ekasystems.com> MIME-Version: 1.0 Content-Disposition: inline References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <3CEA849E-22CD-4DF1-A56B-E1C38572AA77@cisco.com> <6A3B39C4-8126-47D0-B29A-752191F4F487@cs.stanford.edu> <493FF1B9.3080507@ekasystems.com> X-Google-Sender-Auth: 5d9e31481f04119b Cc: roll@ietf.org Subject: Re: [Roll] Working Group Last Call:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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 wish the analysis of the routing table size had gone beyond the big-O analysis considering we already know the rough number of destinations, depth of the network, and the total number of nodes. For pass/fail analysis, something like "if a protocol requires tens of thousands of entries, fail". Granted absolute bounds on many metrics depend on density and what the network is trying to optimize, at least this particular metric seems amenable to a more concrete analysis. I don't think it is a requirement that we use big-O for all the metrics. - om_p On Wed, Dec 10, 2008 at 8:43 AM, Tim Winter wrote: > I think Phil has phrased it very concisely and I second his statements. > Existing (as is) IETF protocols are the extent of the scope of the > survey. Whether or not (unspecified) "tweaks and tunings and potential > extensions" can change the conclusion of with regard to an existing > protocol is beyond the scope and intent of the survey. > > I am not aware of a fault in the analysis of existing protocols as such, > and I agree with the criteria that have been established. Given this, > and the intended scope, I reiterate my support of > draft-ietf-roll-protocols-survey-02. > > If you have some ideas on how to tweak/tune/extend to existing > protocols, or know of non-IETF protocols with desirable traits, please > keep around... Such input may be needed in the future (to see if > recommendations can be made to other WG such that existing protocols can > be adapted, or if new protocol needs to be designed/incorporated into IETF). > > I can attest to the fact that the industry needs a standard routing > solution. Proprietary LLNs are being deployed *now*. I would like to > see a viable, open, and standard IETF protocol emerge that is capable of > meeting industry needs in a timely manner. > > -Tim > > > > Philip Levis wrote: >> >> On Dec 9, 2008, at 7:30 AM, JP Vasseur wrote: >>> >>> Please find below the minutes of the ROLL Interim Working Group >>> meeting that was help in San Jose on Oct 6. >>> >>> This was an excellent very productive meeting where we managed to >>> make good progress and reached a consensus on an important question >>> related to a key Milestone.As usual such consensus must be confirmed >>> on the mailing list. >>> >>> When ROLL got chartered, one of our key milestones was to determined >>> after some careful analysis of the routing requirements whether or >>> not we could find an existing protocols that would meet our routing >>> requirement with no change (with no protocol changes). All >>> participants to the interim meeting agreed that there was no existing >>> protocol that would meet the ROLL routing requirements *with no >>> protocol work*. Do not hesitate to express your opinion on the >>> mailing list before Oct 17 and then we will document the WG decision. >> >> I think this is the key point. >> >> The #1 question is whether the concerns on structure, criteria, etc. >> will change the conclusion of the document. If someone has strong >> evidence that existing protocols, as specified, can meet the >> requirements of ROLL, then that information would be of fantastic use >> and value to ROLL. But we seem to have consensus on this point: >> existing IETF specifications do not meet the requirements L2Ns introduce. >> >> More specifically, if there's a disagreement with the conclusion of >> the document, then this means one of two things: >> >> 1) The analysis of an existing protocol is incorrect >> 2) A criterion is too harsh and should be weaker >> >> The domain experts who have written the application drafts are the >> best commentators on 2); in fact, one of the criteria (control cost) >> did relax slightly based on feedback at the interim meeting. >> >> So this leaves 1). The authors of TBRPF made some very helpful >> comments on the TBRPF analysis early in the document's lifetime, and >> we amended it appropriately. If there are other entries that are >> incorrect, then a statement of the correct analysis would be the best >> way to make the document more accurate. >> >> Everything else besides this is really ancillary; we can debate at >> length whether there should be 4, 5, or 8 criteria, but if the >> conclusion is the same, then all this debate does is stifle ROLL from >> doing useful work. >> >> Of course the document can be improved and comments are welcome. In >> the last revision, a few readers pointed out many things which were >> unclear, and which Stephen, Arsalan, and I tried to clarify. For >> example, it's critical that the document be very transparent on the >> methodology it uses and how it reaches its conclusions. >> >> Phil >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Dec 11 07:09:41 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D41C73A6C5A; Thu, 11 Dec 2008 07:09:41 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEE073A6C5A for ; Thu, 11 Dec 2008 07:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.370, 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 p2aGIZIVl3FS for ; Thu, 11 Dec 2008 07:09:40 -0800 (PST) Received: from mail-ew0-f17.google.com (mail-ew0-f17.google.com [209.85.219.17]) by core3.amsl.com (Postfix) with ESMTP id 9A3FC3A6A91 for ; Thu, 11 Dec 2008 07:09:39 -0800 (PST) Received: by ewy10 with SMTP id 10so1390827ewy.13 for ; Thu, 11 Dec 2008 07:09:31 -0800 (PST) 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=E9bOw5yLQDa2kKbIHis5thxkRMpFl2iYfRxhu6PvqRU=; b=j3M10pv5yshqUlP9Oe0co7NJwc0p6jwHEAOCrYztnsWnBqHSQVenGp/PxuTjzdubjq K/r/84a+VnCDLW05TL/V2pQh9yh1Ao8XYhuEg3HUHolKs2fCVQckY6HNdEGtwBSZNNMV 2zE8eMz2FXSIUB82qUIEWVVahAfjWMnLfOIxs= 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=LiAvXNvaEHQzGZlHSqhrffx2hWD9/CFHGyQnD5nGRN1Eq40iKqJ6wgT6KCHc8T/p50 Uxfmlu9GMXW0rWEb46nHmnd+8PgeokgW5DZu7FtoIlYBq6tItuhLuMHuN3eUgqCW8Zrw YSkJTWt7IkDgASTGHKnlnyhAbDo1VZtwA/CRs= Received: by 10.103.171.20 with SMTP id y20mr1060512muo.19.1229008171006; Thu, 11 Dec 2008 07:09:31 -0800 (PST) Received: by 10.103.248.12 with HTTP; Thu, 11 Dec 2008 07:09:30 -0800 (PST) Message-ID: Date: Thu, 11 Dec 2008 16:09:30 +0100 From: "Emmanuel Baccelli" To: roll@ietf.org In-Reply-To: <493EF103.7050908@eecs.berkeley.edu> MIME-Version: 1.0 References: <493EF103.7050908@eecs.berkeley.edu> Subject: Re: [Roll] Review and concerns (was: Re: Working Group Last Call: draft-ietf-roll-protocols-survey-02) X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============0543861459==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0543861459== Content-Type: multipart/alternative; boundary="----=_Part_103136_20384629.1229008170960" ------=_Part_103136_20384629.1229008170960 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tue, Dec 9, 2008 at 11:28 PM, David E. Culler wrote: > > > Some concerns recognize that there are protocols outside the defined > universe that should be considered and that appear to be far better suited > to meeting the criteria than the set of IETF protocols that were considered > - since those protocols were developed without these criteria. Again, that > suggests that the criteria are a reasonable guide, that they do not appear > to be unobtainable, and that the analysis has provided a suitable guide. > > None of the comments seem to be claiming that there is a solution within > the universe that we were chartered to consider that meets the criteria. > Even admitting that the universe you defined is wide enough (a point which is actually agued since the beginning), we could conclude to this only if this universe (defined in the charter) is covered entirely. Again, I have seen nothing said about NEMO or DTN, so reports of investigations in these fields need to be included in the draft anyways. Second, if we are not going into aI am still wondering what existing protocols/algorithms, IP compatible or not, are being "hinted at" here. ------=_Part_103136_20384629.1229008170960 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Tue, Dec 9, 2008 at 11:28 PM, David E. Culler <culler@eecs.berkeley.edu> wrote:

Some concerns recognize that there are protocols outside the defined universe that should be considered and that appear to be far better suited to meeting the criteria than the set of IETF protocols that were considered - since those protocols were developed without these criteria.  Again, that suggests that the criteria are a reasonable guide, that they do not appear to be unobtainable, and that the analysis has provided a suitable guide.

None of the comments seem to be claiming that there is a solution within the universe that we were chartered to consider that meets the criteria.


Even admitting that the universe you defined is wide enough (a point which is actually agued since the beginning), we could conclude to this only if this universe (defined in the charter) is covered entirely. Again, I have seen nothing said about NEMO or DTN, so reports of investigations in these fields need to be included in the draft anyways.

Second, if we are not going into aI am still wondering what existing protocols/algorithms, IP compatible or not, are being "hinted at" here.
------=_Part_103136_20384629.1229008170960-- --===============0543861459== 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 --===============0543861459==-- From roll-bounces@ietf.org Thu Dec 11 07:14:16 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 825043A6A33; Thu, 11 Dec 2008 07:14:16 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4D7E3A6A33 for ; Thu, 11 Dec 2008 07:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emeER7VjY5LH for ; Thu, 11 Dec 2008 07:14:14 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id 7D2E73A68B6 for ; Thu, 11 Dec 2008 07:14:13 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so577468fga.41 for ; Thu, 11 Dec 2008 07:14:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=osMJGho2tPktrSohmdw/8+T+UQJGBV9rDG+By0+YA/E=; b=dKX97eC1CkTb8B264Gv/UJj8X7cbfSt5sgkNeiX/YwORvLK5Kdv0yhPOoIDlt+jNTv IFkMZnfrwmaJ3Jx4uMs9szdMy9FFBETbqg734yH6REDXHj9ZbMBPIO6KbZD+Lu9U6+SB SsZWs5x9KlIvWwkK847PrpO1KvVXGiYtvqPM8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=a0Eqd7buNx30EdPsImYlkCpInQY5Jq3De/BgOPssjPwLU0UMgrr7o/Y0a7o24Ylkk0 gGlguhUJUrauA23rTYGAZrBZJSiEHtgVNQLiwqa/KVn5qxKzimXTDWb6aOCYlkkXv04I 6Wl/Eu/WqLi16P+HkmqWu+7W9TJrU+X723MzY= Received: by 10.103.220.7 with SMTP id x7mr1051837muq.89.1229008446368; Thu, 11 Dec 2008 07:14:06 -0800 (PST) Received: by 10.103.248.12 with HTTP; Thu, 11 Dec 2008 07:14:06 -0800 (PST) Message-ID: Date: Thu, 11 Dec 2008 16:14:06 +0100 From: "Emmanuel Baccelli" To: roll@ietf.org In-Reply-To: MIME-Version: 1.0 References: <493EF103.7050908@eecs.berkeley.edu> X-Google-Sender-Auth: 82021e3ddf29a5b2 Subject: Re: [Roll] Review and concerns (was: Re: Working Group Last Call: draft-ietf-roll-protocols-survey-02) X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============0890327110==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0890327110== Content-Type: multipart/alternative; boundary="----=_Part_103192_14242966.1229008446369" ------=_Part_103192_14242966.1229008446369 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Sorry, mistyped, and sent by mistake. So here's the correct, full version of my email, see below: On Thu, Dec 11, 2008 at 4:09 PM, Emmanuel Baccelli < emmanuel.baccelli@gmail.com> wrote: > > > On Tue, Dec 9, 2008 at 11:28 PM, David E. Culler > wrote: >> >> >> Some concerns recognize that there are protocols outside the defined >> universe that should be considered and that appear to be far better suited >> to meeting the criteria than the set of IETF protocols that were considered >> - since those protocols were developed without these criteria. Again, that >> suggests that the criteria are a reasonable guide, that they do not appear >> to be unobtainable, and that the analysis has provided a suitable guide. >> >> None of the comments seem to be claiming that there is a solution within >> the universe that we were chartered to consider that meets the criteria. >> > Even admitting that the universe you defined is wide enough (a point which is actually agued since months), we could conclude to this only if this universe (defined in the charter) is covered entirely. Again, it is not the case: I have seen nothing said about NEMO or DTN, so reports of investigations in these fields need to be included in the draft anyways. Second, if we are not going into a long research phase, I am still wondering what existing protocols/algorithms, IP compatible or not, are being "hinted at" here, which could meet the "dream" criterii that are evoked in the draft. Chris Dearlove and other people have asked this question many times, and it is yet to be answered. Emmanuel ------=_Part_103192_14242966.1229008446369 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Sorry, mistyped, and sent by mistake. So here's the correct, full version of my email, see below:

On Thu, Dec 11, 2008 at 4:09 PM, Emmanuel Baccelli <emmanuel.baccelli@gmail.com> wrote:


On Tue, Dec 9, 2008 at 11:28 PM, David E. Culler <culler@eecs.berkeley.edu> wrote:

Some concerns recognize that there are protocols outside the defined universe that should be considered and that appear to be far better suited to meeting the criteria than the set of IETF protocols that were considered - since those protocols were developed without these criteria.  Again, that suggests that the criteria are a reasonable guide, that they do not appear to be unobtainable, and that the analysis has provided a suitable guide.

None of the comments seem to be claiming that there is a solution within the universe that we were chartered to consider that meets the criteria.

 
Even admitting that the universe you defined is wide enough (a point which is actually agued since months), we could conclude to this only if this universe (defined in the charter) is covered entirely. Again, it is not the case: I have seen nothing said about NEMO or DTN, so reports of investigations in these fields need to be included in the draft anyways.

Second, if we are not going into a long research phase, I am still wondering what existing protocols/algorithms, IP compatible or not, are being "hinted at" here, which could meet the "dream" criterii that are evoked in the draft. Chris Dearlove and other people have asked this question many times, and it is yet to be answered.

Emmanuel
------=_Part_103192_14242966.1229008446369-- --===============0890327110== 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 --===============0890327110==-- From roll-bounces@ietf.org Thu Dec 11 12:52:37 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A06623A6987; Thu, 11 Dec 2008 12:52:37 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A3B73A6963 for ; Thu, 11 Dec 2008 12:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWtlEu6JSTY0 for ; Thu, 11 Dec 2008 12:52:35 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 9B46328C0ED for ; Thu, 11 Dec 2008 12:52:35 -0800 (PST) Received: from [128.32.39.228] (dhcp-39-228.EECS.Berkeley.EDU [128.32.39.228]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id mBBKqRlA000035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 11 Dec 2008 12:52:28 -0800 (PST) Message-ID: <49417D7A.7060706@eecs.berkeley.edu> Date: Thu, 11 Dec 2008 12:52:10 -0800 From: "David E. Culler" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: roll@ietf.org References: In-Reply-To: Subject: Re: [Roll] Review and concerns (was: Re: Working Group Last Call: draft-ietf-roll-protocols-survey-02) X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============1451374675==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1451374675== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Emmanuel,
   We discussed the list of rows in each of the IETF meetings and associated discussions leading up to those.   It sounds like you agree that if you have some criteria for limiting the search space the discussion will never complete.   That is necessary, according to the charter, to consider the space of solutions that might actually solve the problem.  To do any analysis there has to be something specific to analyze.  You mention two addition WGs that have done relevant work.  Indeed, from the very beginning it was stated that Roll should work in conjunction with those groups.  It is key another thing to say "this specific protocol as described by this RFC or I-D ought to be analyzed in draft-ietf-roll-protocols-survey-03". 

 Here's the NEMO list.  Which are you arguing should be included and why?
draft-ietf-nemo-basic-support -03
2004-06-07   RFC 3963
draft-ietf-nemo-home-network-models -06
2006-02-21   RFC 4887
draft-ietf-nemo-multihoming-issues -07
2007-02-07   RFC 4980
draft-ietf-nemo-requirements -06
2006-11-09   RFC 4886
draft-ietf-nemo-ro-problem-statement -03
2006-09-18   RFC 4888
draft-ietf-nemo-ro-space-analysis -03
2006-09-18   RFC 4889
draft-ietf-nemo-terminology -06
2006-11-09   RFC 4885

There are many topics that as a working group we'd like to move on to once this process completes.  Much important work has been done outside IETF WGs.  Some of it in the IRTF.  Others in other places.  All the more reason to complete this well formed, bounded effort.   Again, I do not hear any suggestion that any protocol within the domain of analysis meets the criteria.  I do hear that there are protocols or modifications to protocols that do or could.  We need to complete the process on this draft so that we can move on to consider such enhancements, candidates, or new designs. 


On Thu, Dec 11, 2008 at 4:09 PM, Emmanuel Baccelli <emmanuel.baccelli at gmail.com> wrote:


On Tue, Dec 9, 2008 at 11:28 PM, David E. Culler <culler at eecs.berkeley.edu> wrote:

Some concerns recognize that there are protocols outside the defined universe that should be considered and that appear to be far better suited to meeting the criteria than the set of IETF protocols that were considered - since those protocols were developed without these criteria.  Again, that suggests that the criteria are a reasonable guide, that they do not appear to be unobtainable, and that the analysis has provided a suitable guide.

None of the comments seem to be claiming that there is a solution within the universe that we were chartered to consider that meets the criteria.

 
Even admitting that the universe you defined is wide enough (a point which is actually agued since months), we could conclude to this only if this universe (defined in the charter) is covered entirely. Again, it is not the case: I have seen nothing said about NEMO or DTN, so reports of investigations in these fields need to be included in the draft anyways.

Second, if we are not going into a long research phase, I am still wondering what existing protocols/algorithms, IP compatible or not, are being "hinted at" here, which could meet the "dream" criterii that are evoked in the draft. Chris Dearlove and other people have asked this question many times, and it is yet to be answered.

Emmanuel
--===============1451374675== 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 --===============1451374675==-- From roll-bounces@ietf.org Thu Dec 11 13:07:38 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E9883A67F1; Thu, 11 Dec 2008 13:07:38 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E00828C1DB for ; Thu, 11 Dec 2008 10:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dc3xOBwcEfSx for ; Thu, 11 Dec 2008 10:21:52 -0800 (PST) Received: from server1.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 46ED228C129 for ; Thu, 11 Dec 2008 10:21:52 -0800 (PST) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id mBBILjl5002057; Thu, 11 Dec 2008 11:21:45 -0700 (MST) From: Geoff Mulligan To: Emmanuel Baccelli In-Reply-To: References: <493EF103.7050908@eecs.berkeley.edu> Date: Thu, 11 Dec 2008 11:21:36 -0700 Message-Id: <1229019696.5870.32.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: roll@ietf.org Subject: Re: [Roll] Review and concerns (was: Re: Working Group Last Call: draft-ietf-roll-protocols-survey-02) X-BeenThere: roll@ietf.org X-Mailman-Version: 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 in Menneapolis, but didn't get a good answer. Why was IS-IS not included in the survey? Is it considered too similar to OSPF - there are some differences. geoff On Thu, 2008-12-11 at 16:14 +0100, Emmanuel Baccelli wrote: > Sorry, mistyped, and sent by mistake. So here's the correct, full > version of my email, see below: > > On Thu, Dec 11, 2008 at 4:09 PM, Emmanuel Baccelli > wrote: > > > On Tue, Dec 9, 2008 at 11:28 PM, David E. Culler > wrote: > > Some concerns recognize that there are protocols > outside the defined universe that should be considered > and that appear to be far better suited to meeting the > criteria than the set of IETF protocols that were > considered - since those protocols were developed > without these criteria. Again, that suggests that the > criteria are a reasonable guide, that they do not > appear to be unobtainable, and that the analysis has > provided a suitable guide. > > None of the comments seem to be claiming that there is > a solution within the universe that we were chartered > to consider that meets the criteria. > > > > > Even admitting that the universe you defined is wide enough (a point > which is actually agued since months), we could conclude to this only > if this universe (defined in the charter) is covered entirely. Again, > it is not the case: I have seen nothing said about NEMO or DTN, so > reports of investigations in these fields need to be included in the > draft anyways. > > > Second, if we are not going into a long research phase, I am still > wondering what existing protocols/algorithms, IP compatible or not, > are being "hinted at" here, which could meet the "dream" criterii that > are evoked in the draft. Chris Dearlove and other people have asked > this question many times, and it is yet to be answered. > > > Emmanuel > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Sun Dec 14 09:40:25 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 482793A67A8; Sun, 14 Dec 2008 09:40:25 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F1A33A67A8 for ; Sun, 14 Dec 2008 09:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXhStyBnVxB8 for ; Sun, 14 Dec 2008 09:40:23 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B203F3A6782 for ; Sun, 14 Dec 2008 09:40:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,219,1228089600"; d="scan'208";a="28562184" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 Dec 2008 17:40:14 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBEHeEDT030437; Sun, 14 Dec 2008 18:40:14 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBEHeE6n015186; Sun, 14 Dec 2008 17:40:14 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Dec 2008 18:39:19 +0100 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Dec 2008 18:39:18 +0100 Message-Id: <6F6D8A57-2129-4DD6-BC1E-D845F87580CC@cisco.com> From: JP Vasseur To: Geoff Mulligan In-Reply-To: <1229019696.5870.32.camel@dellx1> Mime-Version: 1.0 (Apple Message framework v926) Date: Sun, 14 Dec 2008 18:39:17 +0100 References: <493EF103.7050908@eecs.berkeley.edu> <1229019696.5870.32.camel@dellx1> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 14 Dec 2008 17:39:18.0542 (UTC) FILETIME=[E40F9AE0:01C95E12] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2666; t=1229276414; x=1230140414; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Review=20and=20concerns=20(was =3A=20Re=3A=20Working=20Group=20Last=20Call=3A=09draft-ietf- roll-protocols-survey-02) |Sender:=20; bh=MyoJpoBXmUpllAALiU0b7JzsIrUPzaoXk5XHeH9OHi0=; b=Qud4zaJViFwwkZSK1zUH1CiRn7dPagmShMb+8ZQB3eotkCgQ52csp8OLOF z4eJWPGuBHoWcX0ORble4IzfX8v6nXbSzMv8v5D+kPpCRNdqowaQUfAeP2fL Is2EOpb3rn; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] Review and concerns (was: Re: Working Group Last Call: draft-ietf-roll-protocols-survey-02) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Geoff, On Dec 11, 2008, at 7:21 PM, Geoff Mulligan wrote: > I asked in Menneapolis, but didn't get a good answer. > > Why was IS-IS not included in the survey? Is it considered too > similar > to OSPF - there are some differences. > There are differences of course, as far as the set of criterion is concerned, the results will be identical to OSPF. JP. > geoff > > On Thu, 2008-12-11 at 16:14 +0100, Emmanuel Baccelli wrote: >> Sorry, mistyped, and sent by mistake. So here's the correct, full >> version of my email, see below: >> >> On Thu, Dec 11, 2008 at 4:09 PM, Emmanuel Baccelli >> wrote: >> >> >> On Tue, Dec 9, 2008 at 11:28 PM, David E. Culler >> wrote: >> >> Some concerns recognize that there are protocols >> outside the defined universe that should be considered >> and that appear to be far better suited to meeting the >> criteria than the set of IETF protocols that were >> considered - since those protocols were developed >> without these criteria. Again, that suggests that the >> criteria are a reasonable guide, that they do not >> appear to be unobtainable, and that the analysis has >> provided a suitable guide. >> >> None of the comments seem to be claiming that there is >> a solution within the universe that we were chartered >> to consider that meets the criteria. >> >> >> >> >> Even admitting that the universe you defined is wide enough (a point >> which is actually agued since months), we could conclude to this only >> if this universe (defined in the charter) is covered entirely. Again, >> it is not the case: I have seen nothing said about NEMO or DTN, so >> reports of investigations in these fields need to be included in the >> draft anyways. >> >> >> Second, if we are not going into a long research phase, I am still >> wondering what existing protocols/algorithms, IP compatible or not, >> are being "hinted at" here, which could meet the "dream" criterii >> that >> are evoked in the draft. Chris Dearlove and other people have asked >> this question many times, and it is yet to be answered. >> >> >> Emmanuel >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Sun Dec 14 15:18:49 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3004E3A6804; Sun, 14 Dec 2008 15:18:49 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52BF43A6804 for ; Sun, 14 Dec 2008 15:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsQL3Lz0zW-d for ; Sun, 14 Dec 2008 15:18:47 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 803883A66B4 for ; Sun, 14 Dec 2008 15:18:47 -0800 (PST) Received: from [192.168.2.102] (64-142-4-199.dsl.static.sonic.net [64.142.4.199]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id mBENIW0W007067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 14 Dec 2008 15:18:34 -0800 (PST) Message-ID: <49459435.3020700@eecs.berkeley.edu> Date: Sun, 14 Dec 2008 15:18:13 -0800 From: "David E. Culler" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: JP Vasseur References: <493EF103.7050908@eecs.berkeley.edu> <1229019696.5870.32.camel@dellx1> <6F6D8A57-2129-4DD6-BC1E-D845F87580CC@cisco.com> In-Reply-To: <6F6D8A57-2129-4DD6-BC1E-D845F87580CC@cisco.com> Cc: roll@ietf.org Subject: Re: [Roll] Review and concerns X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Precisely. The relationship and rationale are addressed in the text of the document. So it is covered whiling keeping the table compact. (Actually, the discussion was in there from the first draft.) JP Vasseur wrote: > Hi Geoff, > > On Dec 11, 2008, at 7:21 PM, Geoff Mulligan wrote: > >> I asked in Menneapolis, but didn't get a good answer. >> >> Why was IS-IS not included in the survey? Is it considered too similar >> to OSPF - there are some differences. >> > > There are differences of course, as far as the set of criterion is > concerned, the results will be identical to OSPF. > > JP. > >> geoff >> >> On Thu, 2008-12-11 at 16:14 +0100, Emmanuel Baccelli wrote: >>> Sorry, mistyped, and sent by mistake. So here's the correct, full >>> version of my email, see below: >>> >>> On Thu, Dec 11, 2008 at 4:09 PM, Emmanuel Baccelli >>> wrote: >>> >>> >>> On Tue, Dec 9, 2008 at 11:28 PM, David E. Culler >>> wrote: >>> >>> Some concerns recognize that there are protocols >>> outside the defined universe that should be considered >>> and that appear to be far better suited to meeting the >>> criteria than the set of IETF protocols that were >>> considered - since those protocols were developed >>> without these criteria. Again, that suggests that the >>> criteria are a reasonable guide, that they do not >>> appear to be unobtainable, and that the analysis has >>> provided a suitable guide. >>> >>> None of the comments seem to be claiming that there is >>> a solution within the universe that we were chartered >>> to consider that meets the criteria. >>> >>> >>> >>> >>> Even admitting that the universe you defined is wide enough (a point >>> which is actually agued since months), we could conclude to this only >>> if this universe (defined in the charter) is covered entirely. Again, >>> it is not the case: I have seen nothing said about NEMO or DTN, so >>> reports of investigations in these fields need to be included in the >>> draft anyways. >>> >>> >>> Second, if we are not going into a long research phase, I am still >>> wondering what existing protocols/algorithms, IP compatible or not, >>> are being "hinted at" here, which could meet the "dream" criterii that >>> are evoked in the draft. Chris Dearlove and other people have asked >>> this question many times, and it is yet to be answered. >>> >>> >>> Emmanuel >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > 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 Dec 15 03:23:57 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F09A3A692D; Mon, 15 Dec 2008 03:23:57 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F55E3A692D for ; Mon, 15 Dec 2008 03:23:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.277, 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 IZeJygyHt9bD for ; Mon, 15 Dec 2008 03:23:48 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by core3.amsl.com (Postfix) with ESMTP id 1070B3A68D4 for ; Mon, 15 Dec 2008 03:23:47 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id 18so1458535fkq.5 for ; Mon, 15 Dec 2008 03:23:39 -0800 (PST) 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:cc:in-reply-to:mime-version:content-type:references; bh=uCxCFXieI+NyKdBKevfpC9OU0jBrGzlINiCBuBWxesg=; b=efyykdKUGTDMrk9RgVgm5ZY5jFs+jIfYayO3wc3yUCedgVFPQURqZeYNifh8SmjKgR eJnXZWK43sMHqlweM1/fx5qsNbzewT6fuPEdv4WzynBdkaB3fsCsBEGRWsmxwynMsCJH ezk6Oh/baNt+xUas5wF/OqalXrK8VzLmgJNGk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=tk8QXxYtFYJhRafpp7/ZdcCKj+kkETPgBZxVYGquzt1g8ZjRe3IRwj1OZRvcPDcQML jN4dtlXX8FkLEqPsKuxqlEXweINEVwT00z15qDK+LlP6jWV4sA/Olt01ID9bsmrHeTlO 3tQh6BA1qh34CKW5Rujdmqak1VWo/Y73qw4Y4= Received: by 10.103.229.12 with SMTP id g12mr2935476mur.16.1229340219388; Mon, 15 Dec 2008 03:23:39 -0800 (PST) Received: by 10.103.248.12 with HTTP; Mon, 15 Dec 2008 03:23:39 -0800 (PST) Message-ID: Date: Mon, 15 Dec 2008 12:23:39 +0100 From: "Emmanuel Baccelli" To: "David E. Culler" In-Reply-To: <49417D7A.7060706@eecs.berkeley.edu> MIME-Version: 1.0 References: <49417D7A.7060706@eecs.berkeley.edu> Cc: roll@ietf.org Subject: Re: [Roll] Review and concerns (was: Re: Working Group Last Call: draft-ietf-roll-protocols-survey-02) X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============2046763895==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============2046763895== Content-Type: multipart/alternative; boundary="----=_Part_34485_27065157.1229340219382" ------=_Part_34485_27065157.1229340219382 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Thu, Dec 11, 2008 at 9:52 PM, David E. Culler wrote: > Emmanuel, > We discussed the list of rows in each of the IETF meetings and > associated discussions leading up to those. It sounds like you agree that > if you have some criteria for limiting the search space the discussion will > never complete. That is necessary, according to the charter, to consider > the space of solutions that might actually solve the problem. To do any > analysis there has to be something specific to analyze. You mention two > addition WGs that have done relevant work. Indeed, from the very beginning > it was stated that Roll should work in conjunction with those groups. It is > key another thing to say "this specific protocol as described by this RFC or > I-D ought to be analyzed in draft-ietf-roll-protocols-survey-03". > > Here's the NEMO list. Which are you arguing should be included and why? > Sorry to be blunt, but your charter says that DTN and NEMO are to be reviewed as well as the rest. There is not a word about either of these "fields" in the draft, why? You need to answer this question. Not me. Emmanuel > > draft-ietf-nemo-basic-support > -03 > 2004-06-07 RFC 3963 > draft-ietf-nemo-home-network-models > -06 > 2006-02-21 RFC 4887 > draft-ietf-nemo-multihoming-issues > -07 > 2007-02-07 RFC 4980 > draft-ietf-nemo-requirements > -06 > 2006-11-09 RFC 4886 > draft-ietf-nemo-ro-problem-statement > -03 > 2006-09-18 RFC 4888 > draft-ietf-nemo-ro-space-analysis > -03 > 2006-09-18 RFC 4889 > draft-ietf-nemo-terminology > -06 > 2006-11-09 RFC 4885 > > There are many topics that as a working group we'd like to move on to once > this process completes. Much important work has been done outside IETF > WGs. Some of it in the IRTF. Others in other places. All the more reason > to complete this well formed, bounded effort. Again, I do not hear any > suggestion that any protocol within the domain of analysis meets the > criteria. I do hear that there are protocols or modifications to protocols > that do or could. We need to complete the process on this draft so that we > can move on to consider such enhancements, candidates, or new designs. > > > On Thu, Dec 11, 2008 at 4:09 PM, Emmanuel Baccelli gmail.com > wrote: > >> >> >> On Tue, Dec 9, 2008 at 11:28 PM, David E. Culler > eecs.berkeley.edu > wrote: >>> >>> >>> Some concerns recognize that there are protocols outside the defined >>> universe that should be considered and that appear to be far better suited >>> to meeting the criteria than the set of IETF protocols that were considered >>> - since those protocols were developed without these criteria. Again, that >>> suggests that the criteria are a reasonable guide, that they do not appear >>> to be unobtainable, and that the analysis has provided a suitable guide. >>> >>> None of the comments seem to be claiming that there is a solution within >>> the universe that we were chartered to consider that meets the criteria. >>> >> > > Even admitting that the universe you defined is wide enough (a point > which is actually agued since months), we could conclude to this only if > this universe (defined in the charter) is covered entirely. Again, it is not > the case: I have seen nothing said about NEMO or DTN, so reports of > investigations in these fields need to be included in the draft anyways. > > Second, if we are not going into a long research phase, I am still > wondering what existing protocols/algorithms, IP compatible or not, are > being "hinted at" here, which could meet the "dream" criterii that are > evoked in the draft. Chris Dearlove and other people have asked this > question many times, and it is yet to be answered. > > Emmanuel > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > ------=_Part_34485_27065157.1229340219382 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Thu, Dec 11, 2008 at 9:52 PM, David E. Culler <culler@eecs.berkeley.edu> wrote:
Emmanuel,
   We discussed the list of rows in each of the IETF meetings and associated discussions leading up to those.   It sounds like you agree that if you have some criteria for limiting the search space the discussion will never complete.   That is necessary, according to the charter, to consider the space of solutions that might actually solve the problem.  To do any analysis there has to be something specific to analyze.  You mention two addition WGs that have done relevant work.  Indeed, from the very beginning it was stated that Roll should work in conjunction with those groups.  It is key another thing to say "this specific protocol as described by this RFC or I-D ought to be analyzed in draft-ietf-roll-protocols-survey-03". 

 Here's the NEMO list.  Which are you arguing should be included and why?


Sorry to be blunt, but your charter says that DTN and NEMO are to be reviewed as well as the rest. There is not a word about either of these "fields" in the draft, why? You need to answer this question. Not me.

Emmanuel




 

draft-ietf-nemo-basic-support -03
2004-06-07   RFC 3963
draft-ietf-nemo-home-network-models -06
2006-02-21   RFC 4887
draft-ietf-nemo-multihoming-issues -07
2007-02-07   RFC 4980
draft-ietf-nemo-requirements -06
2006-11-09   RFC 4886
draft-ietf-nemo-ro-problem-statement -03
2006-09-18   RFC 4888
draft-ietf-nemo-ro-space-analysis -03
2006-09-18   RFC 4889
draft-ietf-nemo-terminology -06
2006-11-09   RFC 4885

There are many topics that as a working group we'd like to move on to once this process completes.  Much important work has been done outside IETF WGs.  Some of it in the IRTF.  Others in other places.  All the more reason to complete this well formed, bounded effort.   Again, I do not hear any suggestion that any protocol within the domain of analysis meets the criteria.  I do hear that there are protocols or modifications to protocols that do or could.  We need to complete the process on this draft so that we can move on to consider such enhancements, candidates, or new designs. 


On Thu, Dec 11, 2008 at 4:09 PM, Emmanuel Baccelli <emmanuel.baccelli at gmail.com> wrote:



On Tue, Dec 9, 2008 at 11:28 PM, David E. Culler <culler at eecs.berkeley.edu> wrote:

Some concerns recognize that there are protocols outside the defined universe that should be considered and that appear to be far better suited to meeting the criteria than the set of IETF protocols that were considered - since those protocols were developed without these criteria.  Again, that suggests that the criteria are a reasonable guide, that they do not appear to be unobtainable, and that the analysis has provided a suitable guide.

None of the comments seem to be claiming that there is a solution within the universe that we were chartered to consider that meets the criteria.

 
Even admitting that the universe you defined is wide enough (a point which is actually agued since months), we could conclude to this only if this universe (defined in the charter) is covered entirely. Again, it is not the case: I have seen nothing said about NEMO or DTN, so reports of investigations in these fields need to be included in the draft anyways.

Second, if we are not going into a long research phase, I am still wondering what existing protocols/algorithms, IP compatible or not, are being "hinted at" here, which could meet the "dream" criterii that are evoked in the draft. Chris Dearlove and other people have asked this question many times, and it is yet to be answered.

Emmanuel

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


------=_Part_34485_27065157.1229340219382-- --===============2046763895== 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 --===============2046763895==-- From roll-bounces@ietf.org Mon Dec 15 06:39:45 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13DE13A685C; Mon, 15 Dec 2008 06:39:45 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C75C23A685C for ; Mon, 15 Dec 2008 06:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 R5JALEw-EGYW for ; Mon, 15 Dec 2008 06:39:42 -0800 (PST) Received: from server1.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id C631D3A67F0 for ; Mon, 15 Dec 2008 06:39:42 -0800 (PST) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id mBFEc8db013816; Mon, 15 Dec 2008 07:38:08 -0700 (MST) From: Geoff Mulligan To: "David E. Culler" In-Reply-To: <49459435.3020700@eecs.berkeley.edu> References: <493EF103.7050908@eecs.berkeley.edu> <1229019696.5870.32.camel@dellx1> <6F6D8A57-2129-4DD6-BC1E-D845F87580CC@cisco.com> <49459435.3020700@eecs.berkeley.edu> Date: Mon, 15 Dec 2008 07:38:14 -0700 Message-Id: <1229351894.5870.115.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: roll@ietf.org Subject: Re: [Roll] Review and concerns X-BeenThere: roll@ietf.org X-Mailman-Version: 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 David, I guess I didn't find any discussion of IS-IS. I see that IS-IS is described as a link state protocol (like OSPF) but thats all I found. I don't know the nuances of the differences between IS-IS and OSPF to be able to know that they are so similar that IS-IS didn't need to examined separately rather than group with all link state protocols. geoff On Sun, 2008-12-14 at 15:18 -0800, David E. Culler wrote: > Precisely. > > The relationship and rationale are addressed in the text of the > document. So it is covered whiling keeping the table compact. > (Actually, the discussion was in there from the first draft.) > > JP Vasseur wrote: > > Hi Geoff, > > > > On Dec 11, 2008, at 7:21 PM, Geoff Mulligan wrote: > > > >> I asked in Menneapolis, but didn't get a good answer. > >> > >> Why was IS-IS not included in the survey? Is it considered too similar > >> to OSPF - there are some differences. > >> > > > > There are differences of course, as far as the set of criterion is > > concerned, the results will be identical to OSPF. > > > > JP. > > > >> geoff > >> > >> On Thu, 2008-12-11 at 16:14 +0100, Emmanuel Baccelli wrote: > >>> Sorry, mistyped, and sent by mistake. So here's the correct, full > >>> version of my email, see below: > >>> > >>> On Thu, Dec 11, 2008 at 4:09 PM, Emmanuel Baccelli > >>> wrote: > >>> > >>> > >>> On Tue, Dec 9, 2008 at 11:28 PM, David E. Culler > >>> wrote: > >>> > >>> Some concerns recognize that there are protocols > >>> outside the defined universe that should be considered > >>> and that appear to be far better suited to meeting the > >>> criteria than the set of IETF protocols that were > >>> considered - since those protocols were developed > >>> without these criteria. Again, that suggests that the > >>> criteria are a reasonable guide, that they do not > >>> appear to be unobtainable, and that the analysis has > >>> provided a suitable guide. > >>> > >>> None of the comments seem to be claiming that there is > >>> a solution within the universe that we were chartered > >>> to consider that meets the criteria. > >>> > >>> > >>> > >>> > >>> Even admitting that the universe you defined is wide enough (a point > >>> which is actually agued since months), we could conclude to this only > >>> if this universe (defined in the charter) is covered entirely. Again, > >>> it is not the case: I have seen nothing said about NEMO or DTN, so > >>> reports of investigations in these fields need to be included in the > >>> draft anyways. > >>> > >>> > >>> Second, if we are not going into a long research phase, I am still > >>> wondering what existing protocols/algorithms, IP compatible or not, > >>> are being "hinted at" here, which could meet the "dream" criterii that > >>> are evoked in the draft. Chris Dearlove and other people have asked > >>> this question many times, and it is yet to be answered. > >>> > >>> > >>> Emmanuel > >>> _______________________________________________ > >>> Roll mailing list > >>> Roll@ietf.org > >>> https://www.ietf.org/mailman/listinfo/roll > >> > >> _______________________________________________ > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll > > > > _______________________________________________ > > 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 Dec 15 07:36:29 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CF0428C0F5; Mon, 15 Dec 2008 07:36:29 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BF5C28C0F4 for ; Mon, 15 Dec 2008 07:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.558 X-Spam-Level: X-Spam-Status: No, score=-10.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ij0vE057BZ1 for ; Mon, 15 Dec 2008 07:36:26 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 41B8328C0F5 for ; Mon, 15 Dec 2008 07:36:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,224,1228089600"; d="scan'208";a="28658428" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 15 Dec 2008 15:36:18 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBFFaIWv023933; Mon, 15 Dec 2008 16:36:18 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBFFaIDO014920; Mon, 15 Dec 2008 15:36:18 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Dec 2008 16:36:18 +0100 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Dec 2008 16:36:17 +0100 Message-Id: <173272AB-937B-48CA-A07C-B6B2B7EF97C2@cisco.com> From: JP Vasseur To: Geoff Mulligan In-Reply-To: <1229351894.5870.115.camel@dellx1> Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 15 Dec 2008 16:36:16 +0100 References: <493EF103.7050908@eecs.berkeley.edu> <1229019696.5870.32.camel@dellx1> <6F6D8A57-2129-4DD6-BC1E-D845F87580CC@cisco.com> <49459435.3020700@eecs.berkeley.edu> <1229351894.5870.115.camel@dellx1> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 15 Dec 2008 15:36:17.0594 (UTC) FILETIME=[DF1611A0:01C95ECA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4202; t=1229355378; x=1230219378; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Review=20and=20concerns |Sender:=20; bh=b7irD/Y61G+L8cN1khtDTtx/dxCflITPA0dJv8m7UD8=; b=nkgp3/d1w6q/7sFuq+WAaBxztfZYf7/RalbdkHiWzsecToNRLXLhSFvwTb t0nCNM5SboddUnxDDVda07OKTRd/NM8tSiAONdG6wcoKOHmpKYgaW7ajH6rv FMO3EQjcIh; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org, "David E. Culler" Subject: Re: [Roll] Review and concerns X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Geoff, On Dec 15, 2008, at 3:38 PM, Geoff Mulligan wrote: > David, > I guess I didn't find any discussion of IS-IS. I see that IS-IS is > described as a link state protocol (like OSPF) but thats all I > found. I > don't know the nuances of the differences between IS-IS and OSPF to be > able to know that they are so similar that IS-IS didn't need to > examined > separately rather than group with all link state protocols. > Thanks for your feed-backs but yes indeed, looking at the criterion we're interested in, the conclusions equally apply to both routing protocols. Thanks. JP. > geoff > > On Sun, 2008-12-14 at 15:18 -0800, David E. Culler wrote: >> Precisely. >> >> The relationship and rationale are addressed in the text of the >> document. So it is covered whiling keeping the table compact. >> (Actually, the discussion was in there from the first draft.) >> >> JP Vasseur wrote: >>> Hi Geoff, >>> >>> On Dec 11, 2008, at 7:21 PM, Geoff Mulligan wrote: >>> >>>> I asked in Menneapolis, but didn't get a good answer. >>>> >>>> Why was IS-IS not included in the survey? Is it considered too >>>> similar >>>> to OSPF - there are some differences. >>>> >>> >>> There are differences of course, as far as the set of criterion is >>> concerned, the results will be identical to OSPF. >>> >>> JP. >>> >>>> geoff >>>> >>>> On Thu, 2008-12-11 at 16:14 +0100, Emmanuel Baccelli wrote: >>>>> Sorry, mistyped, and sent by mistake. So here's the correct, full >>>>> version of my email, see below: >>>>> >>>>> On Thu, Dec 11, 2008 at 4:09 PM, Emmanuel Baccelli >>>>> wrote: >>>>> >>>>> >>>>> On Tue, Dec 9, 2008 at 11:28 PM, David E. Culler >>>>> wrote: >>>>> >>>>> Some concerns recognize that there are protocols >>>>> outside the defined universe that should be >>>>> considered >>>>> and that appear to be far better suited to meeting >>>>> the >>>>> criteria than the set of IETF protocols that were >>>>> considered - since those protocols were developed >>>>> without these criteria. Again, that suggests that >>>>> the >>>>> criteria are a reasonable guide, that they do not >>>>> appear to be unobtainable, and that the analysis has >>>>> provided a suitable guide. >>>>> >>>>> None of the comments seem to be claiming that >>>>> there is >>>>> a solution within the universe that we were >>>>> chartered >>>>> to consider that meets the criteria. >>>>> >>>>> >>>>> >>>>> >>>>> Even admitting that the universe you defined is wide enough (a >>>>> point >>>>> which is actually agued since months), we could conclude to this >>>>> only >>>>> if this universe (defined in the charter) is covered entirely. >>>>> Again, >>>>> it is not the case: I have seen nothing said about NEMO or DTN, so >>>>> reports of investigations in these fields need to be included in >>>>> the >>>>> draft anyways. >>>>> >>>>> >>>>> Second, if we are not going into a long research phase, I am still >>>>> wondering what existing protocols/algorithms, IP compatible or >>>>> not, >>>>> are being "hinted at" here, which could meet the "dream" >>>>> criterii that >>>>> are evoked in the draft. Chris Dearlove and other people have >>>>> asked >>>>> this question many times, and it is yet to be answered. >>>>> >>>>> >>>>> Emmanuel >>>>> _______________________________________________ >>>>> Roll mailing list >>>>> Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>> >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>> >>> _______________________________________________ >>> 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 Dec 15 10:43:24 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B26653A6964; Mon, 15 Dec 2008 10:43:24 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C85343A6964 for ; Mon, 15 Dec 2008 10:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BatEGQP4+9KD for ; Mon, 15 Dec 2008 10:43:23 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 054F33A690B for ; Mon, 15 Dec 2008 10:43:22 -0800 (PST) Received: from h-67-101-208-221.snfccasy.dynamic.covad.net ([67.101.208.221] helo=[10.107.80.120]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1LCIPT-0001qU-Pf; Mon, 15 Dec 2008 10:43:16 -0800 Message-Id: From: Philip Levis To: Emmanuel Baccelli In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 15 Dec 2008 10:43:15 -0800 References: <49417D7A.7060706@eecs.berkeley.edu> X-Mailer: Apple Mail (2.929.2) X-Scan-Signature: 47150f6aa31409442f7db1cf5c00e98a Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] Review and concerns (was: Re: Working Group Last Call: draft-ietf-roll-protocols-survey-02) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Dec 15, 2008, at 3:23 AM, Emmanuel Baccelli wrote: > > > On Thu, Dec 11, 2008 at 9:52 PM, David E. Culler > wrote: > Emmanuel, > We discussed the list of rows in each of the IETF meetings and > associated discussions leading up to those. It sounds like you > agree that if you have some criteria for limiting the search space > the discussion will never complete. That is necessary, according > to the charter, to consider the space of solutions that might > actually solve the problem. To do any analysis there has to be > something specific to analyze. You mention two addition WGs that > have done relevant work. Indeed, from the very beginning it was > stated that Roll should work in conjunction with those groups. It > is key another thing to say "this specific protocol as described by > this RFC or I-D ought to be analyzed in draft-ietf-roll-protocols- > survey-03". > > Here's the NEMO list. Which are you arguing should be included and > why? > > > Sorry to be blunt, but your charter says that DTN and NEMO are to be > reviewed as well as the rest. There is not a word about either of > these "fields" in the draft, why? You need to answer this question. > Not me. I thought the draft is very explicit: This document considers "existing routing protocols" to be protocols that are specified in RFCs or, in the cases of DYMO [I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very mature draft which will most likely become an RFC. This document does not seek to answer the question of whether there is any protocol anywhere which could meet LLN application requirements. Rather, it seeks to answer whether protocols, as specified in current IETF standards documents, can meet such requirements. In the case of DTN, it's IRTF. In the case of NEMO, it is not a routing protocol. When the charter was written, the initial thought was that reviewing those protocols seemed like a good idea. We did. But after further examination and discussion, both on the mailing list at at IETF meetings, the WG reached consensus that the current methodology for the *routing protocol survey* is the right one. Because neither is a standards-track routing protocol, their mechanisms do not help answer the question of whether ROLL needs to recharter for protocol design. Rather, they might be part of the next step, which is to examine existing mechanisms and protocols to see how protocol design should go forward. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Dec 15 10:52:58 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02FA228C0E5; Mon, 15 Dec 2008 10:52:58 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A7DF28C0F3 for ; Mon, 15 Dec 2008 10:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYOcSt5qZO6e for ; Mon, 15 Dec 2008 10:52:56 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id EF36F3A697F for ; Mon, 15 Dec 2008 10:52:55 -0800 (PST) Received: from [128.32.39.228] (dhcp-39-228.EECS.Berkeley.EDU [128.32.39.228]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id mBFIqjJM017149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Dec 2008 10:52:46 -0800 (PST) Message-ID: <4946A778.8040003@eecs.berkeley.edu> Date: Mon, 15 Dec 2008 10:52:40 -0800 From: "David E. Culler" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Emmanuel Baccelli References: <49417D7A.7060706@eecs.berkeley.edu> In-Reply-To: Cc: roll@ietf.org Subject: Re: [Roll] Review and concerns X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============0756601724==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0756601724== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit That's correct.  It says"- Survey the applicability of existing protocols to LLNs. The aim of
this document will be to analyze the scaling and characteristics of
existing protocols and identify whether or not they meet the routing
requirements of the applications identified above. Existing IGPs, MANET,
NEMO, DTN routing protocols will be part of evaluation."

My understanding is that the authors have done that review and have reached out in various was to engage in discussion with those groups to identify concrete instances that should be examined in detail.  My question is a concrete one.  In the Nemo IDs is there a protocol that should have been addressed in the survey in the manner of the ones that are there?  I didn't see a specific candidate.  Did they miss it?  Which?  Where?


Emmanuel Baccelli wrote:


On Thu, Dec 11, 2008 at 9:52 PM, David E. Culler <culler@eecs.berkeley.edu> wrote:
Emmanuel,
   We discussed the list of rows in each of the IETF meetings and associated discussions leading up to those.   It sounds like you agree that if you have some criteria for limiting the search space the discussion will never complete.   That is necessary, according to the charter, to consider the space of solutions that might actually solve the problem.  To do any analysis there has to be something specific to analyze.  You mention two addition WGs that have done relevant work.  Indeed, from the very beginning it was stated that Roll should work in conjunction with those groups.  It is key another thing to say "this specific protocol as described by this RFC or I-D ought to be analyzed in draft-ietf-roll-protocols-survey-03". 

 Here's the NEMO list.  Which are you arguing should be included and why?


Sorry to be blunt, but your charter says that DTN and NEMO are to be reviewed as well as the rest. There is not a word about either of these "fields" in the draft, why? You need to answer this question. Not me.

Emmanuel




 

draft-ietf-nemo-basic-support -03
2004-06-07   RFC 3963
draft-ietf-nemo-home-network-models -06
2006-02-21   RFC 4887
draft-ietf-nemo-multihoming-issues -07
2007-02-07   RFC 4980
draft-ietf-nemo-requirements -06
2006-11-09   RFC 4886
draft-ietf-nemo-ro-problem-statement -03
2006-09-18   RFC 4888
draft-ietf-nemo-ro-space-analysis -03
2006-09-18   RFC 4889
draft-ietf-nemo-terminology -06
2006-11-09   RFC 4885

There are many topics that as a working group we'd like to move on to once this process completes.  Much important work has been done outside IETF WGs.  Some of it in the IRTF.  Others in other places.  All the more reason to complete this well formed, bounded effort.   Again, I do not hear any suggestion that any protocol within the domain of analysis meets the criteria.  I do hear that there are protocols or modifications to protocols that do or could.  We need to complete the process on this draft so that we can move on to consider such enhancements, candidates, or new designs. 


On Thu, Dec 11, 2008 at 4:09 PM, Emmanuel Baccelli <emmanuel.baccelli at gmail.com> wrote:



On Tue, Dec 9, 2008 at 11:28 PM, David E. Culler <culler at eecs.berkeley.edu> wrote:

Some concerns recognize that there are protocols outside the defined universe that should be considered and that appear to be far better suited to meeting the criteria than the set of IETF protocols that were considered - since those protocols were developed without these criteria.  Again, that suggests that the criteria are a reasonable guide, that they do not appear to be unobtainable, and that the analysis has provided a suitable guide.

None of the comments seem to be claiming that there is a solution within the universe that we were chartered to consider that meets the criteria.

 
Even admitting that the universe you defined is wide enough (a point which is actually agued since months), we could conclude to this only if this universe (defined in the charter) is covered entirely. Again, it is not the case: I have seen nothing said about NEMO or DTN, so reports of investigations in these fields need to be included in the draft anyways.

Second, if we are not going into a long research phase, I am still wondering what existing protocols/algorithms, IP compatible or not, are being "hinted at" here, which could meet the "dream" criterii that are evoked in the draft. Chris Dearlove and other people have asked this question many times, and it is yet to be answered.

Emmanuel

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



_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--===============0756601724== 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 --===============0756601724==-- From roll-bounces@ietf.org Mon Dec 15 11:50:43 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E0AC3A6A33; Mon, 15 Dec 2008 11:50:43 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B98328C12C for ; Mon, 15 Dec 2008 11:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.619, 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 5uBI23ja3hXa for ; Mon, 15 Dec 2008 11:50:40 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 00B1328C117 for ; Mon, 15 Dec 2008 11:50:39 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so1323584fga.41 for ; Mon, 15 Dec 2008 11:50:32 -0800 (PST) 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=Yyazn46tG1mT/AfnEFa5MlcT1s1ppKIB4QwXFnJSbxw=; b=Uzdt4hBE9HZFGTVxBsRdnod6BWgDhqBzxyfcbhD5irz2vX3Gq+sLqn4OdXH27rSiHb Vt6dtkdl1WRnGNsmikBUXcsy9GxWuRNwFArJyBwZeDGFSVf1lUGnTPya8o+QnG3KSSED DWO/pgmv3dcHGrs2vUtEDgiR0/Q4eHc+0qvHo= 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=t1QKY7d8BUlKJa1aL88o3ygTrHfFlI9zQbLUV819RuX76gbPT2adl8d9hHcrhwaI5K s1CTJTb1fzG0BwxM6z3w6Pel/8JeZTf/JgcC0dDlKcKjpnH4vfdWf6AEqIWbfZ3yUtjP EacaWD3Zs+UtQNfK+Sir0myIc6eS8w3W974hk= Received: by 10.103.193.13 with SMTP id v13mr3127447mup.125.1229370632393; Mon, 15 Dec 2008 11:50:32 -0800 (PST) Received: by 10.103.248.12 with HTTP; Mon, 15 Dec 2008 11:50:32 -0800 (PST) Message-ID: Date: Mon, 15 Dec 2008 20:50:32 +0100 From: "Emmanuel Baccelli" To: "ROLL WG" In-Reply-To: MIME-Version: 1.0 References: <49417D7A.7060706@eecs.berkeley.edu> Subject: Re: [Roll] Review and concerns (was: Re: Working Group Last Call: draft-ietf-roll-protocols-survey-02) X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============0996288553==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0996288553== Content-Type: multipart/alternative; boundary="----=_Part_40750_22940107.1229370632396" ------=_Part_40750_22940107.1229370632396 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, Dec 15, 2008 at 7:43 PM, Philip Levis wrote: > > On Dec 15, 2008, at 3:23 AM, Emmanuel Baccelli wrote: > > >> >> On Thu, Dec 11, 2008 at 9:52 PM, David E. Culler < >> culler@eecs.berkeley.edu> wrote: >> Emmanuel, >> We discussed the list of rows in each of the IETF meetings and >> associated discussions leading up to those. It sounds like you agree that >> if you have some criteria for limiting the search space the discussion will >> never complete. That is necessary, according to the charter, to consider >> the space of solutions that might actually solve the problem. To do any >> analysis there has to be something specific to analyze. You mention two >> addition WGs that have done relevant work. Indeed, from the very beginning >> it was stated that Roll should work in conjunction with those groups. It is >> key another thing to say "this specific protocol as described by this RFC or >> I-D ought to be analyzed in draft-ietf-roll-protocols-survey-03". >> >> Here's the NEMO list. Which are you arguing should be included and why? >> >> >> Sorry to be blunt, but your charter says that DTN and NEMO are to be >> reviewed as well as the rest. There is not a word about either of these >> "fields" in the draft, why? You need to answer this question. Not me. >> > > I thought the draft is very explicit: > > This document considers "existing routing protocols" to be protocols > that are specified in RFCs or, in the cases of DYMO > [I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very > mature draft which will most likely become an RFC. This document > does not seek to answer the question of whether there is any protocol > anywhere which could meet LLN application requirements. Rather, it > seeks to answer whether protocols, as specified in current IETF > standards documents, can meet such requirements. > > In the case of DTN, it's IRTF. > > In the case of NEMO, it is not a routing protocol. > > When the charter was written, the initial thought was that reviewing those > protocols seemed like a good idea. We did. But after further examination and > discussion, both on the mailing list at at IETF meetings, the WG reached > consensus that the current methodology for the *routing protocol survey* is > the right one. Because neither is a standards-track routing protocol, their > mechanisms do not help answer the question of whether ROLL needs to > recharter for protocol design. Rather, they might be part of the next step, > which is to examine existing mechanisms and protocols to see how protocol > design should go forward. > > Phil Then at least give the gist of the discussions on the subject, to explain in the draft why the charter is not covered. However, at the time the charter was written, DTN was already IRTF, and unless I am mistaken, except OSPF, none of the routing protocols are standards-track, so these reasons are not enough, in my mind. Why discard things that are chartered? Maybe the charter was not well written. But this must be justified in the draft. The whole point is that this draft is incomplete, and that this incompleteness i not justified in anyway other than hand-waving. Emmanuel ------=_Part_40750_22940107.1229370632396 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Mon, Dec 15, 2008 at 7:43 PM, Philip Levis <pal@cs.stanford.edu> wrote:

On Dec 15, 2008, at 3:23 AM, Emmanuel Baccelli wrote:



On Thu, Dec 11, 2008 at 9:52 PM, David E. Culler <culler@eecs.berkeley.edu> wrote:
Emmanuel,
  We discussed the list of rows in each of the IETF meetings and associated discussions leading up to those.   It sounds like you agree that if you have some criteria for limiting the search space the discussion will never complete.   That is necessary, according to the charter, to consider the space of solutions that might actually solve the problem.  To do any analysis there has to be something specific to analyze.  You mention two addition WGs that have done relevant work.  Indeed, from the very beginning it was stated that Roll should work in conjunction with those groups.  It is key another thing to say "this specific protocol as described by this RFC or I-D ought to be analyzed in draft-ietf-roll-protocols-survey-03".

 Here's the NEMO list.  Which are you arguing should be included and why?


Sorry to be blunt, but your charter says that DTN and NEMO are to be reviewed as well as the rest. There is not a word about either of these "fields" in the draft, why? You need to answer this question. Not me.

I thought the draft is very explicit:

  This document considers "existing routing protocols" to be protocols
  that are specified in RFCs or, in the cases of DYMO
  [I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very
  mature draft which will most likely become an RFC.  This document
  does not seek to answer the question of whether there is any protocol
  anywhere which could meet LLN application requirements.  Rather, it
  seeks to answer whether protocols, as specified in current IETF
  standards documents, can meet such requirements.

In the case of DTN, it's IRTF.

In the case of NEMO, it is not a routing protocol.

When the charter was written, the initial thought was that reviewing those protocols seemed like a good idea. We did. But after further examination and discussion, both on the mailing list at at IETF meetings, the WG reached consensus that the current methodology for the *routing protocol survey* is the right one. Because neither is a standards-track routing protocol, their mechanisms do not help answer the question of whether ROLL needs to recharter for protocol design. Rather, they might be part of the next step, which is to examine existing mechanisms and protocols to see how protocol design should go forward.

Phil

Then at least give the gist of the discussions on the subject, to explain in the draft why the charter is not covered. 

However, at the time the charter was written, DTN was already IRTF, and unless I am mistaken, except OSPF, none of the routing protocols are standards-track, so these reasons are not enough, in my mind. 

Why discard things that are chartered? Maybe the charter was not well written. But this must be justified in the draft. The whole point is that this draft is incomplete, and that this incompleteness i not justified in anyway other than hand-waving.

Emmanuel





------=_Part_40750_22940107.1229370632396-- --===============0996288553== 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 --===============0996288553==-- From roll-bounces@ietf.org Mon Dec 15 22:57:07 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AFB23A6828; Mon, 15 Dec 2008 22:57:07 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D61E3A6828 for ; Mon, 15 Dec 2008 22:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPmt16EmEjKC for ; Mon, 15 Dec 2008 22:57:05 -0800 (PST) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id D6A5B3A67F6 for ; Mon, 15 Dec 2008 22:57:04 -0800 (PST) Received: from [129.104.11.1] (helo=[192.168.112.180]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LCTrU-000Krp-0m; Tue, 16 Dec 2008 06:56:56 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 129.104.11.1 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19bbj7I6uKY4GJgLrRMBy53 In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC06ADE37A@xmb-ams-337.emea.cisco.com> References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> <61D43925-D96D-41A0-A73B-E87B586245E3@thomasclausen.org> <7892795E1A87F04CADFCCF41FADD00FC06ADE37A@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Thomas Heide Clausen Date: Tue, 16 Dec 2008 07:55:57 +0100 To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.753.1) Cc: "Dearlove, Christopher \(UK\)" , Emmanuel Baccelli , roll@ietf.org Subject: Re: [Roll] WorkingGroup LastCall:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Pascal, Long time no see -- hope all is well in the south? On Dec 9, 2008, at 6:32 PM, Pascal Thubert (pthubert) wrote: > Hi Thomas: > > Every evaluation picks criteria and applies them. This doc has been = > around for awhile with its own clear list of criteria, which take = > their source in the requirements drafts. Someone could propose = > another doc with another set of criteria that would make perfect = > sense for a different set of requirements. > Right, I appreciate that any evaluation is the result of a choice of = criteria -- and that's fine as such. However the choice has to be = sensible such that the conclusions that can be drawn are useful. In this case, I feel that a somewhat common, but none the less = unfortunate, choice is made. I'll again emphasize the "control cost" = metric. As it would be, we should not really care for the specific = "control cost" but rather "the total cost of getting traffic from the = source to the destination. This includes the control cost that = incurs, of course, but not only: the cost of carrying data traffic = should be considered as well. If the data traffic to be delivered is = non-zero, the latter often is important -- which is one good reason = for a routing protocol to trade of "control costs" for attaining = "shorter/shortest paths" (according to whatever metric). Hence, in an absolute sense, the metric "control cost" when taken = alone does not state anything regarding a specific protocols' = applicability to any domain: it does not indicate anything regarding = the network load attained, nor on energy conservation (recognizing = that transmission/receipt of *any* packet loads the network and = requires energy from the relays). I return on my caricature and propose a zero control-cost, zero state = protocol, instant-convergence which goes "whenever you have data to = deliver, flood it, and don't do any duplicate elimination". It'd = score well according to the metrics -- but I assume that we agree = that it'd be a particularly unsuitable protocol for general data = delivery? > We could make a moving target of this doc and pursue the quest of = > the perfect evaluation of life, the universe and everything. But = > that's not the motivation nor the best interest of this group. I'm not encouraging that. I'm encouraging that a couple of missing = pieces be added to the document, and that without those pieces the = document isn't particularly helpful for the group. > In any case, do we expect a perfect one-fit-it-all protocol? I = > guess not. I do not pretend to know that. And, my problem is that this I-D does = not help clarifying that at all. > We'll have to trade off and prioritize, so while the evaluation = > draft has mostly served its purpose, we are far from being done = > with the requirement drafts themselves. It seems to me that this is not in line with what the tracker = reveals. draft-ietf-roll-urban-routing-reqs is in IESG evaluation and = draft-ietf-roll-home-routing-reqs in last-call, which indicates that = the WG considers those to be done? Thomas > For instance, in the case of industrial, there is an emphasys on = > reliability vs. path cost, which *is actually* achieved in the real = > (non-IP) world by building graphs that tend to enable multiple = > forwarding solutions at each hop, with the capability to revise the = > forwarding decision on a frame by frame basis after a few L2 retries. > > There are deployed IP protocols that enable similar non-equal-cost = > path computation, for instance in the DV world with EIGRP feasible = > successors. There is a huge amount of reusable art in traffic = > engineering. There is also interesting art in academia such as Tora = > that might fit the bill. What we need to do is build on this = > experience and start the work on real solutions to figure what = > optimum we can actually achieve for our requirements. > > Pascal > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On = >> Behalf Of Thomas Heide Clausen >> Sent: mardi 9 d=E9cembre 2008 16:21 >> To: JP Vasseur (jvasseur) >> Cc: Dearlove, Christopher (UK); Emmanuel Baccelli; roll@ietf.org >> Subject: Re: [Roll] WorkingGroup LastCall:draft-ietf-roll- = >> protocols-survey-02 >> >> >> On Dec 9, 2008, at 16:13 PM, JP Vasseur wrote: >> >>> >>> On Dec 9, 2008, at 4:03 PM, Dearlove, Christopher (UK) wrote: >>> >>>> >>>>> 2- There is clearly a need for a solution *today*: look at all = >>>>> other >>>>> (deployed) non IP solutions out there >>>> >>>>> 4- We are not talking about a "dream protocol": again this is very >>>>> much realistic since solutions do exist today (not IP = >>>>> unfortunately >>>> :-( ....) >>>> >>>> Can you point me to an existing (doesn't have to be IP) protocol >>>> that passes all five of the ID's tests, without some major drawback >>>> in some other area. I for one would find it interesting and useful. >>>> (Obviously it would have to have a specification, not just a claim >>>> made about a proprietary protocol.) >>> >>> You missed my point ... I did not say that there were any of them >>> satisfying these criterion. >>> But clearly there are non IP solutions being deployed, my point >>> being that we need an >>> IP solution soon and we should make it right. >> >> I read Chris Dearlove as asking for something concrete, justifying >> that these five "criteria" that the survey I-D sets out are >> *attainable* (and without some major drawbacks on the other important >> metrics that the survey I-D is ignoring) and that we're not chasing a >> "pie in the sky". >> >>>> If one or more such protocols exist, I don't see why they aren't >>>> discussed at this stage. >>> >>> I do not think that it is in our charter to analyze *all* possible >>> protocols. >> >> No, but if a good such protocol indeed existed, IP or not, having it >> before us might just help quell skepticism. >> _______________________________________________ >> 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 Dec 15 23:25:26 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB33D3A6A56; Mon, 15 Dec 2008 23:25:26 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C7543A67F6 for ; Mon, 15 Dec 2008 23:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=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 fmPo5uznaTHw for ; Mon, 15 Dec 2008 23:25:24 -0800 (PST) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id E09ED3A6A57 for ; Mon, 15 Dec 2008 23:25:23 -0800 (PST) Received: from [129.104.11.1] (helo=[192.168.112.180]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LCUIu-000250-8R; Tue, 16 Dec 2008 07:25:16 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 129.104.11.1 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX193ZtZJBS2sNOvqkOGUb/bT In-Reply-To: <95CE6683-9834-430C-937D-32A034C87175@cs.stanford.edu> References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <710F3638-03FD-460F-8AB2-DC4100832F3B@thomasclausen.org> <95CE6683-9834-430C-937D-32A034C87175@cs.stanford.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <8C365038-B7A6-4517-A1B5-BDC3AA81827C@ThomasClausen.org> From: Thomas Heide Clausen Date: Tue, 16 Dec 2008 08:24:19 +0100 To: Philip Levis X-Mailer: Apple Mail (2.753.1) Cc: charliep@computer.org, roll@ietf.org Subject: Re: [Roll] Review and concerns (was: Re: Working Group Last Call: draft-ietf-roll-protocols-survey-02) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Dear Philip, On Dec 9, 2008, at 6:58 PM, Philip Levis wrote: > > On Dec 8, 2008, at 8:00 AM, Thomas Heide Clausen wrote: > >> Dear All, >> >> I've been reviewing the latest incarnation of this I-D, and I have >> a couple of general concerns with this I-D and, more specifically, >> with the approach it seems to be suggesting for the working group. > > Well, the approach is the general consensus the working group > reached after discussing the topic over the past year or so. It may be so, and it may be entirely fair to decide to survey protocols based on a set of metrics, and to establish a set of metrics/criteria against which any ROLL protocol should be measured. However, in that case, I still think that the approach is wrong. It would be a LOT cleaner to stipulate such metrics in an isolated I-D, rather than embed those in a "protocol survey". That way, these evaluation criteria could be used to, objectively, evaluate both existing routing proposals, as well as whatever "new" proposals that were made on a level playing field. It is not clear as- is if the standard to which the protocols in this I-D is held is ALSO going to be that to which any "new" proposal is going to be held; the I-D does not answer this, the charter does not answer this, the other WG I-Ds do not answer this -- and I see postings talking about "trade- offs are necessary" on the list, but I do not know if that also implies trading-off on the criteria in the survey I-D. If the answer is that the standard / set of criteria is to be the same, then I'd encourage that those be exposed and explored in isolation, and then applied to the different protocols later. If the answer is "no, there may be trade-offs also on those criteria, when we come to building protocols", then I am convinced that the approach is inappropriate. Regardless of what approach is taken of the above, I do disagree with the specifics of the choice of metrics: * the set of metrics chosen, as I believe those to be incomplete and to lead to the wrong conclusions being drawn; * the fact that the I-D considers the selected metrics to be with bounds that are "set in stone", and not subject to trade-offs -- especially when the trade offs *may* reflect substantial gains on other metrics not considered See also my reply to Pascal for an example hereof. >> o The document seems to set the bar of acceptance at "the holy >> grail of a routing protocol", >> i.e. defines "acceptable" to be "zero-cost [more on that in a >> following bullet], >> instant-convergence" -- thereby causing all routing protocols to >> almost by definition be >> judged "insufficient" -- which is reflected in the evaluation of >> the existing set of routing >> protocols. > > I don't quite follow "zero cost" and "instant-convergence;" the > cost metrics noted are clearly non-zero (and there are others not > described), while convergence is not placed as a criterion. > >> >> o As I assume ROLL is designing "for the real world", compromises >> and trade-offs are >> paramount in protocol design. By elevating a set of criteria >> (sec. 3 and 4 -- "table scalability", >> "loss response", "control cost", "link cost" and "node cost") >> above the rest, while pointing out >> that (i) an approach not meeting the bar on all of those is >> unacceptable and (ii) "applications >> introduce additional, more stringent, requirements", this I-D >> effectively limits the trade-offs >> possible for when designing protocols for these applications. > > I'm not sure I'd agree with your claim that the criteria set are > not reasonable "for the real world." In particular, there are > several members of the WG who have designed, implemented, and > deployed protocols in products, scientific deployments, and other > real-world uses of L2Ns. They seem to think the criteria are > reasonable. See email to Pascal for example of why the metric "control cost" is not, in isolation, a useful metric unless one makes additional assumptions. Note, this is a single example, similar arguments could be made re. state, .... > Tradeoffs are a critical part of any real system. Note, however, > that the criteria specified should not be interpreted as MUST NOT > ever do more than X; rather, MUST work with only X. As a trivial > example, simply because a protocol's routing table needs to be able > to scale with O(D) doesn't mean a protocol can't maintain a table > larger than O(D). The former ensures that the design mechanisms are > reasonable for the low-power devices L2Ns necessitate; the latter > provides actual deployment and implementation flexibility. For > these classes of networks, making the minimum resource requirements > low is critical. > >> >> o Going by where the bar for acceptance is set in this document, >> I have thought and come >> up with indeed two solutions that have "zero-cost-instant- >> convergence" properties, and >> they both satisfy the IP delivery semantics. One is "drop all >> traffic, don't even try" and the >> other is "flood all traffic, don't maintain a routing table". >> >> Of course, those two proposals are in jest, as I am sure that >> the trade-off I am making >> -- sacrificing delivery ratio for the former, satisfying network >> traffic and energy (but not >> as a consequence of the routing protocol relaying control >> traffic) for the latter are not >> acceptable in an absolute sense -- but the routing protocol will >> itself require have >> zero-cost, zero-memory, instant-convergence. > > I thought the document was pretty clear: there could be protocols > which meet the criteria in the document yet are not sufficient. > There are obviously other considerations. But as the question the > document seeks to answer -- "Can ROLL use existing standards > unchanged" -- is much narrower than "What should a protocol look > like?" The purpose of this narrow scope is to allow the WG to > answer the question without debating minutia on whether a > particular criterion is more or less important. That is something > for later WG discussion. I think that this is not the right conclusion to draw here. If you want to determine if an existing routing solution can be used unchanged, then you MUST necessarily know what you expect that routing solution to look like, at least in an abstract sense, and certainly to determine whether a particular criterion is more or less important. I.e. to determine if an existing solution is applicable, you MUST determine which trade-offs you're ready to make. Otherwise, it could appear as if the goal was to simply go through the motions of dismissing "not-invented-here" proposals. >> o From the previous and first bullet, "control cost" is an >> insufficient measure. "Flooding all >> data" has zero "control cost" but a large overall cost (many >> retransmissions, lots of battery >> drain, lots of media use). A routing protocol incurring some >> "control cost" to gain lower >> "data transmission cost" likely is a better tradeoff, >> especially if data traffic is a common >> occurrence in the network. >> >> IOW, looking at "control cost" as a separate metric is not >> terribly useful unless the >> consequences in terms of the "data cost" and "data delivery >> ratio" are considered >> as well. >> > > I think you're reading this document in a way in which it was never > intended, pretty explicitly so. This draft does not say "if a > protocol meets these requirements, then it is OK." Otherwise, we > end up in an adversarial situation, like the one you outline above, > where we're trying to find holes in the criteria. Adding criteria > such as "delivers data" would be a bit silly, adding complexity to > the document when we all know that's of course important. Again, no. Looking at *a* criteria such as "control cost" in isolation has the inherent problem of not being useful. As I state in my email to Pascal, we do not CARE about "control cost", we care about "minimizing the total load on the network". Be as it may, one could trade off "a bit of control cost for a lot of path-shortening", which would be highly beneficial when you have actual data over the network. >> Chris Dearlove summarize well in saying that the document does >> well in setting out a rigid set of "pass" criteria and observing >> that none of the six protocols analyzed satisfies those off-the- >> shel -- but that this should not be stretched to assume that an >> entirely new design is required. > > Please read through the mail archives. At no point has the document > ever claimed so, and I've tried to be very very explicit in this. > At the interim meeting, I was asked the question of "so what should > we do next," and I demurred. The introduction is VERY explicit: > > "Whether or not such a protocol involves modifications to an > existing protocol or a new protocol entirely is outside the scope > of this document: this document simply seeks to answer the > question: do LLNs require a new protocol specification document at > all?" > > This concern with the document comes up again and again, and I cite > the same points. For some reason readers come away with an > impression of the document's claims which are completely contrary > to its text. Do you have any suggestions on how we could make the > document clearer? I am not sure that adding an explanatory text to the introduction would resolve the issue I have with this document. >> I also join Chris in his comment that, for example, OLSRv2 offers >> "timing backoff" and "fisheye variable flooding" without >> variations to the routing protocol [the specificities of how to >> set timers or vary flooding is a policy matter that is dependent >> on deployment, but can be done entirely conformant with its >> specification] -- and that this is not considered. I'll go further >> than Chris and suggest that not considering the use of such >> options, which are present in the protocols but where a policy >> specification dependent on deployment is required, casts doubt on >> the assessment of the protocols as presented - not just OLSRv2, >> but such options exist for other protocols as well. > > Unfortunately, neither of these are specified in RFCs or mature > drafts. Mario Gerla is wonderful and has great ideas, but it's > tough to argue that analytical papers from almost a decade ago > definitively establish the efficacy of a protocol mechanism well > enough to determine IETF protocol specification. I find it curious that an analytical study by Gerla is being dismissed for a document emphasizing O(...) evaluations. I also note that there're deployments of e.g. fisheye mechanisms "out there", I am aware of some in the context of OLSR(v2) -- and that the OLSRv2 specification explicitly contains what's needed for that. The parametrization for a given deployment is, of course, deployment- dependent. Thomas _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Dec 15 23:29:12 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AFD73A6A2C; Mon, 15 Dec 2008 23:29:12 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73D1A3A6A2C for ; Mon, 15 Dec 2008 23:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 zSOD4izE+ffp for ; Mon, 15 Dec 2008 23:29:10 -0800 (PST) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id E90493A67EE for ; Mon, 15 Dec 2008 23:29:09 -0800 (PST) Received: from [129.104.11.1] (helo=[192.168.112.180]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LCUMV-00032J-V7; Tue, 16 Dec 2008 07:29:00 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 129.104.11.1 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19Q6V5XjJ1Dhe6lpamnnltG In-Reply-To: <6A3B39C4-8126-47D0-B29A-752191F4F487@cs.stanford.edu> References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> <3CEA849E-22CD-4DF1-A56B-E1C38572AA77@cisco.com> <6A3B39C4-8126-47D0-B29A-752191F4F487@cs.stanford.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <5467B083-1300-4723-9B5D-F45D6AED701B@thomasclausen.org> From: Thomas Heide Clausen Date: Tue, 16 Dec 2008 08:28:02 +0100 To: Philip Levis X-Mailer: Apple Mail (2.753.1) Cc: Emmanuel Baccelli , arsalan@eecs.berkeley.edu, roll@ietf.org Subject: Re: [Roll] Working Group Last Call:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Dec 9, 2008, at 8:47 PM, Philip Levis wrote: > > On Dec 9, 2008, at 7:30 AM, JP Vasseur wrote: >> >> Please find below the minutes of the ROLL Interim Working Group >> meeting that was help in San Jose on Oct 6. >> >> This was an excellent very productive meeting where we managed to >> make good progress and reached a consensus on an important >> question related to a key Milestone.As usual such consensus must >> be confirmed on the mailing list. >> >> When ROLL got chartered, one of our key milestones was to >> determined after some careful analysis of the routing requirements >> whether or not we could find an existing protocols that would meet >> our routing requirement with no change (with no protocol changes). >> All participants to the interim meeting agreed that there was no >> existing protocol that would meet the ROLL routing requirements >> *with no protocol work*. Do not hesitate to express your opinion >> on the mailing list before Oct 17 and then we will document the WG >> decision. > > I think this is the key point. > > The #1 question is whether the concerns on structure, criteria, > etc. will change the conclusion of the document. If someone has > strong evidence that existing protocols, as specified, can meet the > requirements of ROLL, then that information would be of fantastic > use and value to ROLL. But we seem to have consensus on this point: > existing IETF specifications do not meet the requirements L2Ns > introduce. > Be VERY careful, though: as I read the document, it sets a bar VERY high on some areas and VERY low in others. And, like it or not, this document does read "as if" it was a "ROLL routing solutions criteria specification". And, as such, it is incomplete. > More specifically, if there's a disagreement with the conclusion of > the document, then this means one of two things: > > 1) The analysis of an existing protocol is incorrect > 2) A criterion is too harsh and should be weaker > No, wrong conclusion, there's a third option: 3) The set of criteria is incomplete, and additional criteria should be added in order to complete the evaluation and guide the wg forward. Thomas > The domain experts who have written the application drafts are the > best commentators on 2); in fact, one of the criteria (control > cost) did relax slightly based on feedback at the interim meeting. > > So this leaves 1). The authors of TBRPF made some very helpful > comments on the TBRPF analysis early in the document's lifetime, > and we amended it appropriately. If there are other entries that > are incorrect, then a statement of the correct analysis would be > the best way to make the document more accurate. > > Everything else besides this is really ancillary; we can debate at > length whether there should be 4, 5, or 8 criteria, but if the > conclusion is the same, then all this debate does is stifle ROLL > from doing useful work. > > Of course the document can be improved and comments are welcome. In > the last revision, a few readers pointed out many things which were > unclear, and which Stephen, Arsalan, and I tried to clarify. For > example, it's critical that the document be very transparent on the > methodology it uses and how it reaches its conclusions. > > Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Dec 16 05:08:08 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A3A63A6A7A; Tue, 16 Dec 2008 05:08:08 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7F9B3A6A74 for ; Tue, 16 Dec 2008 05:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, HELO_EQ_IP_ADDR=1.119] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPXnjLShZ06d for ; Tue, 16 Dec 2008 05:08:06 -0800 (PST) Received: from cs.tcd.ie (relay.cs.tcd.ie [IPv6:2001:770:10:200:214:4fff:feb0:ab6c]) by core3.amsl.com (Postfix) with ESMTP id 174493A6883 for ; Tue, 16 Dec 2008 05:08:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by relay.cs.tcd.ie (Postfix) with ESMTP id F383B3EF3C; Tue, 16 Dec 2008 13:07:56 +0000 (GMT) X-Virus-Scanned: amavisd-new at cs.tcd.ie Received: from cs.tcd.ie ([127.0.0.1]) by localhost (smtp.cs.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Kzr6a4mpP6s; Tue, 16 Dec 2008 13:07:56 +0000 (GMT) Received: from [134.226.62.18] (cswireless62-18.cs.tcd.ie [134.226.62.18]) by smtp.cs.tcd.ie (Postfix) with ESMTP id 7A8F93EF11; Tue, 16 Dec 2008 13:07:54 +0000 (GMT) Message-ID: <4947A850.9030305@cs.tcd.ie> Date: Tue, 16 Dec 2008 13:08:32 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: Philip Levis References: <49417D7A.7060706@eecs.berkeley.edu> In-Reply-To: X-Enigmail-Version: 0.95.7 Cc: ROLL WG Subject: Re: [Roll] Review and concerns X-BeenThere: roll@ietf.org X-Mailman-Version: 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: > In the case of DTN, it's IRTF. Yes it is. But of course that's a good and not a bad thing:-) Anyway FYI (I've not read the draft so I don't have "concerns"), there is one routing protocol (PRoPHET) defined in an I-D by the DTNRG, [1] and that's nearly ready to start becomming an RFC. Note that PRoPHET is not "the" routing scheme for DTNs (there are others, some of which claim to be better) but it is the only one defined in an I-D afaik, so it may well meet your criteria for inclusion. I've no idea if PRoPHET would be good, bad or indifferent in meeting your requirements were it to be included in the survey. Also - if this WG wants to ask DTN folks if they've something else to offer, feel free to mail the dtn-interest list [2] - I don't recall seeing anything from ROLL on that list (but I may have forgotten). Regards, Stephen. (DTNRG co-chair) [1] http://tools.ietf.org/html/draft-irtf-dtnrg-prophet [2] http://mailman.dtnrg.org/mailman/listinfo/dtn-interest/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Dec 16 09:47:13 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24BF33A684F; Tue, 16 Dec 2008 09:47:13 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 306A23A6906 for ; Tue, 16 Dec 2008 09:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAiTl+jEUAWS for ; Tue, 16 Dec 2008 09:47:11 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 8ECBD3A67E2 for ; Tue, 16 Dec 2008 09:47:11 -0800 (PST) Received: from dnab42227a.stanford.edu ([171.66.34.122]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1LCe0e-0007dH-I8; Tue, 16 Dec 2008 09:47:04 -0800 Message-Id: <26FA91B0-A0BA-44EB-9536-29B302EF58AC@cs.stanford.edu> From: Philip Levis To: Emmanuel Baccelli In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 16 Dec 2008 09:08:10 -0800 References: <49417D7A.7060706@eecs.berkeley.edu> X-Mailer: Apple Mail (2.929.2) X-Scan-Signature: 9c8d7c79e82d9ccd3af9a51b4d3246f3 Cc: ROLL WG Subject: Re: [Roll] Review and concerns (was: Re: Working Group Last Call: draft-ietf-roll-protocols-survey-02) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Dec 15, 2008, at 11:50 AM, Emmanuel Baccelli wrote: > > Then at least give the gist of the discussions on the subject, to > explain in the draft why the charter is not covered. > > However, at the time the charter was written, DTN was already IRTF, > and unless I am mistaken, except OSPF, none of the routing protocols > are standards-track, so these reasons are not enough, in my mind. > > Why discard things that are chartered? Maybe the charter was not > well written. But this must be justified in the draft. The whole > point is that this draft is incomplete, and that this incompleteness > i not justified in anyway other than hand-waving. I agree -- it is appropriate to put the reasoning behind their omission in the document itself. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Dec 16 09:47:14 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5000A3A6A9A; Tue, 16 Dec 2008 09:47:14 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC5FB3A67E2 for ; Tue, 16 Dec 2008 09:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJvvgox7rn9p for ; Tue, 16 Dec 2008 09:47:12 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 2FA153A684F for ; Tue, 16 Dec 2008 09:47:12 -0800 (PST) Received: from dnab42227a.stanford.edu ([171.66.34.122]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1LCe0f-0007dH-3e; Tue, 16 Dec 2008 09:47:05 -0800 Message-Id: From: Philip Levis To: JP Vasseur In-Reply-To: <173272AB-937B-48CA-A07C-B6B2B7EF97C2@cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 16 Dec 2008 09:09:50 -0800 References: <493EF103.7050908@eecs.berkeley.edu> <1229019696.5870.32.camel@dellx1> <6F6D8A57-2129-4DD6-BC1E-D845F87580CC@cisco.com> <49459435.3020700@eecs.berkeley.edu> <1229351894.5870.115.camel@dellx1> <173272AB-937B-48CA-A07C-B6B2B7EF97C2@cisco.com> X-Mailer: Apple Mail (2.929.2) X-Scan-Signature: 980022258218d8e0da9e8fd80fb6777b Cc: roll@ietf.org, "David E. Culler" Subject: Re: [Roll] Review and concerns X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Dec 15, 2008, at 7:36 AM, JP Vasseur wrote: > Hi Geoff, > > On Dec 15, 2008, at 3:38 PM, Geoff Mulligan wrote: > >> David, >> I guess I didn't find any discussion of IS-IS. I see that IS-IS is >> described as a link state protocol (like OSPF) but thats all I >> found. I >> don't know the nuances of the differences between IS-IS and OSPF to >> be >> able to know that they are so similar that IS-IS didn't need to >> examined >> separately rather than group with all link state protocols. >> > > Thanks for your feed-backs but yes indeed, looking at the criterion > we're interested in, the conclusions > equally apply to both routing protocols. JP is correct. We will add a sentence stating this. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Dec 16 09:47:19 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A3AA3A6AAB; Tue, 16 Dec 2008 09:47:19 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A13A93A6AAB for ; Tue, 16 Dec 2008 09:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.506 X-Spam-Level: X-Spam-Status: No, score=-1.506 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lspgUGMZ4TDS for ; Tue, 16 Dec 2008 09:47:17 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id E7E703A6AAA for ; Tue, 16 Dec 2008 09:47:16 -0800 (PST) Received: from [192.168.7.43] (69-12-164-138.sfo.archrock.com [69.12.164.138]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id mBGHl1Ki006077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Dec 2008 09:47:03 -0800 (PST) Message-ID: <4947E98F.3010104@eecs.berkeley.edu> Date: Tue, 16 Dec 2008 09:46:55 -0800 From: "David E. Culler" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Stephen Farrell References: <49417D7A.7060706@eecs.berkeley.edu> <4947A850.9030305@cs.tcd.ie> In-Reply-To: <4947A850.9030305@cs.tcd.ie> Cc: ROLL WG Subject: Re: [Roll] Review and concerns X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============1939299923==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1939299923== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit That's very useful guidance.  Thanks.

Stephen Farrell wrote: 
Philip Levis wrote:
  
In the case of DTN, it's IRTF.
    

Yes it is. But of course that's a good and not a bad thing:-)

Anyway FYI (I've not read the draft so I don't have "concerns"),
there is one routing protocol (PRoPHET) defined in an I-D by
the DTNRG, [1] and that's nearly ready to start becomming an RFC.
Note that PRoPHET is not "the" routing scheme for DTNs (there
are others, some of which claim to be better) but it is the
only one defined in an I-D afaik, so it may well meet your
criteria for inclusion. I've no idea if PRoPHET would be good,
bad or indifferent in meeting your requirements were it to
be included in the survey.

Also - if this WG wants to ask DTN folks if they've something
else to offer, feel free to mail the dtn-interest list [2] - I
don't recall seeing anything from ROLL on that list (but I
may have forgotten).

Regards,
Stephen. (DTNRG co-chair)

[1] http://tools.ietf.org/html/draft-irtf-dtnrg-prophet
[2] http://mailman.dtnrg.org/mailman/listinfo/dtn-interest/

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--===============1939299923== 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 --===============1939299923==-- From roll-bounces@ietf.org Wed Dec 17 03:27:16 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C810528C19C; Wed, 17 Dec 2008 03:27:16 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F5C928C19C for ; Wed, 17 Dec 2008 03:27:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.422 X-Spam-Level: X-Spam-Status: No, score=-10.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1Doern0u1Gt for ; Wed, 17 Dec 2008 03:27:04 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 61F1128C19B for ; Wed, 17 Dec 2008 03:27:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,236,1228089600"; d="scan'208";a="28876162" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Dec 2008 11:26:52 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mBHBQqv1017652; Wed, 17 Dec 2008 12:26:52 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBHBQp0V021782; Wed, 17 Dec 2008 11:26:51 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Dec 2008 12:26:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 17 Dec 2008 12:26:46 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC06B356B1@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] WorkingGroup LastCall:draft-ietf-roll-protocols-survey-02 Thread-Index: AclfS4jAyq5B/L4NSm6zyClBHxlmGgA60iFA References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> <61D43925-D96D-41A0-A73B-E87B586245E3@thomasclausen.org> <7892795E1A87F04CADFCCF41FADD00FC06ADE37A@xmb-ams-337.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Thomas Heide Clausen" X-OriginalArrivalTime: 17 Dec 2008 11:26:51.0746 (UTC) FILETIME=[5B926420:01C9603A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7793; t=1229513212; x=1230377212; 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]=20WorkingGroup=09LastCall=3Adraf t-ietf-roll-protocols-survey-02 |Sender:=20; bh=5cm2vTB2zn0QUVmUcGbcVBIFgt6DkuGPCwuh1jKXgRI=; b=j12Bnh146tAMllAuYZue8cf6r5SCGOLteEjIehg8FAJcqnQU8iy1VIcRh7 +ofx/G31Ba3Anrfq/dbBSF5IyfoU7zGA/Eg4O4yDBC6PBXRa3DnOJtMulERU ahdWjCFhPp; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "Dearlove, Christopher \(UK\)" , Emmanuel Baccelli , roll@ietf.org Subject: Re: [Roll] WorkingGroup LastCall:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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 Thomas: What I mean is that the requirement drafts will be the source of the work t= o come, as opposed to the evaluation draft that merely indicates that there= is work to be done. So we need to focus on fulfilling the requirements in = a way that makes sense, and your comments below shed a clear light on what = making sense means. Sometime soon, I hope we'll see a number of proposed approaches and we'll n= eed to evaluate them so as to select (at least) one and refine it to standa= rd quality. Those new approaches should be a lot more specific to the ROLL = problem and probably a lot more tricky to classify wrt the requirements. Th= us more refined criteria will most certainly be needed and this discussion = is certainly a good preparation. Clearly the total cost of getting packets though is a great metric. It has = to be balanced with expected latency, stealth/deep sleep capabilities and s= o on. Seems to me though that we should focus on where the proposals actual= ly make a difference between one another and figure which exhibits the most= crucial benefits for our requirements; but we can only do that once we hav= e proposals on the table. Pascal >-----Original Message----- >From: Thomas Heide Clausen [mailto:ietf@thomasclausen.org] >Sent: mardi 16 d=E9cembre 2008 07:56 >To: Pascal Thubert (pthubert) >Cc: JP Vasseur (jvasseur); Dearlove, Christopher (UK); Emmanuel Baccelli; = roll@ietf.org >Subject: Re: [Roll] WorkingGroup LastCall:draft-ietf-roll-protocols-survey= -02 > >Hi Pascal, > >Long time no see -- hope all is well in the south? > >On Dec 9, 2008, at 6:32 PM, Pascal Thubert (pthubert) wrote: > >> Hi Thomas: >> >> Every evaluation picks criteria and applies them. This doc has been >> around for awhile with its own clear list of criteria, which take >> their source in the requirements drafts. Someone could propose >> another doc with another set of criteria that would make perfect >> sense for a different set of requirements. >> > >Right, I appreciate that any evaluation is the result of a choice of >criteria -- and that's fine as such. However the choice has to be >sensible such that the conclusions that can be drawn are useful. > >In this case, I feel that a somewhat common, but none the less >unfortunate, choice is made. I'll again emphasize the "control cost" >metric. As it would be, we should not really care for the specific >"control cost" but rather "the total cost of getting traffic from the >source to the destination. This includes the control cost that >incurs, of course, but not only: the cost of carrying data traffic >should be considered as well. If the data traffic to be delivered is >non-zero, the latter often is important -- which is one good reason >for a routing protocol to trade of "control costs" for attaining >"shorter/shortest paths" (according to whatever metric). > >Hence, in an absolute sense, the metric "control cost" when taken >alone does not state anything regarding a specific protocols' >applicability to any domain: it does not indicate anything regarding >the network load attained, nor on energy conservation (recognizing >that transmission/receipt of *any* packet loads the network and >requires energy from the relays). > >I return on my caricature and propose a zero control-cost, zero state >protocol, instant-convergence which goes "whenever you have data to >deliver, flood it, and don't do any duplicate elimination". It'd >score well according to the metrics -- but I assume that we agree >that it'd be a particularly unsuitable protocol for general data >delivery? > >> We could make a moving target of this doc and pursue the quest of >> the perfect evaluation of life, the universe and everything. But >> that's not the motivation nor the best interest of this group. > >I'm not encouraging that. I'm encouraging that a couple of missing >pieces be added to the document, and that without those pieces the >document isn't particularly helpful for the group. > >> In any case, do we expect a perfect one-fit-it-all protocol? I >> guess not. > >I do not pretend to know that. And, my problem is that this I-D does >not help clarifying that at all. > >> We'll have to trade off and prioritize, so while the evaluation >> draft has mostly served its purpose, we are far from being done >> with the requirement drafts themselves. > >It seems to me that this is not in line with what the tracker >reveals. draft-ietf-roll-urban-routing-reqs is in IESG evaluation and >draft-ietf-roll-home-routing-reqs in last-call, which indicates that >the WG considers those to be done? > >Thomas > >> For instance, in the case of industrial, there is an emphasys on >> reliability vs. path cost, which *is actually* achieved in the real >> (non-IP) world by building graphs that tend to enable multiple >> forwarding solutions at each hop, with the capability to revise the >> forwarding decision on a frame by frame basis after a few L2 retries. >> >> There are deployed IP protocols that enable similar non-equal-cost >> path computation, for instance in the DV world with EIGRP feasible >> successors. There is a huge amount of reusable art in traffic >> engineering. There is also interesting art in academia such as Tora >> that might fit the bill. What we need to do is build on this >> experience and start the work on real solutions to figure what >> optimum we can actually achieve for our requirements. >> >> Pascal >> >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >>> Behalf Of Thomas Heide Clausen >>> Sent: mardi 9 d=E9cembre 2008 16:21 >>> To: JP Vasseur (jvasseur) >>> Cc: Dearlove, Christopher (UK); Emmanuel Baccelli; roll@ietf.org >>> Subject: Re: [Roll] WorkingGroup LastCall:draft-ietf-roll- >>> protocols-survey-02 >>> >>> >>> On Dec 9, 2008, at 16:13 PM, JP Vasseur wrote: >>> >>>> >>>> On Dec 9, 2008, at 4:03 PM, Dearlove, Christopher (UK) wrote: >>>> >>>>> >>>>>> 2- There is clearly a need for a solution *today*: look at all >>>>>> other >>>>>> (deployed) non IP solutions out there >>>>> >>>>>> 4- We are not talking about a "dream protocol": again this is very >>>>>> much realistic since solutions do exist today (not IP >>>>>> unfortunately >>>>> :-( ....) >>>>> >>>>> Can you point me to an existing (doesn't have to be IP) protocol >>>>> that passes all five of the ID's tests, without some major drawback >>>>> in some other area. I for one would find it interesting and useful. >>>>> (Obviously it would have to have a specification, not just a claim >>>>> made about a proprietary protocol.) >>>> >>>> You missed my point ... I did not say that there were any of them >>>> satisfying these criterion. >>>> But clearly there are non IP solutions being deployed, my point >>>> being that we need an >>>> IP solution soon and we should make it right. >>> >>> I read Chris Dearlove as asking for something concrete, justifying >>> that these five "criteria" that the survey I-D sets out are >>> *attainable* (and without some major drawbacks on the other important >>> metrics that the survey I-D is ignoring) and that we're not chasing a >>> "pie in the sky". >>> >>>>> If one or more such protocols exist, I don't see why they aren't >>>>> discussed at this stage. >>>> >>>> I do not think that it is in our charter to analyze *all* possible >>>> protocols. >>> >>> No, but if a good such protocol indeed existed, IP or not, having it >>> before us might just help quell skepticism. >>> _______________________________________________ >>> 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 Dec 17 09:05:10 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D75D28C19B; Wed, 17 Dec 2008 09:05:10 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5664428C19B for ; Wed, 17 Dec 2008 09:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.558 X-Spam-Level: X-Spam-Status: No, score=-10.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8Iq1ajbfNcs for ; Wed, 17 Dec 2008 09:05:08 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 39B4628C170 for ; Wed, 17 Dec 2008 09:05:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,238,1228089600"; d="scan'208,217";a="28922436" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Dec 2008 17:04:54 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mBHH4sV1009446; Wed, 17 Dec 2008 18:04:54 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBHH4sqd028441; Wed, 17 Dec 2008 17:04:54 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Dec 2008 18:04:54 +0100 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Dec 2008 18:04:53 +0100 Message-Id: <260E044E-1C74-4C4D-9BF4-0A79E1A39177@cisco.com> From: JP Vasseur To: Thomas Heide Clausen , Emmanuel Baccelli , "Christopher (UK) Dearlove" In-Reply-To: <5467B083-1300-4723-9B5D-F45D6AED701B@thomasclausen.org> Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 17 Dec 2008 18:04:52 +0100 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> <3CEA849E-22CD-4DF1-A56B-E1C38572AA77@cisco.com> <6A3B39C4-8126-47D0-B29A-752191F4F487@cs.stanford.edu> <5467B083-1300-4723-9B5D-F45D6AED701B@thomasclausen.org> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 17 Dec 2008 17:04:53.0907 (UTC) FILETIME=[94AE8E30:01C96069] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11993; t=1229533494; x=1230397494; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Proposal=20so=20as=20to=20reach=20a=20consensus =20on=20**=20draft-ietf-roll-protocols-survey-02=20** |Sender:=20; bh=c4cDHdd3jeyodMTJ2p4yuS3elUhwIOCa32sXidCABnc=; b=hHzWfE6dl4cnOobzvYEykubdp4xCSFgypfvBOscQBv3rFb6qaHZaYr3sWJ bwXB8lmSKNr01QX7Lae6TUt8wJDPjHd4l0aYLjb1PVtEYk7R45osp6IqZOFs xFXAYTeSGV; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org, Arsalan Tavakoli , "David E. Culler" Subject: [Roll] Proposal so as to reach a consensus on ** draft-ietf-roll-protocols-survey-02 ** X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============1787949354==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1787949354== Content-Type: multipart/alternative; boundary=Apple-Mail-46--29293956 --Apple-Mail-46--29293956 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, First of all, thanks for all the comments; even late comments are very much welcome to improve the quality of the document. I'm sure that there is only a communication issue, and we all want to have a constructive approach so as to quickly reach a consensus. I would just want to stress a few facts before making a proposal: 1) We have limited time: non-IP and proprietary protocols/ architectures/solutions are being deployed today and the industry is asking for an IP-based routing protocol for LLN: we do need to do the right thing but we can't afford to argue for ever on issues that will not change the overall conclusion, 2) All the requirements documents have been written by authors with a real-world experience, 4) Designing a protocol that will fulfill those requirements is feasible (since some of them do exist today). See the "requirements" section below. So far I think that we are on the same page. Our charter First, spell out a set of requirements for a few limited applications (almost complete). Second, answer to this explicitly narrow question: "Can we use an *existing* IP protocols for LLNs ?". The protocol survey aims at answering this question. Not whether it should be a new protocol, an extension to an existing protocol, ... Other WG items are not relevant to this discussion. Requirements As you know, we are not currently chartered to work on protocols. We first had to express our requirements and see whether an existing protocol would meet these requirements. One cannot ask us to demonstrate that we can design such a protocol without being chartered to do so. That being said, considering the number of existing and deployed protocols in the field designed by some of the people who wrote the requirements, we can have a good level of confidence that such objective is achievable. For the record, I've been working myself on such protocols for some time. Just two important comments with regards to "requirements". 1- Requirements are "guidelines". When time will come to work on protocol (if re-chartered), anybody will be more than welcome to propose a protocol (protocol extensions or new protocol). We will have to make compromise indeed. I would like to remind that we do not have to support all the MUST in a single instantiation of the protocol. There are ways to design protocols with options (there are many protocols that have this property). 2- I would also like to remind that we live in a highly constrained environment with small footprint (few hundreds of bytes in RAM for routing is not unusual). We could not afford to use an existing adapted protocol that would meet our requirements if it requires lots of extra memory for features that are not needed in LLNs. Any additional memory has a cost, which matters a lot to LLNs. Proposal Now, let's try to be constructive and address your concerns. 1) Lack of background, context, ... in the document. Emmanuel is quite right that background is missing in the document as well as a clear conclusion: "how have we chosen the protocols in the survey, why protocols X, Y, Z, ... have not been included in the survey, ...". I saw that Phil agreed to add some text to address this issue. Emmanuel, does that address your concern (to be confirmed once you see the text) ? Phil, could you please propose some text ? 2) Missing protocols: we had to draw the line somewhere. *LOTS* of protocols have been proposed over the last decade. We had many suggestions to also look at protocol X, Y and Z. The decision was (according to our charter) to limit our survey to existing IETF protocols (RFC or very mature ID): OSPF, OLSR, TBRPF, RIP, AODV, DYMO, DSR. The list is already fairly long. The charter mentions DTN. The WG decided not to include DTN and this needs to be documented. Phil, could you please add some text ? Note that this does not mean that we may not borrow mechanism(s) from existing protocols by the way if we get re-chartered. 3) Is the goal to exclude existing routing protocols as potential candidates ? The answer is "no" but Thomas is right, this is currently not well explained in the document. The objective is to agree that none of the existing protocols meet the requirement but the solution might either be to develop a new one or extend an existing routing protocol (once we get re-chartered). Thomas, would that address your concern ? 4) Evaluation metric should be in a separate document: the approached adopted by the WG was to derive metrics from the requirements documents so as to perform the protocol survey. Once we will start protocol design, we will go back to the requirement documents since this is *the* objective of Requirements IDs. 5) Missing Metrics and Incorrect Metrics: Let us know if you have a list of metrics that are in your opinion "missing" and which metrics are "incorrect/inappropriate"? Or are we now in agreement based on 4) above ? Let's try to quickly reach a consensus and continue the excellent progress of the WG so far. Many Thanks for your help. JP. --Apple-Mail-46--29293956 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi,

First of = all, thanks for all the comments; even late comments are very much = welcome to improve the quality of the document. I'm sure that there is = only a communication issue, and we all want to have a constructive = approach so as to quickly reach a consensus.

I = would just want to stress a few facts before making a = proposal:

1) We have limited time: non-IP and = proprietary protocols/architectures/solutions are being deployed today = and the industry is asking for an IP-based routing protocol for = LLN: we do need to do the right thing but we can't afford to argue for = ever on issues that will not change the overall = conclusion,
2) All the requirements documents have been = written by authors with a real-world experience,
4) Designing = a protocol that will fulfill those requirements is feasible (since some = of them do exist today). See the "requirements" section = below.

So far I think that we are on the same = page.

Our = charter

First, spell out a set of = requirements for a few limited applications (almost = complete).
Second, answer to this explicitly narrow question: = "Can we use an *existing* IP protocols for LLNs ?". = The protocol survey aims at answering this question. Not whether it = should be a new protocol, an extension to an existing protocol, = ... 
Other WG items are not relevant to this = discussion.

Requirements
=
As you know, we are not currently chartered = to work on protocols. We first had to express our requirements and see = whether an existing protocol would meet these requirements. One cannot = ask us to demonstrate that we can design such a protocol without being = chartered to do so. That being said, considering the number of existing = and deployed protocols in the field designed by some of the people who = wrote the requirements, we can have a good level of confidence that such = objective is achievable. For the record, I've been working myself on = such protocols for some time.

Just two = important comments with regards to = "requirements".

1- Requirements are = "guidelines". When time will come to work on protocol (if re-chartered), = anybody will be more than welcome to propose a protocol (protocol = extensions or new protocol). We will have to make compromise indeed. I = would like to remind that we do not have to support all the MUST in a = single instantiation of the protocol. There are ways to design = protocols with options (there are many protocols that have this = property).
2- I would also like to remind that we live in a = highly constrained environment with small footprint (few hundreds of = bytes in RAM for routing is not unusual). We could not afford to use an = existing adapted protocol that would meet our requirements if it = requires lots of extra memory for features that are not needed in LLNs. = Any additional memory has a cost, which matters a lot to = LLNs.

Proposal

=
Now, let's try to be constructive and address your = concerns.

1) Lack of background, context, = ... in the document. Emmanuel is quite right that background is = missing in the document as well as a clear conclusion: "how have we = chosen the protocols in the survey, why protocols X, Y, Z, ... have not = been included in the survey, ...". I saw that Phil agreed to add some = text to address this issue.
Emmanuel, does that address = your concern (to be confirmed once you see the text) = ?
Phil, could you please propose some text = ?

2) Missing protocols: we = had to draw the line somewhere. *LOTS* of protocols have been proposed = over the last decade. We had many suggestions to also look at protocol = X, Y and Z. The decision was (according to our charter) to limit our = survey to existing IETF protocols (RFC or very mature ID):  OSPF, = OLSR, TBRPF, RIP, AODV, DYMO, DSR. The list is already fairly long. The = charter mentions DTN. The WG decided not to include DTN and this needs = to be documented.
Phil, could you please add some text = ? Note that this does not mean that we may not borrow mechanism(s) = from existing protocols by the way if we get = re-chartered.

3) Is the goal to exclude = existing routing protocols as potential candidates ? The answer = is "no" but Thomas is right, this is currently not well explained in the = document. The objective is to agree that none of the existing protocols = meet the requirement but the solution might either be to develop = a new one or extend an existing routing protocol (once we get = re-chartered).
Thomas, would that address your concern = ?

4) Evaluation metric should be in a = separate document: the approached adopted by the WG was to derive = metrics from the requirements documents so as to perform the protocol = survey. Once we will start protocol design, we will go back to the = requirement documents since this is *the* objective of Requirements = IDs.

5) Missing Metrics and

Let's try to quickly reach a = consensus and continue the excellent progress of the WG so = far.

Many Thanks for your = help.

JP.



= --Apple-Mail-46--29293956-- --===============1787949354== 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 --===============1787949354==-- From roll-bounces@ietf.org Wed Dec 17 10:09:31 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D0EC28C1DB; Wed, 17 Dec 2008 10:09:31 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BC5528C1DA for ; Wed, 17 Dec 2008 10:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnZI-ZrzJ-gQ for ; Wed, 17 Dec 2008 10:09:27 -0800 (PST) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id AF32128C1BB for ; Wed, 17 Dec 2008 10:09:26 -0800 (PST) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mBHI9EOD027779 for ; Wed, 17 Dec 2008 18:09:15 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mBHI9Ehq017913 for ; Wed, 17 Dec 2008 18:09:14 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 17 Dec 2008 18:09:13 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 17 Dec 2008 18:09:13 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 17 Dec 2008 18:09:11 -0000 Message-ID: In-Reply-To: <260E044E-1C74-4C4D-9BF4-0A79E1A39177@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal so as to reach a consensus on ** draft-ietf-roll-protocols-survey-02 ** Thread-Index: AclgaZkRObb/KsJgQo25JQU9voixEwABRX8Q References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> <3CEA849E-22CD-4DF1-A56B-E1C38572AA77@cisco.com> <6A3B39C4-8126-47D0-B29A-752191F4F487@cs.stanford.edu> <5467B083-1300-4723-9B5D-F45D6AED701B@thomasclausen.org> <260E044E-1C74-4C4D-9BF4-0A79E1A39177@cisco.com> From: "Dearlove, Christopher (UK)" To: "JP Vasseur" , "Thomas Heide Clausen" , "Emmanuel Baccelli" X-OriginalArrivalTime: 17 Dec 2008 18:09:13.0254 (UTC) FILETIME=[91082C60:01C96072] Cc: roll@ietf.org, Arsalan Tavakoli , "David E. Culler" Subject: Re: [Roll] Proposal so as to reach a consensus on ** draft-ietf-roll-protocols-survey-02 ** X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============1160982360==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============1160982360== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C96072.908B9F7A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C96072.908B9F7A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not listed as an action below, as my main point was (and remains) the danger that this document will be read as saying more than any, more limited, consensus agreement, rather than that the document is bad, although I share some concerns over whether the requirements used are "right". But I'm not actually opposed to the narrow conclusion that no existing protocol surveyed is ideal as is. It's important to make it clear what is, and is not, being said. =20 Given all the real constraints on time etc., I think that the below is on the right track to improve the document. That leaves point 5 in the final list, which ties in with point 2 in the requirements list. I think the key issues are overall cost vs. "signalling" cost (it's the former that really matters) and latency. (Crudely, I can see at least three latency regimes - now, waiting for a route discovery process, a long term process such as various opportunistic store and forward approaches. Note that longer delays that may be necessitated by cutting down signalling storage have a potentially increased data queuing cost, back to the first point.) And finally (for this email) regarding various real solutions that put the onus on gateways to do critical work, have more storage and be more immediate and so on. The possible congestion and vulnerability issues of such key points may also be important. =20 Note that I'm not saying these points need to be addressed in detail here. It's more about putting down markers for the next stage, when these will matter. =20 (I'm not around much longer before the first full week in January incidentally.) --=20 Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 =20 ________________________________ From: JP Vasseur [mailto:jvasseur@cisco.com]=20 Sent: 17 December 2008 17:05 To: Thomas Heide Clausen; Emmanuel Baccelli; Dearlove, Christopher (UK) Cc: Philip Levis; Arsalan Tavakoli; Stephen Dawson-Haggerty; roll@ietf.org; David E. Culler Subject: Proposal so as to reach a consensus on ** draft-ietf-roll-protocols-survey-02 ** *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 =09 Hi,=20 First of all, thanks for all the comments; even late comments are very much welcome to improve the quality of the document. I'm sure that there is only a communication issue, and we all want to have a constructive approach so as to quickly reach a consensus. I would just want to stress a few facts before making a proposal: 1) We have limited time: non-IP and proprietary protocols/architectures/solutions are being deployed today and the industry is asking for an IP-based routing protocol for LLN: we do need to do the right thing but we can't afford to argue for ever on issues that will not change the overall conclusion, 2) All the requirements documents have been written by authors with a real-world experience, 4) Designing a protocol that will fulfill those requirements is feasible (since some of them do exist today). See the "requirements" section below. So far I think that we are on the same page. Our charter First, spell out a set of requirements for a few limited applications (almost complete). Second, answer to this explicitly narrow question: "Can we use an *existing* IP protocols for LLNs ?". The protocol survey aims at answering this question. Not whether it should be a new protocol, an extension to an existing protocol, ...=20 Other WG items are not relevant to this discussion. Requirements As you know, we are not currently chartered to work on protocols. We first had to express our requirements and see whether an existing protocol would meet these requirements. One cannot ask us to demonstrate that we can design such a protocol without being chartered to do so. That being said, considering the number of existing and deployed protocols in the field designed by some of the people who wrote the requirements, we can have a good level of confidence that such objective is achievable. For the record, I've been working myself on such protocols for some time. Just two important comments with regards to "requirements". 1- Requirements are "guidelines". When time will come to work on protocol (if re-chartered), anybody will be more than welcome to propose a protocol (protocol extensions or new protocol). We will have to make compromise indeed. I would like to remind that we do not have to support all the MUST in a single instantiation of the protocol. There are ways to design protocols with options (there are many protocols that have this property). 2- I would also like to remind that we live in a highly constrained environment with small footprint (few hundreds of bytes in RAM for routing is not unusual). We could not afford to use an existing adapted protocol that would meet our requirements if it requires lots of extra memory for features that are not needed in LLNs. Any additional memory has a cost, which matters a lot to LLNs. Proposal Now, let's try to be constructive and address your concerns. 1) Lack of background, context, ... in the document. Emmanuel is quite right that background is missing in the document as well as a clear conclusion: "how have we chosen the protocols in the survey, why protocols X, Y, Z, ... have not been included in the survey, ...". I saw that Phil agreed to add some text to address this issue. Emmanuel, does that address your concern (to be confirmed once you see the text) ? Phil, could you please propose some text ? 2) Missing protocols: we had to draw the line somewhere. *LOTS* of protocols have been proposed over the last decade. We had many suggestions to also look at protocol X, Y and Z. The decision was (according to our charter) to limit our survey to existing IETF protocols (RFC or very mature ID): OSPF, OLSR, TBRPF, RIP, AODV, DYMO, DSR. The list is already fairly long. The charter mentions DTN. The WG decided not to include DTN and this needs to be documented. Phil, could you please add some text ? Note that this does not mean that we may not borrow mechanism(s) from existing protocols by the way if we get re-chartered. 3) Is the goal to exclude existing routing protocols as potential candidates ? The answer is "no" but Thomas is right, this is currently not well explained in the document. The objective is to agree that none of the existing protocols meet the requirement but the solution might either be to develop a new one or extend an existing routing protocol (once we get re-chartered). Thomas, would that address your concern ? 4) Evaluation metric should be in a separate document: the approached adopted by the WG was to derive metrics from the requirements documents so as to perform the protocol survey. Once we will start protocol design, we will go back to the requirement documents since this is *the* objective of Requirements IDs. 5) Missing Metrics and Incorrect Metrics: Let us know if you have a list of metrics that are in your opinion "missing" and which metrics are "incorrect/inappropriate"? Or are we now in agreement based on 4) above ? Let's try to quickly reach a consensus and continue the excellent progress of the WG so far. Many Thanks for your help. JP. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** ------_=_NextPart_001_01C96072.908B9F7A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I'm not listed as an action below, as my main= point was=20 (and remains) the
danger that this document will be read as saying= more than=20 any, more limited,
consensus agreement, rather than that the document= is bad,=20 although I share
some concerns over whether the requirements used= are=20 "right". But I'm not
actually opposed to the narrow conclusion that no= existing=20 protocol surveyed
is ideal as is. It's important to make it clear= what is,=20 and is not, being said.
 
Given=20 all the real constraints on time etc., I think that the below is on the=20 right
track=20 to improve the document. That leaves point 5 in the final list, which= =20 ties
in=20 with point 2 in the requirements list. I think the key issues are= overall=20 cost vs.
"signalling" cost (it's the former that really= matters) and=20 latency. (Crudely, I can see
at=20 least three latency regimes - now, waiting for a route= discovery=20 process, a long
term=20 process such as various opportunistic store and forward= approaches. Note=20 that
longer=20 delays that may be necessitated by cutting down signalling storage=20 have
a=20 potentially increased data queuing cost, back to the first point.) And= finally=20 (for
this=20 email) regarding various real solutions that put the onus on gateways= to do=20 critical
work,=20 have more storage and be more immediate and so on. The possible=20 congestion
and=20 vulnerability issues of such key points may also be=20 important.
 
Note=20 that I'm not saying these points need to be addressed in detail here. It's= =20 more
about=20 putting down markers for the next stage, when these will=20 matter.
 
(I'm=20 not around much longer before the first full week in January=20 incidentally.)

--=
Christopher=20 Dearlove
Technology Leader, Communications Group
Networks, Security= and=20 Information Systems Department
BAE Systems Advanced Technology= Centre
West=20 Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245=20 242194  Fax: +44 1245 242124

BAE Systems (Operations)=20 Limited
Registered Office: Warwick House, PO Box 87,
Farnborough= Aerospace=20 Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England &= Wales=20 No: 1996687

 

From: JP Vasseur= [mailto:jvasseur@cisco.com]=20
Sent: 17 December 2008 17:05
To: Thomas Heide Clausen;= =20 Emmanuel Baccelli; Dearlove, Christopher (UK)
Cc: Philip Levis;=20 Arsalan Tavakoli; Stephen Dawson-Haggerty; roll@ietf.org; David E.=20 Culler
Subject: Proposal so as to reach a consensus on **=20 draft-ietf-roll-protocols-survey-02 **

*** WARNING ***

This mail has originated=20 outside your organization,
either from an external partner or the= =20 Global Internet.
Keep this in mind if you answer this message.=20
Hi,

First of all, thanks for all the comments; even late comments are very= much=20 welcome to improve the quality of the document. I'm sure that there is only= a=20 communication issue, and we all want to have a constructive approach so as= to=20 quickly reach a consensus.

I would just want to stress a few facts before making a= proposal:

1) We have limited time: non-IP and proprietary=20 protocols/architectures/solutions are being deployed today and= the industry=20 is asking for an IP-based routing protocol for LLN: we do need to do the= right=20 thing but we can't afford to argue for ever on issues that will not= change=20 the overall conclusion,
2) All the requirements documents have been written by authors with a= =20 real-world experience,
4) Designing a protocol that will fulfill those requirements is= feasible=20 (since some of them do exist today). See the "requirements" section= below.

So far I think that we are on the same page.

Our charter

First, spell out a set of requirements for a few limited applications= =20 (almost complete).
Second, answer to this explicitly narrow question: "Can we use an=20 *existing* IP protocols for LLNs ?". The= protocol=20 survey aims at answering this question. Not whether it should be a new= protocol,=20 an extension to an existing protocol, ... 
Other WG items are not relevant to this discussion.

Requirements

As you know, we are not currently chartered to work on protocols. We= first=20 had to express our requirements and see whether an existing protocol would= meet=20 these requirements. One cannot ask us to demonstrate that we can design= such a=20 protocol without being chartered to do so. That being said, considering the= =20 number of existing and deployed protocols in the field designed by some of= the=20 people who wrote the requirements, we can have a good level of confidence= that=20 such objective is achievable. For the record, I've been working myself on= such=20 protocols for some time.

Just two important comments with regards to "requirements".

1- Requirements are "guidelines". When time will come to work on= protocol=20 (if re-chartered), anybody will be more than welcome to propose a protocol= =20 (protocol extensions or new protocol). We will have to make compromise= indeed. I=20 would like to remind that we do not have to support all the MUST in a= single=20 instantiation of the protocol. There are ways to design protocols with= =20 options (there are many protocols that have this property).
2- I would also like to remind that we live in a highly constrained=20 environment with small footprint (few hundreds of bytes in RAM for routing= is=20 not unusual). We could not afford to use an existing adapted protocol that= would=20 meet our requirements if it requires lots of extra memory for features that= are=20 not needed in LLNs. Any additional memory has a cost, which matters a lot= to=20 LLNs.

Proposal

Now, let's try to be constructive and address your concerns.

1) Lack of background, context, ... in the document. Emmanuel= is=20 quite right that background is missing in the document as well as a clear=20 conclusion: "how have we chosen the protocols in the survey, why protocols= X, Y,=20 Z, ... have not been included in the survey, ...". I saw that Phil agreed= to add=20 some text to address this issue.
Emmanuel, does that address your concern (to be confirmed once you= see=20 the text) ?
Phil, could you please propose some text ?

2) Missing protocols: we had to draw the line somewhere. *LOTS*= of=20 protocols have been proposed over the last decade. We had many suggestions= to=20 also look at protocol X, Y and Z. The decision was (according to our= charter) to=20 limit our survey to existing IETF protocols (RFC or very mature ID):=  OSPF,=20 OLSR, TBRPF, RIP, AODV, DYMO, DSR. The list is already fairly long. The= charter=20 mentions DTN. The WG decided not to include DTN and this needs to be=20 documented.
Phil, could you please add some text ? Note that this does not= mean=20 that we may not borrow mechanism(s) from existing protocols by the way if= we get=20 re-chartered.

3) Is the goal to exclude existing routing protocols as potential=20 candidates ? The answer is "no" but Thomas is right, this is= currently=20 not well explained in the document. The objective is to agree that none of= the=20 existing protocols meet the requirement but the solution might= either be=20 to develop a new one or extend an existing routing protocol (once we get=20 re-chartered).
Thomas, would that address your concern ?

4) Evaluation metric should be in a separate document: the=20 approached adopted by the WG was to derive metrics from the requirements=20 documents so as to perform the protocol survey. Once we will start protocol design, we= will=20 go back to the requirement documents since this is *the* objective of=20 Requirements IDs.

5) Missing Metrics and Incorrect Metrics: Let us know= if you=20 have a list of metrics that are in your opinion "missing" and which metrics= are=20 "incorrect/inappropriate"? Or are we now in agreement based on 4) above=20 ?

Let's try to quickly reach a consensus and continue the excellent= progress=20 of the WG so far.

Many Thanks for your help.

JP.



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

------_=_NextPart_001_01C96072.908B9F7A-- --===============1160982360== 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 --===============1160982360==-- From roll-bounces@ietf.org Wed Dec 17 10:28:29 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE8023A6B1F; Wed, 17 Dec 2008 10:28:29 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BEDD3A6B1F for ; Wed, 17 Dec 2008 10:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.56 X-Spam-Level: X-Spam-Status: No, score=-10.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwwetCJRiiCV for ; Wed, 17 Dec 2008 10:28:26 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 4F0FB3A689F for ; Wed, 17 Dec 2008 10:28:25 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,238,1228089600"; d="scan'208,217";a="28930097" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 17 Dec 2008 18:28:11 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBHISBhZ009644; Wed, 17 Dec 2008 19:28:11 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBHISBam017868; Wed, 17 Dec 2008 18:28:11 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Dec 2008 19:28:11 +0100 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Dec 2008 19:28:10 +0100 Message-Id: <5EA61F2A-C9B5-421B-8DA8-E202430C1221@cisco.com> From: JP Vasseur To: "Dearlove, Christopher (UK)" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 17 Dec 2008 19:28:09 +0100 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> <3CEA849E-22CD-4DF1-A56B-E1C38572AA77@cisco.com> <6A3B39C4-8126-47D0-B29A-752191F4F487@cs.stanford.edu> <5467B083-1300-4723-9B5D-F45D6AED701B@thomasclausen.org> <260E044E-1C74-4C4D-9BF4-0A79E1A39177@cisco.com> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 17 Dec 2008 18:28:10.0362 (UTC) FILETIME=[36CD15A0:01C96075] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=24263; t=1229538491; x=1230402491; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Proposal=20so=20as=20to=20reac h=20a=20consensus=20on=20**=20draft-ietf-roll-protocols-surv ey-02=20** |Sender:=20; bh=e3iqflk1k0njluJynThTnI02nmIijzFDD+59iZJiAwM=; b=Q1xknxO8bMAcqOVZNFTcVgixVnxVDzLqjJ8pVgXAKXZPqQbNgGrvKe2Mtr 9MvITi3GhBh/OpKKxgtQ9H/pk9GWVAulkFQPm5iU2QeqJHQJnd+QXR1XcxbY 6qGp0BkXI0; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Emmanuel Baccelli , roll@ietf.org, Arsalan Tavakoli , "David E. Culler" Subject: Re: [Roll] Proposal so as to reach a consensus on ** draft-ietf-roll-protocols-survey-02 ** X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============1438042135==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1438042135== Content-Type: multipart/alternative; boundary=Apple-Mail-61--24297479 --Apple-Mail-61--24297479 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Christopher, On Dec 17, 2008, at 7:09 PM, Dearlove, Christopher (UK) wrote: > I'm not listed as an action below, as my main point was (and > remains) the > danger that this document will be read as saying more than any, more > limited, > consensus agreement, rather than that the document is bad, although > I share > some concerns over whether the requirements used are "right". But > I'm not > actually opposed to the narrow conclusion that no existing protocol > surveyed > is ideal as is. It's important to make it clear what is, and is not, > being said. > > Given all the real constraints on time etc., I think that the below > is on the right > track to improve the document. That leaves point 5 in the final > list, which ties > in with point 2 in the requirements list. I think the key issues are > overall cost vs. > "signalling" cost (it's the former that really matters) and latency. > (Crudely, I can see > at least three latency regimes - now, waiting for a route discovery > process, a long > term process such as various opportunistic store and forward > approaches. Note that > longer delays that may be necessitated by cutting down signalling > storage have > a potentially increased data queuing cost, back to the first point.) > And finally (for > this email) regarding various real solutions that put the onus on > gateways to do critical > work, have more storage and be more immediate and so on. The > possible congestion > and vulnerability issues of such key points may also be important. > > Note that I'm not saying these points need to be addressed in detail > here. It's more > about putting down markers for the next stage, when these will matter. > Thanks for your feed-back and input. Is it fair to say that you no longer have any "blocking" issue but you want to make sure that we revisit your points when we will start the protocol work ? Thanks. JP. > > (I'm not around much longer before the first full week in January > incidentally.) > -- > Christopher Dearlove > Technology Leader, Communications Group > Networks, Security and Information Systems Department > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 Fax: +44 1245 242124 > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, > Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > > From: JP Vasseur [mailto:jvasseur@cisco.com] > Sent: 17 December 2008 17:05 > To: Thomas Heide Clausen; Emmanuel Baccelli; Dearlove, Christopher > (UK) > Cc: Philip Levis; Arsalan Tavakoli; Stephen Dawson-Haggerty; roll@ietf.org > ; David E. Culler > Subject: Proposal so as to reach a consensus on ** draft-ietf-roll- > protocols-survey-02 ** > > *** WARNING *** > > This mail has originated outside your organization, > either from an external partner or the Global Internet. > Keep this in mind if you answer this message. > Hi, > > First of all, thanks for all the comments; even late comments are > very much welcome to improve the quality of the document. I'm sure > that there is only a communication issue, and we all want to have a > constructive approach so as to quickly reach a consensus. > > I would just want to stress a few facts before making a proposal: > > 1) We have limited time: non-IP and proprietary protocols/ > architectures/solutions are being deployed today and the industry is > asking for an IP-based routing protocol for LLN: we do need to do > the right thing but we can't afford to argue for ever on issues that > will not change the overall conclusion, > 2) All the requirements documents have been written by authors with > a real-world experience, > 4) Designing a protocol that will fulfill those requirements is > feasible (since some of them do exist today). See the "requirements" > section below. > > So far I think that we are on the same page. > > Our charter > > First, spell out a set of requirements for a few limited > applications (almost complete). > Second, answer to this explicitly narrow question: "Can we use an > *existing* IP protocols for LLNs ?". The protocol survey aims at > answering this question. Not whether it should be a new protocol, an > extension to an existing protocol, ... > Other WG items are not relevant to this discussion. > > Requirements > > As you know, we are not currently chartered to work on protocols. We > first had to express our requirements and see whether an existing > protocol would meet these requirements. One cannot ask us to > demonstrate that we can design such a protocol without being > chartered to do so. That being said, considering the number of > existing and deployed protocols in the field designed by some of the > people who wrote the requirements, we can have a good level of > confidence that such objective is achievable. For the record, I've > been working myself on such protocols for some time. > > Just two important comments with regards to "requirements". > > 1- Requirements are "guidelines". When time will come to work on > protocol (if re-chartered), anybody will be more than welcome to > propose a protocol (protocol extensions or new protocol). We will > have to make compromise indeed. I would like to remind that we do > not have to support all the MUST in a single instantiation of the > protocol. There are ways to design protocols with options (there are > many protocols that have this property). > 2- I would also like to remind that we live in a highly constrained > environment with small footprint (few hundreds of bytes in RAM for > routing is not unusual). We could not afford to use an existing > adapted protocol that would meet our requirements if it requires > lots of extra memory for features that are not needed in LLNs. Any > additional memory has a cost, which matters a lot to LLNs. > > Proposal > > Now, let's try to be constructive and address your concerns. > > 1) Lack of background, context, ... in the document. Emmanuel is > quite right that background is missing in the document as well as a > clear conclusion: "how have we chosen the protocols in the survey, > why protocols X, Y, Z, ... have not been included in the > survey, ...". I saw that Phil agreed to add some text to address > this issue. > Emmanuel, does that address your concern (to be confirmed once you > see the text) ? > Phil, could you please propose some text ? > > 2) Missing protocols: we had to draw the line somewhere. *LOTS* of > protocols have been proposed over the last decade. We had many > suggestions to also look at protocol X, Y and Z. The decision was > (according to our charter) to limit our survey to existing IETF > protocols (RFC or very mature ID): OSPF, OLSR, TBRPF, RIP, AODV, > DYMO, DSR. The list is already fairly long. The charter mentions > DTN. The WG decided not to include DTN and this needs to be > documented. > Phil, could you please add some text ? Note that this does not mean > that we may not borrow mechanism(s) from existing protocols by the > way if we get re-chartered. > > 3) Is the goal to exclude existing routing protocols as potential > candidates ? The answer is "no" but Thomas is right, this is > currently not well explained in the document. The objective is to > agree that none of the existing protocols meet the requirement but > the solution might either be to develop a new one or extend an > existing routing protocol (once we get re-chartered). > Thomas, would that address your concern ? > > 4) Evaluation metric should be in a separate document: the > approached adopted by the WG was to derive metrics from the > requirements documents so as to perform the protocol survey. Once we > will start protocol design, we will go back to the requirement > documents since this is *the* objective of Requirements IDs. > > 5) Missing Metrics and Incorrect Metrics: Let us know if you have a > list of metrics that are in your opinion "missing" and which metrics > are "incorrect/inappropriate"? Or are we now in agreement based on > 4) above ? > > Let's try to quickly reach a consensus and continue the excellent > progress of the WG so far. > > Many Thanks for your help. > > JP. > > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-61--24297479 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Christopher,

On Dec 17, 2008, at 7:09 PM, Dearlove, = Christopher (UK) wrote:

I'm not listed as an action below, as my = main point was (and remains) the
danger that this document will be read as = saying more than any, more limited,
consensus agreement, rather than that the = document is bad, although I share
some concerns over whether the requirements = used are "right". But I'm not
actually opposed to the narrow conclusion = that no existing protocol surveyed
is ideal as is. It's important to make it = clear what is, and is not, being said.
 
=
Given all the real constraints on time = etc., I think that the below is on the right
=
track to improve the document. That leaves = point 5 in the final list, which ties
=
in with point 2 in the requirements = list. I think the key issues are overall cost vs.
"signalling" cost (it's the former that really matters) and latency. = (Crudely, I can see
at least three latency regimes - = now, waiting for a route discovery process, a long
=
term process such as various opportunistic store and forward = approaches. Note that
longer delays that may be necessitated by cutting down = signalling storage have
a potentially increased data queuing cost, back to the first = point.) And finally (for
this email) regarding various real solutions that put = the onus on gateways to do critical
work, have more storage and be more immediate and so on. The possible = congestion
and vulnerability issues of such = key points may also be important.
 
Note that I'm not saying these points need to be addressed in = detail here. It's more
about putting down markers for the next stage, when these = will matter.


= Thanks for your feed-back and input. Is it fair to say that you no = longer have any "blocking" issue but you
want to make sure = that we revisit your points when we will start the protocol work = ?

Thanks.

JP.

<= blockquote type=3D"cite">
 
(I'm not around much longer before the first full week in = January incidentally.)

-- =
Christopher Dearlove
Technology Leader, Communications = Group
Networks, Security and Information Systems Department
BAE = Systems Advanced Technology Centre
West Hanningfield Road, Great = Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 = 1245 242124

BAE Systems (Operations) Limited
Registered = Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales = No: 1996687

 

=
From: JP = Vasseur [mailto:jvasseur@cisco.com] =
Sent: 17 December 2008 17:05
To: Thomas Heide = Clausen; Emmanuel Baccelli; Dearlove, Christopher (UK)
Cc: = Philip Levis; Arsalan Tavakoli; Stephen Dawson-Haggerty; roll@ietf.org; David E. = Culler
Subject: Proposal so as to reach a consensus on ** = draft-ietf-roll-protocols-survey-02 **

=
*** WARNING = ***

This mail has originated outside your = organization,
either from an external partner or the Global = Internet.
Keep this in mind if you answer this message. =
Hi,

First of all, = thanks for all the comments; even late comments are very much welcome to = improve the quality of the document. I'm sure that there is only a = communication issue, and we all want to have a constructive approach so = as to quickly reach a consensus.

I would just = want to stress a few facts before making a proposal:
=

1) We have limited time: non-IP and proprietary = protocols/architectures/solutions are being deployed today and = the industry is asking for an IP-based routing protocol for LLN: we = do need to do the right thing but we can't afford to argue for ever on = issues that will not change the overall conclusion,
2) = All the requirements documents have been written by authors with a = real-world experience,
4) Designing a protocol that will = fulfill those requirements is feasible (since some of them do exist = today). See the "requirements" section below.

=
So far I think that we are on the same page.

=
Our charter

First, spell = out a set of requirements for a few limited applications (almost = complete).
Second, answer to this explicitly narrow question: = "Can we use an *existing* IP protocols for LLNs ?". The = protocol survey aims at answering this question. Not whether it should = be a new protocol, an extension to an existing protocol, ... 
=
Other WG items are not relevant to this discussion.
=

Requirements
=

As you know, we are not currently = chartered to work on protocols. We first had to express our requirements = and see whether an existing protocol would meet these requirements. One = cannot ask us to demonstrate that we can design such a protocol without = being chartered to do so. That being said, considering the number of = existing and deployed protocols in the field designed by some of the = people who wrote the requirements, we can have a good level of = confidence that such objective is achievable. For the record, I've been = working myself on such protocols for some time.

=
Just two important comments with regards to "requirements".
=

1- Requirements are "guidelines". When time will = come to work on protocol (if re-chartered), anybody will be more than = welcome to propose a protocol (protocol extensions or new protocol). We = will have to make compromise indeed. I would like to remind that we do = not have to support all the MUST in a single instantiation of the = protocol. There are ways to design protocols with options (there are = many protocols that have this property).
2- I would also like = to remind that we live in a highly constrained environment with small = footprint (few hundreds of bytes in RAM for routing is not unusual). We = could not afford to use an existing adapted protocol that would meet our = requirements if it requires lots of extra memory for features that are = not needed in LLNs. Any additional memory has a cost, which matters a = lot to LLNs.

Proposal
=

Now, let's try to be constructive and address your = concerns.

1) Lack of background, context, = ... in the document. Emmanuel is quite right that background is = missing in the document as well as a clear conclusion: "how have we = chosen the protocols in the survey, why protocols X, Y, Z, ... have not = been included in the survey, ...". I saw that Phil agreed to add some = text to address this issue.
Emmanuel, does that address = your concern (to be confirmed once you see the text) ?
=
Phil, could you please propose some text ?
=

2) Missing protocols: we had to draw = the line somewhere. *LOTS* of protocols have been proposed over the last = decade. We had many suggestions to also look at protocol X, Y and Z. The = decision was (according to our charter) to limit our survey to existing = IETF protocols (RFC or very mature ID):  OSPF, OLSR, TBRPF, RIP, = AODV, DYMO, DSR. The list is already fairly long. The charter mentions = DTN. The WG decided not to include DTN and this needs to be = documented.
Phil, could you please add some text ? = Note that this does not mean that we may not borrow mechanism(s) from = existing protocols by the way if we get re-chartered.
=

3) Is the goal to exclude existing routing = protocols as potential candidates ? The answer is "no" but = Thomas is right, this is currently not well explained in the document. = The objective is to agree that none of the existing protocols meet the = requirement but the solution might either be to develop a new one = or extend an existing routing protocol (once we get re-chartered).
=
Thomas, would that address your concern ?
=

4) Evaluation metric should be in a separate = document: the approached adopted by the WG was to derive metrics = from the requirements documents so as to perform the protocol survey. = Once we will start protocol design, we will go back to the = requirement documents since this is *the* objective of Requirements = IDs.

5) Missing Metrics = and Incorrect Metrics: Let us know if you have a list = of metrics that are in your opinion "missing" and which metrics are = "incorrect/inappropriate"? Or are we now in agreement based on 4) above = ?

Let's try to quickly reach a = consensus and continue the excellent progress of the WG so far.
=

Many Thanks for your help.

=
JP.



=
********************************************************= ************
This email and any attachments are confidential to the = intended
recipient and may also be privileged. If you are not the = intended
recipient please delete it from your system and notify the = sender.
You should not copy it or use it for any purpose nor = disclose or
distribute its contents to any other person.
= ********************************************************************
=
=
_________________________________________= ______
Roll mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-61--24297479-- --===============1438042135== 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 --===============1438042135==-- From roll-bounces@ietf.org Wed Dec 17 12:05:39 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE64228C1E9; Wed, 17 Dec 2008 12:05:38 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA79A28C1E4 for ; Wed, 17 Dec 2008 12:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0N1fk4Z4C93D for ; Wed, 17 Dec 2008 12:05:35 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id BCCE028C1DC for ; Wed, 17 Dec 2008 12:05:35 -0800 (PST) Received: from [76.14.71.180] (helo=[192.168.2.101]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1LD2e7-0005iX-NN; Wed, 17 Dec 2008 12:05:28 -0800 Message-Id: <7F73D017-FBC6-4AB2-9359-78501D90825F@cs.stanford.edu> From: Philip Levis To: JP Vasseur In-Reply-To: <260E044E-1C74-4C4D-9BF4-0A79E1A39177@cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 17 Dec 2008 12:05:24 -0800 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> <3CEA849E-22CD-4DF1-A56B-E1C38572AA77@cisco.com> <6A3B39C4-8126-47D0-B29A-752191F4F487@cs.stanford.edu> <5467B083-1300-4723-9B5D-F45D6AED701B@thomasclausen.org> <260E044E-1C74-4C4D-9BF4-0A79E1A39177@cisco.com> X-Mailer: Apple Mail (2.929.2) X-Scan-Signature: b6c1f4b091abe5b5a29b37e1ccaa2d85 Cc: Arsalan Tavakoli , "David E. Culler" , "Christopher \(UK\) Dearlove" , Emmanuel Baccelli , roll@ietf.org Subject: Re: [Roll] Proposal so as to reach a consensus on ** draft-ietf-roll-protocols-survey-02 ** X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Dec 17, 2008, at 9:04 AM, JP Vasseur wrote: > > Now, let's try to be constructive and address your concerns. > > 1) Lack of background, context, ... in the document. Emmanuel is > quite right that background is missing in the document as well as a > clear conclusion: "how have we chosen the protocols in the survey, > why protocols X, Y, Z, ... have not been included in the > survey, ...". I saw that Phil agreed to add some text to address > this issue. > Emmanuel, does that address your concern (to be confirmed once you > see the text) ? > Phil, could you please propose some text ? The OSPF section will be renamed OSPF/IS-IS and I will add supporting text that notes the distinctions between the two and why their analysis is the same. > > 2) Missing protocols: we had to draw the line somewhere. *LOTS* of > protocols have been proposed over the last decade. We had many > suggestions to also look at protocol X, Y and Z. The decision was > (according to our charter) to limit our survey to existing IETF > protocols (RFC or very mature ID): OSPF, OLSR, TBRPF, RIP, AODV, > DYMO, DSR. The list is already fairly long. The charter mentions > DTN. The WG decided not to include DTN and this needs to be > documented. > Phil, could you please add some text ? Note that this does not mean > that we may not borrow mechanism(s) from existing protocols by the > way if we get re-chartered. The current text reads: "This document considers "existing routing protocols" to be protocols that are specified in RFCs or, in the cases of DYMO [I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very mature draft which will most likely become an RFC." I propose "This document considers "existing routing protocols" to be routing protocols that are specified in RFCs or, in the cases of DYMO [I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very mature draft which will most likely become an RFC. It does not examine the Network Mobility Basic Support Protocol (NEMO)[cite], DTN bundles[cite], or the DTN Licklider protocol[cite] because they are not routing protocols." > > 3) Is the goal to exclude existing routing protocols as potential > candidates ? The answer is "no" but Thomas is right, this is > currently not well explained in the document. The objective is to > agree that none of the existing protocols meet the requirement but > the solution might either be to develop a new one or extend an > existing routing protocol (once we get re-chartered). > Thomas, would that address your concern ? The current text reads: "As they were not designed with these requirements in mind, existing protocols may or may not work well in LLNs. The first step to reaching consensus on a routing protocol for LLNs is to decide which of these two is true. If an existing protocol can meet LLN requirements without any changes, then barring extenuating circumstances, it behooves us to use an existing standard. However, if no current protocol can meet LLN's requirements, then further work will be needed to define and standardize with a protocol that can. Whether or not such a protocol involves modifications to an existing protocol or a new protocol entirely is outside the scope of this document: this document simply seeks to answer the question: do LLNs require a new protocol specification document at all?" I'd appreciate advice on how to make this clearer. > > 4) Evaluation metric should be in a separate document: the > approached adopted by the WG was to derive metrics from the > requirements documents so as to perform the protocol survey. Once we > will start protocol design, we will go back to the requirement > documents since this is *the* objective of Requirements IDs. > > 5) Missing Metrics and Incorrect Metrics: Let us know if you have a > list of metrics that are in your opinion "missing" and which metrics > are "incorrect/inappropriate"? Or are we now in agreement based on > 4) above ? > Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Dec 17 12:06:53 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 614A528C1F7; Wed, 17 Dec 2008 12:06:53 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2518828C1E9 for ; Wed, 17 Dec 2008 12:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqKAUc8Ag0U2 for ; Wed, 17 Dec 2008 12:06:51 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 5232028C1E7 for ; Wed, 17 Dec 2008 12:06:51 -0800 (PST) Received: from [76.14.71.180] (helo=[192.168.2.101]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1LD2fL-0005k4-Tb; Wed, 17 Dec 2008 12:06:44 -0800 Message-Id: <3C687FD9-8ABF-43D6-9F8F-6536417159BE@cs.stanford.edu> From: Philip Levis To: Thomas Heide Clausen In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 17 Dec 2008 12:06:41 -0800 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> <61D43925-D96D-41A0-A73B-E87B586245E3@thomasclausen.org> <7892795E1A87F04CADFCCF41FADD00FC06ADE37A@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.929.2) X-Scan-Signature: d1b7ebe10773c68371983edd1a66f504 Cc: "Dearlove, Christopher \(UK\)" , roll@ietf.org, Emmanuel Baccelli Subject: Re: [Roll] WorkingGroup LastCall:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Thomas, (comments inline) > Hi Pascal, > > Long time no see -- hope all is well in the south? > > On Dec 9, 2008, at 6:32 PM, Pascal Thubert (pthubert) wrote: > >> Hi Thomas: >> >> Every evaluation picks criteria and applies them. This doc has been >> around for awhile with its own clear list of criteria, which take >> their source in the requirements drafts. Someone could propose >> another doc with another set of criteria that would make perfect >> sense for a different set of requirements. >> > > Right, I appreciate that any evaluation is the result of a choice of > criteria -- and that's fine as such. However the choice has to be > sensible such that the conclusions that can be drawn are useful. > > In this case, I feel that a somewhat common, but none the less > unfortunate, choice is made. I'll again emphasize the "control cost" > metric. As it would be, we should not really care for the specific > "control cost" but rather "the total cost of getting traffic from > the source to the destination. This includes the control cost that > incurs, of course, but not only: the cost of carrying data traffic > should be considered as well. If the data traffic to be delivered is > non-zero, the latter often is important -- which is one good reason > for a routing protocol to trade of "control costs" for attaining > "shorter/shortest paths" (according to whatever metric). I agree that "total cost" (control cost + data cost) is a better metric for some protocols; in particular, when considering throughput, the channel occupancy time of a protocol per bit delivered is a measure of its efficiency. But "control cost" does not address this case: rather, it addresses the common case in LLNs where there is a very very low data rate. In particular, there is a tradeoff between data reporting rate and lifetime: more packets use more battery. Furthermore, the data reporting interval may not be known a-priori (e.g., event-driven networks), so one cannot simply define a constant that matches the data rate. Otherwise you run into situations where there's a period of high data but the control interval is low so the topology cannot adapt quickly. In short, simply sending periodic beacons is not a suitable approach for LLNs. It's a non-starter for a ROLL protocol. That's why this criterion is here: it articulates that control rates cannot surpass data rates. Of course you'd like them to be *much* lower, but this criterion sets an upper bound. While you might say that it's too weak, there are many protocols that don't meet it! Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Dec 17 13:15:31 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C6FA3A691E; Wed, 17 Dec 2008 13:15:31 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 504173A691E for ; Wed, 17 Dec 2008 13:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLR4QbtdSnOK for ; Wed, 17 Dec 2008 13:15:29 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id D7DF93A6831 for ; Wed, 17 Dec 2008 13:15:28 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so44109yxg.49 for ; Wed, 17 Dec 2008 13:15:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=YAdS6wzMrbqzuqWfpjUqvhhXA5rck8P2dnjMJ6DWKNc=; b=GueEmYgSrgmvNj4wiQjNGrO/r4B4AsxgbS3U3He+9uDfKPZYdwCgfPyfF2tSbbOgsB Tug0oAjJ4g2MJrNIPf+JQxd1XxupUr+/mx/viO124VwnfwilqP02uZdJK3gc+iOS/sfm NA1oJxDp2iyZ9oeLePEK5znjQazyxOzNkdiu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=u31zlbw4FMQXSoj29lxltlf4bbtV+dXW39+Rkf73LT4qhaCd7HeHrVC3ne0pZKYKG/ 7KQiazk6JuRh8fcDRoNad9nvKvM701gzr9dLKELEu3OFuTVddPfUxBBXN/p1ZAv/NkMe 3uXn4e6YIN6G0f9gdZw5q2kdywnTJyCb4oYtc= Received: by 10.100.153.4 with SMTP id a4mr946690ane.101.1229548521263; Wed, 17 Dec 2008 13:15:21 -0800 (PST) Received: by 10.100.42.11 with HTTP; Wed, 17 Dec 2008 13:15:21 -0800 (PST) Message-ID: <44680fe70812171315y15473468k94b61b263d73f2ac@mail.gmail.com> Date: Wed, 17 Dec 2008 13:15:21 -0800 From: "Stephen Dawson-Haggerty" To: "Philip Levis" In-Reply-To: <3C687FD9-8ABF-43D6-9F8F-6536417159BE@cs.stanford.edu> MIME-Version: 1.0 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <61D43925-D96D-41A0-A73B-E87B586245E3@thomasclausen.org> <7892795E1A87F04CADFCCF41FADD00FC06ADE37A@xmb-ams-337.emea.cisco.com> <3C687FD9-8ABF-43D6-9F8F-6536417159BE@cs.stanford.edu> X-Google-Sender-Auth: 9cbe1cdc81c3f42e Cc: Emmanuel Baccelli , "Dearlove, Christopher \(UK\)" , roll@ietf.org, Thomas Heide Clausen Subject: Re: [Roll] WorkingGroup LastCall:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============1862013797==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1862013797== Content-Type: multipart/alternative; boundary="----=_Part_9734_30689481.1229548521256" ------=_Part_9734_30689481.1229548521256 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline (comments below) On Wed, Dec 17, 2008 at 12:06 PM, Philip Levis wrote: > Thomas, > > (comments inline) > > Hi Pascal, >> >> Long time no see -- hope all is well in the south? >> >> On Dec 9, 2008, at 6:32 PM, Pascal Thubert (pthubert) wrote: >> >> Hi Thomas: >>> >>> Every evaluation picks criteria and applies them. This doc has been >>> around for awhile with its own clear list of criteria, which take their >>> source in the requirements drafts. Someone could propose another doc with >>> another set of criteria that would make perfect sense for a different set of >>> requirements. >>> >>> >> Right, I appreciate that any evaluation is the result of a choice of >> criteria -- and that's fine as such. However the choice has to be sensible >> such that the conclusions that can be drawn are useful. >> >> In this case, I feel that a somewhat common, but none the less >> unfortunate, choice is made. I'll again emphasize the "control cost" metric. >> As it would be, we should not really care for the specific "control cost" >> but rather "the total cost of getting traffic from the source to the >> destination. This includes the control cost that incurs, of course, but not >> only: the cost of carrying data traffic should be considered as well. If the >> data traffic to be delivered is non-zero, the latter often is important -- >> which is one good reason for a routing protocol to trade of "control costs" >> for attaining "shorter/shortest paths" (according to whatever metric). >> > > I agree that "total cost" (control cost + data cost) is a better metric for > some protocols; in particular, when considering throughput, the channel > occupancy time of a protocol per bit delivered is a measure of its > efficiency. But "control cost" does not address this case: rather, it > addresses the common case in LLNs where there is a very very low data rate. > In particular, there is a tradeoff between data reporting rate and lifetime: > more packets use more battery. Furthermore, the data reporting interval may > not be known a-priori (e.g., event-driven networks), so one cannot simply > define a constant that matches the data rate. Otherwise you run into > situations where there's a period of high data but the control interval is > low so the topology cannot adapt quickly. > > In short, simply sending periodic beacons is not a suitable approach for > LLNs. It's a non-starter for a ROLL protocol. That's why this criterion is > here: it articulates that control rates cannot surpass data rates. Of course > you'd like them to be *much* lower, but this criterion sets an upper bound. > While you might say that it's too weak, there are many protocols that don't > meet it! Yes, I think it's worth emphasizing that although the metric is called "control cost," what that metric says is that the data rate must be bounded by the data rate (except in the edge case); so in effect, we're treating the data rate as an externally specified value, and then bounding the total rate. Now, bounding rates isn't exactly the same thing as bounding the costs; for instance, if a protocol aggressively traded off stretch for control traffic, you might pass this metric but still not be a very good protocol. Flooding every packet would be an example of this (I think this was noted on the list at some point). None of the protocols we examined do this; they all form routes which attempt to optimize an additive link metric. If they did do this, we would have to come up with a different metric. However, given "traditional" protocols forward packets by building forwarding tables at each router, this seems like a pretty good metric. Would adding a note about this metric's limitations be a good idea? > > > Phil > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > ------=_Part_9734_30689481.1229548521256 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline (comments below)

On Wed, Dec 17, 2008 at 12:06 PM, Philip Levis <pal@cs.stanford.edu> wrote:
Thomas,

(comments inline)


Hi Pascal,

Long time no see -- hope all is well in the south?

On Dec 9, 2008, at 6:32 PM, Pascal Thubert (pthubert) wrote:

Hi Thomas:

Every evaluation picks criteria and applies them. This doc has been around for awhile with its own clear list of criteria, which take their source in the requirements drafts. Someone could propose another doc with another set of criteria that would make perfect sense for a different set of requirements.


Right, I appreciate that any evaluation is the result of a choice of criteria -- and that's fine as such. However the choice has to be sensible such that the conclusions that can be drawn are useful.

In this case, I feel that a somewhat common, but none the less unfortunate, choice is made. I'll again emphasize the "control cost" metric. As it would be, we should not really care for the specific "control cost" but rather "the total cost of getting traffic from the source to the destination. This includes the control cost that incurs, of course, but not only: the cost of carrying data traffic should be considered as well. If the data traffic to be delivered is non-zero, the latter often is important -- which is one good reason for a routing protocol to trade of "control costs" for attaining "shorter/shortest paths" (according to whatever metric).

I agree that "total cost" (control cost + data cost) is a better metric for some protocols; in particular, when considering throughput, the channel occupancy time of a protocol per bit delivered is a measure of its efficiency. But "control cost" does not address this case: rather, it addresses the common case in LLNs where there is a very very low data rate. In particular, there is a tradeoff between data reporting rate and lifetime: more packets use more battery. Furthermore, the data reporting interval may not be known a-priori (e.g., event-driven networks), so one cannot simply define a constant that matches the data rate. Otherwise you run into situations where there's a period of high data but the control interval is low so the topology cannot adapt quickly.

In short, simply sending periodic beacons is not a suitable approach for LLNs. It's a non-starter for a ROLL protocol. That's why this criterion is here: it articulates that control rates cannot surpass data rates. Of course you'd like them to be *much* lower, but this criterion sets an upper bound. While you might say that it's too weak, there are many protocols that don't meet it!

Yes, I think it's worth emphasizing that although the metric is called "control cost," what that metric says is that the data rate must be bounded by the data rate (except in the edge case); so in effect, we're treating the data rate as an externally specified value, and then bounding the total rate.  Now, bounding rates isn't exactly the same thing as bounding the costs; for instance, if a protocol aggressively traded off stretch for control traffic, you might pass this metric but still not be a very good protocol.  Flooding every packet would be an example of this (I think this was noted on the list at some point).

None of the protocols we examined do this; they all form routes which attempt to optimize an additive link metric.  If they did do this, we would have to come up with a different metric.  However, given "traditional" protocols forward packets by building forwarding tables at each router, this seems like a pretty good metric. 

Would adding a note about this metric's limitations be a good idea?
 


Phil

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

------=_Part_9734_30689481.1229548521256-- --===============1862013797== 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 --===============1862013797==-- From roll-bounces@ietf.org Wed Dec 17 13:41:55 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64B5E3A6AFC; Wed, 17 Dec 2008 13:41:55 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85A5E3A6AFC for ; Wed, 17 Dec 2008 13:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8BpPjzATDfn for ; Wed, 17 Dec 2008 13:41:50 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 44C713A67D2 for ; Wed, 17 Dec 2008 13:41:49 -0800 (PST) Received: by bwz14 with SMTP id 14so445600bwz.13 for ; Wed, 17 Dec 2008 13:41:40 -0800 (PST) Received: by 10.103.220.18 with SMTP id x18mr472597muq.38.1229550100290; Wed, 17 Dec 2008 13:41:40 -0800 (PST) Received: by 10.102.220.8 with HTTP; Wed, 17 Dec 2008 13:41:40 -0800 (PST) Message-ID: <25c114b90812171341i12b0bc5fy91049fbfb57d21ac@mail.gmail.com> Date: Wed, 17 Dec 2008 22:41:40 +0100 From: "Ulrich Herberg" To: "Philip Levis" In-Reply-To: <3C687FD9-8ABF-43D6-9F8F-6536417159BE@cs.stanford.edu> MIME-Version: 1.0 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <61D43925-D96D-41A0-A73B-E87B586245E3@thomasclausen.org> <7892795E1A87F04CADFCCF41FADD00FC06ADE37A@xmb-ams-337.emea.cisco.com> <3C687FD9-8ABF-43D6-9F8F-6536417159BE@cs.stanford.edu> X-Google-Sender-Auth: 5744f72cf074679e Cc: Emmanuel Baccelli , "Dearlove, Christopher \(UK\)" , roll@ietf.org, Thomas Heide Clausen Subject: Re: [Roll] WorkingGroup LastCall:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============2006017741==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============2006017741== Content-Type: multipart/alternative; boundary="----=_Part_15802_32442952.1229550100289" ------=_Part_15802_32442952.1229550100289 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Comments inline... On Wed, Dec 17, 2008 at 9:06 PM, Philip Levis wrote: > Thomas, > > >> On Dec 9, 2008, at 6:32 PM, Pascal Thubert (pthubert) wrote: >> >> Hi Thomas: >>> >>> Every evaluation picks criteria and applies them. This doc has been >>> around for awhile with its own clear list of criteria, which take their >>> source in the requirements drafts. Someone could propose another doc with >>> another set of criteria that would make perfect sense for a different set of >>> requirements. >>> >>> >> Right, I appreciate that any evaluation is the result of a choice of >> criteria -- and that's fine as such. However the choice has to be sensible >> such that the conclusions that can be drawn are useful. >> >> In this case, I feel that a somewhat common, but none the less >> unfortunate, choice is made. I'll again emphasize the "control cost" metric. >> As it would be, we should not really care for the specific "control cost" >> but rather "the total cost of getting traffic from the source to the >> destination. This includes the control cost that incurs, of course, but not >> only: the cost of carrying data traffic should be considered as well. If the >> data traffic to be delivered is non-zero, the latter often is important -- >> which is one good reason for a routing protocol to trade of "control costs" >> for attaining "shorter/shortest paths" (according to whatever metric). >> > > I agree that "total cost" (control cost + data cost) is a better metric for > some protocols; in particular, when considering throughput, the channel > occupancy time of a protocol per bit delivered is a measure of its > efficiency. But "control cost" does not address this case: rather, it > addresses the common case in LLNs where there is a very very low data rate. > In particular, there is a tradeoff between data reporting rate and lifetime: > more packets use more battery. Furthermore, the data reporting interval may > not be known a-priori (e.g., event-driven networks), so one cannot simply > define a constant that matches the data rate. Otherwise you run into > situations where there's a period of high data but the control interval is > low so the topology cannot adapt quickly. I don't understand your argument. Why is "control cost" a better criterion than "total cost"? In terms of energy consumption, even a very low control cost can inflict very high data traffic cost (e.g. the broadcast example). It is the total amount of sent frames that is proportional to the energy consumption, not just the control traffic. You say "more packets use more battery". Correct, but "more packets" include more data packets as well as more control packets. > > > In short, simply sending periodic beacons is not a suitable approach for > LLNs. It's a non-starter for a ROLL protocol. That's why this criterion is > here: it articulates that control rates cannot surpass data rates. Of course > you'd like them to be *much* lower, but this criterion sets an upper bound. > While you might say that it's too weak, there are many protocols that don't > meet it! I think you have to be careful when defining the criteria of a routing protocol for LLNs not to have a particular routing solution in mind. Part of the goal of this draft is to set objective criteria for selecting routing protocols for LLNs. It is dangerous to dismiss any proactive routing protocol in advance by saying "sending periodic beacons is not a suitable approach for LLNs", and setting the selection criteria accordingly. Regards, Ulrich ------=_Part_15802_32442952.1229550100289 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Comments inline...

On Wed, Dec 17, 2008 at 9:06 PM, Philip Levis <pal@cs.stanford.edu> wrote:
Thomas,


On Dec 9, 2008, at 6:32 PM, Pascal Thubert (pthubert) wrote:

Hi Thomas:

Every evaluation picks criteria and applies them. This doc has been around for awhile with its own clear list of criteria, which take their source in the requirements drafts. Someone could propose another doc with another set of criteria that would make perfect sense for a different set of requirements.


Right, I appreciate that any evaluation is the result of a choice of criteria -- and that's fine as such. However the choice has to be sensible such that the conclusions that can be drawn are useful.

In this case, I feel that a somewhat common, but none the less unfortunate, choice is made. I'll again emphasize the "control cost" metric. As it would be, we should not really care for the specific "control cost" but rather "the total cost of getting traffic from the source to the destination. This includes the control cost that incurs, of course, but not only: the cost of carrying data traffic should be considered as well. If the data traffic to be delivered is non-zero, the latter often is important -- which is one good reason for a routing protocol to trade of "control costs" for attaining "shorter/shortest paths" (according to whatever metric).

I agree that "total cost" (control cost + data cost) is a better metric for some protocols; in particular, when considering throughput, the channel occupancy time of a protocol per bit delivered is a measure of its efficiency. But "control cost" does not address this case: rather, it addresses the common case in LLNs where there is a very very low data rate. In particular, there is a tradeoff between data reporting rate and lifetime: more packets use more battery. Furthermore, the data reporting interval may not be known a-priori (e.g., event-driven networks), so one cannot simply define a constant that matches the data rate. Otherwise you run into situations where there's a period of high data but the control interval is low so the topology cannot adapt quickly.


I don't understand your argument. Why is "control cost" a better criterion than "total cost"? In terms of energy consumption, even a very low control cost can inflict very high data traffic cost (e.g. the broadcast example). It is the total amount of sent frames that is proportional to the energy consumption, not just the control traffic. You say "more packets use more battery". Correct, but "more packets" include more data packets as well as more control packets.


In short, simply sending periodic beacons is not a suitable approach for LLNs. It's a non-starter for a ROLL protocol. That's why this criterion is here: it articulates that control rates cannot surpass data rates. Of course you'd like them to be *much* lower, but this criterion sets an upper bound. While you might say that it's too weak, there are many protocols that don't meet it!

I think you have to be careful when defining the criteria of a routing protocol for LLNs not to have a particular routing solution in mind. Part of the goal of this draft is to set objective criteria for selecting routing protocols for LLNs. It is dangerous to dismiss any proactive routing protocol in advance by saying "sending periodic beacons is not a suitable approach for LLNs", and setting the selection criteria accordingly.

Regards,
Ulrich

------=_Part_15802_32442952.1229550100289-- --===============2006017741== 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 --===============2006017741==-- From roll-bounces@ietf.org Wed Dec 17 14:24:26 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01EC128C1EC; Wed, 17 Dec 2008 14:24:26 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3352E28C1EC for ; Wed, 17 Dec 2008 14:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIarId-rMyXo for ; Wed, 17 Dec 2008 14:24:23 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id B12383A67BD for ; Wed, 17 Dec 2008 14:24:22 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so55882ywj.49 for ; Wed, 17 Dec 2008 14:24:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=ZlwMx5NbJfM9EhMuPhhrXFJaXrz96qqSB2n/ooyJgYU=; b=njNMo81KR4xCiPboA4VcENjEazjXCbkr+ziev90vHy/pgEpXu422Us5FV+Vz+bKWg3 dJ6mmjj/bKeZpdtuQtcozrqJ2HdQ/Dff66VuNv7GYmVqMR86+pLrsXjl1toV8DDsjcWM esHypoxuIEEXiHEtrbYIC9H+OIR6O5uhhzNGc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=tWeeCkaDSr5p2btqUb6PhTY9K86QXbK91AvuJrqU9cSofzOsHj53Gl+XsouSb3CjpF CJmZYLEo54eBOuVGckEwbd0qBK32uTl42bG+c4jHO42GkKevMqzZPFF5kgXmPOHjOflY OyluIevPziNGpOC3z6vvqYzN4wcw36tM14pTQ= Received: by 10.100.142.15 with SMTP id p15mr1005960and.33.1229552653572; Wed, 17 Dec 2008 14:24:13 -0800 (PST) Received: by 10.100.42.11 with HTTP; Wed, 17 Dec 2008 14:24:12 -0800 (PST) Message-ID: <44680fe70812171424o4c0f5dc3m8b6e40e460b9b342@mail.gmail.com> Date: Wed, 17 Dec 2008 14:24:12 -0800 From: "Stephen Dawson-Haggerty" To: "Ulrich Herberg" In-Reply-To: <25c114b90812171341i12b0bc5fy91049fbfb57d21ac@mail.gmail.com> MIME-Version: 1.0 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <61D43925-D96D-41A0-A73B-E87B586245E3@thomasclausen.org> <7892795E1A87F04CADFCCF41FADD00FC06ADE37A@xmb-ams-337.emea.cisco.com> <3C687FD9-8ABF-43D6-9F8F-6536417159BE@cs.stanford.edu> <25c114b90812171341i12b0bc5fy91049fbfb57d21ac@mail.gmail.com> X-Google-Sender-Auth: 5be8d09ae2f8f52e Cc: "Dearlove, Christopher \(UK\)" , Emmanuel Baccelli , roll@ietf.org, Thomas Heide Clausen Subject: Re: [Roll] WorkingGroup LastCall:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============1717944618==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1717944618== Content-Type: multipart/alternative; boundary="----=_Part_10838_9274383.1229552653068" ------=_Part_10838_9274383.1229552653068 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline > Every evaluation picks criteria and applies them. This doc has been around >>>> for awhile with its own clear list of criteria, which take their source in >>>> the requirements drafts. Someone could propose another doc with another set >>>> of criteria that would make perfect sense for a different set of >>>> requirements. >>>> >>>> >>> Right, I appreciate that any evaluation is the result of a choice of >>> criteria -- and that's fine as such. However the choice has to be sensible >>> such that the conclusions that can be drawn are useful. >>> >>> In this case, I feel that a somewhat common, but none the less >>> unfortunate, choice is made. I'll again emphasize the "control cost" metric. >>> As it would be, we should not really care for the specific "control cost" >>> but rather "the total cost of getting traffic from the source to the >>> destination. This includes the control cost that incurs, of course, but not >>> only: the cost of carrying data traffic should be considered as well. If the >>> data traffic to be delivered is non-zero, the latter often is important -- >>> which is one good reason for a routing protocol to trade of "control costs" >>> for attaining "shorter/shortest paths" (according to whatever metric). >>> >> >> I agree that "total cost" (control cost + data cost) is a better metric >> for some protocols; in particular, when considering throughput, the channel >> occupancy time of a protocol per bit delivered is a measure of its >> efficiency. But "control cost" does not address this case: rather, it >> addresses the common case in LLNs where there is a very very low data rate. >> In particular, there is a tradeoff between data reporting rate and lifetime: >> more packets use more battery. Furthermore, the data reporting interval may >> not be known a-priori (e.g., event-driven networks), so one cannot simply >> define a constant that matches the data rate. Otherwise you run into >> situations where there's a period of high data but the control interval is >> low so the topology cannot adapt quickly. >> > > > I don't understand your argument. Why is "control cost" a better criterion > than "total cost"? In terms of energy consumption, even a very low control > cost can inflict very high data traffic cost (e.g. the broadcast example). > It is the total amount of sent frames that is proportional to the energy > consumption, not just the control traffic. You say "more packets use more > battery". Correct, but "more packets" include more data packets as well as > more control packets. > We're really making a statement about the relationship between control and data traffic. In some sense this does put a bound on the total cost; it's just parameterized by the data cost. Our metric simply aims to make sure the protocol won't do anything crazy, regardless of what data rate you chose. This means, for instance, if you want a very low duty cycle network you can just send a small amount of data and not worry about the network creating a lot of traffic on its own. > > >> >> In short, simply sending periodic beacons is not a suitable approach for >> LLNs. It's a non-starter for a ROLL protocol. That's why this criterion is >> here: it articulates that control rates cannot surpass data rates. Of course >> you'd like them to be *much* lower, but this criterion sets an upper bound. >> While you might say that it's too weak, there are many protocols that don't >> meet it! > > > I think you have to be careful when defining the criteria of a routing > protocol for LLNs not to have a particular routing solution in mind. Part of > the goal of this draft is to set objective criteria for selecting routing > protocols for LLNs. It is dangerous to dismiss any proactive routing > protocol in advance by saying "sending periodic beacons is not a suitable > approach for LLNs", and setting the selection criteria accordingly. > Agreed. After the interm meeting we altered the draft based specifically on this concern, and I do not believe that the document precludes proactive routing protocols so long as they are tunable to prevent a lot of constant control traffic in the absence of data. Best, Steve ------=_Part_10838_9274383.1229552653068 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Every evaluation picks criteria and applies them. This doc has been around for awhile with its own clear list of criteria, which take their source in the requirements drafts. Someone could propose another doc with another set of criteria that would make perfect sense for a different set of requirements.


Right, I appreciate that any evaluation is the result of a choice of criteria -- and that's fine as such. However the choice has to be sensible such that the conclusions that can be drawn are useful.

In this case, I feel that a somewhat common, but none the less unfortunate, choice is made. I'll again emphasize the "control cost" metric. As it would be, we should not really care for the specific "control cost" but rather "the total cost of getting traffic from the source to the destination. This includes the control cost that incurs, of course, but not only: the cost of carrying data traffic should be considered as well. If the data traffic to be delivered is non-zero, the latter often is important -- which is one good reason for a routing protocol to trade of "control costs" for attaining "shorter/shortest paths" (according to whatever metric).

I agree that "total cost" (control cost + data cost) is a better metric for some protocols; in particular, when considering throughput, the channel occupancy time of a protocol per bit delivered is a measure of its efficiency. But "control cost" does not address this case: rather, it addresses the common case in LLNs where there is a very very low data rate. In particular, there is a tradeoff between data reporting rate and lifetime: more packets use more battery. Furthermore, the data reporting interval may not be known a-priori (e.g., event-driven networks), so one cannot simply define a constant that matches the data rate. Otherwise you run into situations where there's a period of high data but the control interval is low so the topology cannot adapt quickly.


I don't understand your argument. Why is "control cost" a better criterion than "total cost"? In terms of energy consumption, even a very low control cost can inflict very high data traffic cost (e.g. the broadcast example). It is the total amount of sent frames that is proportional to the energy consumption, not just the control traffic. You say "more packets use more battery". Correct, but "more packets" include more data packets as well as more control packets.

We're really making a statement about the relationship between control and data traffic.  In some sense this does put a bound on the total cost; it's just parameterized by the data cost.  Our metric simply aims to make sure the protocol won't do anything crazy, regardless of what data rate you chose.  This means, for instance, if you want a very low duty cycle network you can just send a small amount of data and not worry about the network creating a lot of traffic on its own.
 



In short, simply sending periodic beacons is not a suitable approach for LLNs. It's a non-starter for a ROLL protocol. That's why this criterion is here: it articulates that control rates cannot surpass data rates. Of course you'd like them to be *much* lower, but this criterion sets an upper bound. While you might say that it's too weak, there are many protocols that don't meet it!

I think you have to be careful when defining the criteria of a routing protocol for LLNs not to have a particular routing solution in mind. Part of the goal of this draft is to set objective criteria for selecting routing protocols for LLNs. It is dangerous to dismiss any proactive routing protocol in advance by saying "sending periodic beacons is not a suitable approach for LLNs", and setting the selection criteria accordingly.

Agreed.  After the interm meeting we altered the draft based specifically on this concern, and I do not believe that the document precludes proactive routing protocols so long as they are tunable to prevent a lot of constant control traffic in the absence of data.

Best,
Steve




------=_Part_10838_9274383.1229552653068-- --===============1717944618== 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 --===============1717944618==-- From roll-bounces@ietf.org Thu Dec 18 01:57:11 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5898128C12E; Thu, 18 Dec 2008 01:57:11 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6855C28C1B1 for ; Thu, 18 Dec 2008 01:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PU+niKRdmvoL for ; Thu, 18 Dec 2008 01:57:09 -0800 (PST) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 565D93A682A for ; Thu, 18 Dec 2008 01:57:09 -0800 (PST) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mBI9uwo1022273 for ; Thu, 18 Dec 2008 09:56:58 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mBI9uwba005299 for ; Thu, 18 Dec 2008 09:56:58 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Thu, 18 Dec 2008 09:56:57 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Thu, 18 Dec 2008 09:56:57 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 18 Dec 2008 09:56:53 -0000 Message-ID: In-Reply-To: <5EA61F2A-C9B5-421B-8DA8-E202430C1221@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Proposal so as to reach a consensus on ** draft-ietf-roll-protocols-survey-02 ** Thread-Index: AclgdT01AgZxFRWrQYGngtCwdIzi0AAgNW9Q References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> <3CEA849E-22CD-4DF1-A56B-E1C38572AA77@cisco.com> <6A3B39C4-8126-47D0-B29A-752191F4F487@cs.stanford.edu> <5467B083-1300-4723-9B5D-F45D6AED701B@thomasclausen.org> <260E044E-1C74-4C4D-9BF4-0A79E1A39177@cisco.com> <5EA61F2A-C9B5-421B-8DA8-E202430C1221@cisco.com> From: "Dearlove, Christopher (UK)" To: "JP Vasseur" X-OriginalArrivalTime: 18 Dec 2008 09:56:57.0323 (UTC) FILETIME=[F6A883B0:01C960F6] Cc: Emmanuel Baccelli , roll@ietf.org, Arsalan Tavakoli , "David E. Culler" Subject: Re: [Roll] Proposal so as to reach a consensus on ** draft-ietf-roll-protocols-survey-02 ** X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============0390375359==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============0390375359== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C960F6.F66F2F30" This is a multi-part message in MIME format. ------_=_NextPart_001_01C960F6.F66F2F30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Thanks for your feed-back and input. Is it fair to say that you no longer have any "blocking" issue but you > want to make sure that we revisit your points when we will start the protocol work ?=20 =20 Actually, if you look at the record, I have carefully never called for this ID to be blocked, although others have. I have expressed some reservations. But my main point was, and is, to put a marker down to say that in the future, there is a danger that the narrow point that this ID makes could be over-read, and that it shouldn't. =20 That said, making the ID clearer on these points can only be a good thing. I regret I haven't had the time to contribute more. =20 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** ------_=_NextPart_001_01C960F6.F66F2F30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 >  Thanks for your= feed-back=20 and input. Is it fair to say that you no longer have any "blocking" issue= but=20 you
 >  want to make sure that we revisit= your=20 points when we will start the protocol work ? 
 
Actually, if you look at the record, I have carefully never called= for=20 this ID
to be=20 blocked, although others have. I have expressed some=20 reservations.
But my main point was, and is, to put a marker down to say= that in=20 the
future, there is a danger that the narrow point that this ID makes= =20 could
be=20 over-read, and that it shouldn't.
 
That=20 said, making the ID clearer on these points can only be a good=20 thing.
I=20 regret I haven't had the time to contribute more.
 
****************************************************************= ****
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

------_=_NextPart_001_01C960F6.F66F2F30-- --===============0390375359== 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 --===============0390375359==-- From roll-bounces@ietf.org Thu Dec 18 02:03:33 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21AAE3A6B40; Thu, 18 Dec 2008 02:03:33 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 854063A6B40 for ; Thu, 18 Dec 2008 02:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 GBhrypeaJBUf for ; Thu, 18 Dec 2008 02:03:31 -0800 (PST) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id 04B013A6AB7 for ; Thu, 18 Dec 2008 02:03:30 -0800 (PST) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mBIA3IVG013747 for ; Thu, 18 Dec 2008 10:03:20 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mBIA3Ibp007573 for ; Thu, 18 Dec 2008 10:03:18 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Thu, 18 Dec 2008 10:03:18 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Thu, 18 Dec 2008 10:03:18 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 18 Dec 2008 10:03:14 -0000 Message-ID: In-Reply-To: <3C687FD9-8ABF-43D6-9F8F-6536417159BE@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] WorkingGroup LastCall:draft-ietf-roll-protocols-survey-02 Thread-Index: Aclggv0ynLOX2+7FQzWOpYAaw2Xe+QAdBUcw References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> <61D43925-D96D-41A0-A73B-E87B586245E3@thomasclausen.org> <7892795E1A87F04CADFCCF41FADD00FC06ADE37A@xmb-ams-337.emea.cisco.com> <3C687FD9-8ABF-43D6-9F8F-6536417159BE@cs.stanford.edu> From: "Dearlove, Christopher (UK)" To: "Philip Levis" , "Thomas Heide Clausen" X-OriginalArrivalTime: 18 Dec 2008 10:03:18.0057 (UTC) FILETIME=[D997E990:01C960F7] Cc: roll@ietf.org, Emmanuel Baccelli Subject: Re: [Roll] WorkingGroup LastCall:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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 short, simply sending periodic beacons is not a suitable approach > for LLNs. If your LLN is mostly static then sending exponentially backed-off beacons is not out of the question. (I'm neither arguing for or against using such beacons, merely noting they are not automatically disqualified.) ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Dec 18 02:17:34 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20FF33A6835; Thu, 18 Dec 2008 02:17:34 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 662233A6876 for ; Thu, 18 Dec 2008 02:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id af9yt7tvCPHP for ; Thu, 18 Dec 2008 02:17:31 -0800 (PST) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 2F0583A6767 for ; Thu, 18 Dec 2008 02:17:31 -0800 (PST) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mBIAHMnQ002113 for ; Thu, 18 Dec 2008 10:17:22 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mBIAHMdA017219 for ; Thu, 18 Dec 2008 10:17:22 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Thu, 18 Dec 2008 10:17:21 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Thu, 18 Dec 2008 10:17:21 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 18 Dec 2008 10:17:19 -0000 Message-ID: In-Reply-To: <44680fe70812171315y15473468k94b61b263d73f2ac@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] WorkingGroup LastCall:draft-ietf-roll-protocols-survey-02 Thread-Index: AclgjJUHJPMXUIf2TAi2EShaASYMMwAa2Mmw References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <61D43925-D96D-41A0-A73B-E87B586245E3@thomasclausen.org> <7892795E1A87F04CADFCCF41FADD00FC06ADE37A@xmb-ams-337.emea.cisco.com> <3C687FD9-8ABF-43D6-9F8F-6536417159BE@cs.stanford.edu> <44680fe70812171315y15473468k94b61b263d73f2ac@mail.gmail.com> From: "Dearlove, Christopher (UK)" To: "Stephen Dawson-Haggerty" , "Philip Levis" X-OriginalArrivalTime: 18 Dec 2008 10:17:21.0588 (UTC) FILETIME=[D0608740:01C960F9] Cc: Emmanuel Baccelli , roll@ietf.org, Thomas Heide Clausen Subject: Re: [Roll] WorkingGroup LastCall:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============1466820420==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============1466820420== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C960F9.CF151CBC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C960F9.CF151CBC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Would adding a note about this metric's limitations be a good idea? =20 That sounds like one. I guess if you split control and non-control costs (which can be argued against, but I'll assume it for now) what is important is that as well as having a low control cost, you need to also specify that the control signalling does the job of producing efficient routing, i.e. enabling low non-control costs. Inefficient routing can occur in at least three ways =20 - Using multiple routes. Of course some use of multiple routes might be a design feature for safety. But I think we're all agreed that uncontrolled blind flooding (as an extreme case) is not a good solution. =20 - Creating inefficient routes. Ideally a minimum metric route would be found. A solution within a known factor of that might be OK. A solution that always goes via a gateway may be acceptable (if the load on, and congestion at, the gateway is tolerable). The bad extreme case here is random routing (which in a finite sized network will eventally get you to your destination, but ...). =20 - Latency. Apart from being an issue in its own right, latency (such as waiting for a route finding process to execute, or an extreme case in a dynamic network of storing and opportunistically forwarding) adds queuing memory costs (or increased packet losses if queuing is limited). =20 My point is that saying "control costs should be minimal" ideally needs a "but control must do a good enough job" qualifier. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** ------_=_NextPart_001_01C960F9.CF151CBC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 >  Would adding a note= about=20 this metric's limitations be a good idea?
  
That sounds like one. I guess if you split control= and=20 non-control costs
(which can be argued against, but I'll assume it= for now)=20 what is important
is that as well as having a low control cost, you= need to=20 also specify that
the control signalling does the job of producing= efficient=20 routing, i.e.
enabling low non-control costs. Inefficient= routing can=20 occur in at least
three ways
 
- Using multiple routes. Of course some use of= multiple=20 routes might be
  a design feature for safety. But I think= we're all=20 agreed that uncontrolled
  blind flooding (as an extreme case) is= not a=20 good solution.
 
- Creating inefficient routes. Ideally a minimum= metric=20 route would be
  found. A solution within a known factor of= that=20 might be OK. A solution
  that always goes via a gateway may be= acceptable (if=20 the load on, and
  congestion at, the gateway is tolerable).= The bad=20 extreme case here is
  random routing (which in a finite sized= network will=20 eventally get you to
  your destination, but= ...).
 
- Latency. Apart from being an issue in its own= right,=20 latency (such as
  waiting for a route finding process to= execute, or=20 an extreme case in
  a dynamic network of storing and= opportunistically=20 forwarding) adds
  queuing memory costs (or increased packet= losses if=20 queuing is
  limited).
 
My point is that saying "control costs should be= minimal"=20 ideally needs
a "but control must do a good enough job"=20 qualifier.
****************************************************************= ****
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

------_=_NextPart_001_01C960F9.CF151CBC-- --===============1466820420== 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 --===============1466820420==-- From roll-bounces@ietf.org Thu Dec 18 03:03:00 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38E5D3A6A01; Thu, 18 Dec 2008 03:03:00 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27A2F3A6A01 for ; Thu, 18 Dec 2008 03:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOPt1w9v+oUM for ; Thu, 18 Dec 2008 03:02:57 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 2FCA93A67C0 for ; Thu, 18 Dec 2008 03:02:57 -0800 (PST) Received: by bwz14 with SMTP id 14so1306379bwz.13 for ; Thu, 18 Dec 2008 03:02:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=MOoHWTNmPZEVeJErBrsiXFMK8JlgL6BNNhrzCn7UbJE=; b=E+iJZz9tGW9kdmsDS+kBLuJnZ19CQx60CVgzKRvM9LVg/Wvt+uT2BGX2MM/2T0iaPH dzzto6XKE04RFUlfwvVvN6gAj4NI4n64Q709LxI71e2T9MYw60qi/qguEUjbzypLSU3f U7gjp2BHkAr1CReeen+tLt3GDkfbtoXmFoY94= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=wFyjVqw5i7V7wWyOUpedz9nXJ9DWa3jhPUsZuZcCZ/UNMd6omnx4icDFEdgmi0ieTn 5QAOukehzMaCvrkl8hsdLQiEC8fkFaRfUqHlfjnllTwwvYxBM7Sg96v4zkv8b6abbIDP 4xOwueHEjzLo2ecz6CHcuy2g6JTfUz1tqAwBA= Received: by 10.103.119.19 with SMTP id w19mr685120mum.80.1229598168343; Thu, 18 Dec 2008 03:02:48 -0800 (PST) Received: by 10.103.248.12 with HTTP; Thu, 18 Dec 2008 03:02:48 -0800 (PST) Message-ID: Date: Thu, 18 Dec 2008 12:02:48 +0100 From: "Emmanuel Baccelli" To: roll@ietf.org In-Reply-To: <7F73D017-FBC6-4AB2-9359-78501D90825F@cs.stanford.edu> MIME-Version: 1.0 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <3CEA849E-22CD-4DF1-A56B-E1C38572AA77@cisco.com> <6A3B39C4-8126-47D0-B29A-752191F4F487@cs.stanford.edu> <5467B083-1300-4723-9B5D-F45D6AED701B@thomasclausen.org> <260E044E-1C74-4C4D-9BF4-0A79E1A39177@cisco.com> <7F73D017-FBC6-4AB2-9359-78501D90825F@cs.stanford.edu> X-Google-Sender-Auth: 7173babcb9ade6f6 Subject: Re: [Roll] Proposal so as to reach a consensus on ** draft-ietf-roll-protocols-survey-02 ** X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============0820564742==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0820564742== Content-Type: multipart/alternative; boundary="----=_Part_19763_30025307.1229598168333" ------=_Part_19763_30025307.1229598168333 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wed, Dec 17, 2008 at 9:05 PM, Philip Levis wrote: > > On Dec 17, 2008, at 9:04 AM, JP Vasseur wrote: > > >> Now, let's try to be constructive and address your concerns. >> >> 1) Lack of background, context, ... in the document. Emmanuel is quite >> right that background is missing in the document as well as a clear >> conclusion: "how have we chosen the protocols in the survey, why protocols >> X, Y, Z, ... have not been included in the survey, ...". I saw that Phil >> agreed to add some text to address this issue. >> Emmanuel, does that address your concern (to be confirmed once you see the >> text) ? >> Phil, could you please propose some text ? >> > > The OSPF section will be renamed OSPF/IS-IS and I will add supporting text > that notes the distinctions between the two and why their analysis is the > same. I guess that's not all, right? I suppose there will be additional text justifying why the set of protocols (and not just OSPF/IS-IS) chosen to be evaluated is indeed a good sample of what is done in the IETF. Somewhere in this additional text, we also need some justification why DTN protocols are ignored and why there is not a word about NEMO-RO. I would rather recommend that one or two protocols such as PRoPHET (DTN protocol put forward by Stephen Farrell) be evaluated too, but if there is justification in the draft why not to do it, it would be OK I guess (at least with me). In any case, the goal of these additions would be to make the document both more self-contained and self-explanatory, while easier to relate with the content of the current charter. Emmanuel > > > >> 2) Missing protocols: we had to draw the line somewhere. *LOTS* of >> protocols have been proposed over the last decade. We had many suggestions >> to also look at protocol X, Y and Z. The decision was (according to our >> charter) to limit our survey to existing IETF protocols (RFC or very mature >> ID): OSPF, OLSR, TBRPF, RIP, AODV, DYMO, DSR. The list is already fairly >> long. The charter mentions DTN. The WG decided not to include DTN and this >> needs to be documented. >> Phil, could you please add some text ? Note that this does not mean that >> we may not borrow mechanism(s) from existing protocols by the way if we get >> re-chartered. >> > > The current text reads: > > "This document considers "existing routing protocols" to be protocols > that are specified in RFCs or, in the cases of DYMO > [I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very > mature draft which will most likely become an RFC." > > I propose > > "This document considers "existing routing protocols" to be routing > protocols > that are specified in RFCs or, in the cases of DYMO > [I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very > mature draft which will most likely become an RFC. It does not > examine the Network Mobility Basic Support Protocol (NEMO)[cite], > DTN bundles[cite], or the DTN Licklider protocol[cite] because they > are not routing protocols." > > >> 3) Is the goal to exclude existing routing protocols as potential >> candidates ? The answer is "no" but Thomas is right, this is currently not >> well explained in the document. The objective is to agree that none of the >> existing protocols meet the requirement but the solution might either be to >> develop a new one or extend an existing routing protocol (once we get >> re-chartered). >> Thomas, would that address your concern ? >> > > The current text reads: > > "As they were not designed with > these requirements in mind, existing protocols may or may not work > well in LLNs. The first step to reaching consensus on a routing > protocol for LLNs is to decide which of these two is true. If an > existing protocol can meet LLN requirements without any changes, then > barring extenuating circumstances, it behooves us to use an existing > standard. However, if no current protocol can meet LLN's > requirements, then further work will be needed to define and > standardize with a protocol that can. Whether or not such a protocol > involves modifications to an existing protocol or a new protocol > entirely is outside the scope of this document: this document simply > seeks to answer the question: do LLNs require a new protocol > specification document at all?" > > I'd appreciate advice on how to make this clearer. > > >> 4) Evaluation metric should be in a separate document: the approached >> adopted by the WG was to derive metrics from the requirements documents so >> as to perform the protocol survey. Once we will start protocol design, we >> will go back to the requirement documents since this is *the* objective of >> Requirements IDs. >> >> 5) Missing Metrics and Incorrect Metrics: Let us know if you have a list >> of metrics that are in your opinion "missing" and which metrics are >> "incorrect/inappropriate"? Or are we now in agreement based on 4) above ? >> >> > Phil > ------=_Part_19763_30025307.1229598168333 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

On Wed, Dec 17, 2008 at 9:05 PM, Philip = Levis <pal@cs.s= tanford.edu> wrote:

On Dec 17, 2008, at 9:04 AM, JP Vasseur wrote:


Now, let's try to be constructive and address your concerns.

1) Lack of background, context, ... in the document. Emmanuel is quite righ= t that background is missing in the document as well as a clear conclusion:= "how have we chosen the protocols in the survey, why protocols X, Y, = Z, ... have not been included in the survey, ...". I saw that Phil agr= eed to add some text to address this issue.
Emmanuel, does that address your concern (to be confirmed once you see the = text) ?
Phil, could you please propose some text ?

The OSPF section will be renamed OSPF/IS-IS and I will add supporting text = that notes the distinctions between the two and why their analysis is the s= ame.

I guess that's not all, right? I s= uppose there will be additional text justifying why the set of protocols (a= nd not just OSPF/IS-IS) chosen to be evaluated is indeed a good sample of w= hat is done in the IETF. Somewhere in this additional text, we also need so= me justification why DTN protocols are ignored and why there is not a word = about NEMO-RO. I would rather recommend that one or two protocols such as&n= bsp;= PRoPHET (DTN protocol put forward by Stephen Farrell) be evaluated too= , but if there is justification in the draft why not to do it, it would be = OK I guess (at least with me). In any case, the goal of these additions wou= ld be to make the document both more self-contained and self-explanatory, w= hile easier to relate with the content of the current charter.
=
Emmanuel

 



2) Missing protocols: we had to draw the line somewhere. *LOTS* of protocol= s have been proposed over the last decade. We had many suggestions to also = look at protocol X, Y and Z. The decision was (according to our charter) to= limit our survey to existing IETF protocols (RFC or very mature ID):  = ;OSPF, OLSR, TBRPF, RIP, AODV, DYMO, DSR. The list is already fairly long. = The charter mentions DTN. The WG decided not to include DTN and this needs = to be documented.
Phil, could you please add some text ? Note that this does not mean that we= may not borrow mechanism(s) from existing protocols by the way if we get r= e-chartered.

The current text reads:

"This document considers "existing routing protocols" to be = protocols
that are specified in RFCs or, in the cases of DYMO
[I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very
mature draft which will most likely become an RFC."

I propose

"This document considers "existing routing protocols" to be = routing protocols
that are specified in RFCs or, in the cases of DYMO
[I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very
mature draft which will most likely become an RFC. It does not
examine the Network Mobility Basic Support Protocol (NEMO)[cite],
DTN bundles[cite], or the DTN Licklider protocol[cite] because they
are not routing protocols."



3) Is the goal to exclude existing routing protocols as potential candidate= s ? The answer is "no" but Thomas is right, this is currently not= well explained in the document. The objective is to agree that none of the= existing protocols meet the requirement but the solution might either be t= o develop a new one or extend an existing routing protocol (once we get re-= chartered).
Thomas, would that address your concern ?

The current text reads:

"As they were not designed with
  these requirements in mind, existing protocols may or may not work<= br>   well in LLNs.  The first step to reaching consensus on a routi= ng
  protocol for LLNs is to decide which of these two is true.  If= an
  existing protocol can meet LLN requirements without any changes, th= en
  barring extenuating circumstances, it behooves us to use an existin= g
  standard.  However, if no current protocol can meet LLN's<= br>   requirements, then further work will be needed to define and
  standardize with a protocol that can.  Whether or not such a p= rotocol
  involves modifications to an existing protocol or a new protocol   entirely is outside the scope of this document: this document simpl= y
  seeks to answer the question: do LLNs require a new protocol
  specification document at all?"

I'd appreciate advice on how to make this clearer.



4) Evaluation metric should be in a separate document: the approached adopt= ed by the WG was to derive metrics from the requirements documents so as to= perform the protocol survey. Once we will start protocol design, we will g= o back to the requirement documents since this is *the* objective of Requir= ements IDs.

5) Missing Metrics and Incorrect Metrics: Let us know if you have a list of= metrics that are in your opinion "missing" and which metrics are= "incorrect/inappropriate"? Or are we now in agreement based on 4= ) above ?


Phil

------=_Part_19763_30025307.1229598168333-- --===============0820564742== 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 --===============0820564742==-- From roll-bounces@ietf.org Thu Dec 18 11:53:11 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A536028C105; Thu, 18 Dec 2008 11:53:11 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03D9D3A6B7B for ; Thu, 18 Dec 2008 11:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ugGBb0HTU4f for ; Thu, 18 Dec 2008 11:53:10 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 00CFA3A680C for ; Thu, 18 Dec 2008 11:53:09 -0800 (PST) Received: from [198.128.25.123] (GoatRock.dhcp.lbnl.us [198.128.25.123]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id mBIJqvbP019300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Dec 2008 11:52:59 -0800 (PST) Message-ID: <494A9206.4010709@eecs.berkeley.edu> Date: Thu, 18 Dec 2008 10:10:14 -0800 From: "David E. Culler" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> <61D43925-D96D-41A0-A73B-E87B586245E3@thomasclausen.org> <7892795E1A87F04CADFCCF41FADD00FC06ADE37A@xmb-ams-337.emea.cisco.com> <3C687FD9-8ABF-43D6-9F8F-6536417159BE@cs.stanford.edu> In-Reply-To: Cc: Emmanuel Baccelli , roll@ietf.org, Thomas Heide Clausen Subject: Re: [Roll] WorkingGroup LastCall:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============1223257452==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1223257452== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dearlove, Christopher (UK) wrote: 
In short, simply sending periodic beacons is not a suitable approach  
for LLNs.
    

If your LLN is mostly static then sending exponentially backed-off
beacons is not out of the question.
Indeed., such an approach would meet the criteria, although a fixed beacon interval would not.  It is a separate question under what conditions such a beacon strategy would provide adequate information.  (Yes, if things were truly static that is one case where it does.)  Of course, there are various adaptive strategies that approach this behavior while also dealing with changes.  That is the point.  Routing protocols in this space need to attend to such issues, rather than assume that beacons are cheap enough to be ignored.  We may find that existing protocols become much more attractive once they pay more careful attention to the beacon strategy.  

(I'm neither arguing for or against using such beacons, merely noting
they are not automatically disqualified.)

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

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--===============1223257452== 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 --===============1223257452==-- From roll-bounces@ietf.org Thu Dec 18 11:54:43 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC7CE28C123; Thu, 18 Dec 2008 11:54:43 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D648728C123 for ; Thu, 18 Dec 2008 11:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PS9im3riNVFF for ; Thu, 18 Dec 2008 11:54:41 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id 885BE3A6B7B for ; Thu, 18 Dec 2008 11:54:41 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so223663ywj.49 for ; Thu, 18 Dec 2008 11:54:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=5j5osI6CyqLipP8tOOaKEP+/l48WKqI/GB4NXurfpIY=; b=cABLu33q4I/5uOuu08pLrqDRFw7GjVmH3eO6Fu9UBVv5gbQZb+CZWho+sIis2UWu5q nMsBp3TZmiR6hNhWP/PZQxslU0EoZSysbSaMYJARNXhf0br1gkO2qdsjSdvFeg8PgFSK rrQvaU7/Zl7WxJBIVU8NKwXSk+d1NxDm8s3t8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=XE/ZiO/SysfOjivL0Ya6YLbNql7RNGnxxRHWHLRe+F+10EIg0djoJhGQjJliXmvQip RSxhvhkgRCUBxWGCUQuUFYEm3oFlBM+/03rRDtN5SvyFgqyJqpmkF8phNSURTmbbo6zz HgtFFIITwEs1U9LqdJxnpDmH8yxL1jg0A8AK4= Received: by 10.100.126.15 with SMTP id y15mr1718409anc.123.1229630073083; Thu, 18 Dec 2008 11:54:33 -0800 (PST) Received: by 10.100.42.11 with HTTP; Thu, 18 Dec 2008 11:54:32 -0800 (PST) Message-ID: <44680fe70812181154t62740241l40bf1af4d52ed765@mail.gmail.com> Date: Thu, 18 Dec 2008 11:54:32 -0800 From: "Stephen Dawson-Haggerty" To: "Dearlove, Christopher (UK)" In-Reply-To: MIME-Version: 1.0 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <61D43925-D96D-41A0-A73B-E87B586245E3@thomasclausen.org> <7892795E1A87F04CADFCCF41FADD00FC06ADE37A@xmb-ams-337.emea.cisco.com> <3C687FD9-8ABF-43D6-9F8F-6536417159BE@cs.stanford.edu> <44680fe70812171315y15473468k94b61b263d73f2ac@mail.gmail.com> X-Google-Sender-Auth: 8cb6c82d8eebee7b Cc: Emmanuel Baccelli , roll@ietf.org, Thomas Heide Clausen Subject: Re: [Roll] WorkingGroup LastCall:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============0779791910==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0779791910== Content-Type: multipart/alternative; boundary="----=_Part_18734_12050559.1229630073076" ------=_Part_18734_12050559.1229630073076 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree with everything you say, and will incorporate statements to this effect into the new version. I do see that you can argue against doing the evaluation this way. What I believe drove us to use this criteria is that having picked a set of protocols which all form routes in a pretty classical way, this is a fair way to compare them since they more or less achieve similar results. What we're getting at is that this assumption is implicit in our metric... If we were not writing an evaluation and instead were devising a set of tests which any ROLL protocol would need to pass, this would be less useful metric because it would not work for every possible protocol and might pass things like the flooding counterexample. However, given that these protocols work as they do, it seems fair. Steve On Thu, Dec 18, 2008 at 2:17 AM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > > Would adding a note about this metric's limitations be a good idea? > > That sounds like one. I guess if you split control and non-control costs > (which can be argued against, but I'll assume it for now) what is > important > is that as well as having a low control cost, you need to also specify that > the control signalling does the job of producing efficient routing, i.e. > enabling low non-control costs. Inefficient routing can occur in at least > three ways > > - Using multiple routes. Of course some use of multiple routes might be > a design feature for safety. But I think we're all agreed that > uncontrolled > blind flooding (as an extreme case) is not a good solution. > > - Creating inefficient routes. Ideally a minimum metric route would be > found. A solution within a known factor of that might be OK. A solution > that always goes via a gateway may be acceptable (if the load on, and > congestion at, the gateway is tolerable). The bad extreme case here is > random routing (which in a finite sized network will eventally get you to > your destination, but ...). > > - Latency. Apart from being an issue in its own right, latency (such as > waiting for a route finding process to execute, or an extreme case in > a dynamic network of storing and opportunistically forwarding) adds > queuing memory costs (or increased packet losses if queuing is > limited). > > My point is that saying "control costs should be minimal" ideally needs > a "but control must do a good enough job" qualifier. > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > ------=_Part_18734_12050559.1229630073076 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree with everything you say, and will incorporate statements to this effect into the new version.  I do see that you can argue against doing the evaluation this way.  What I believe drove us to use this criteria is that having picked a set of protocols which all form routes in a pretty classical way, this is a fair way to compare them since they more or less achieve similar results.  What we're getting at is that this assumption is implicit in our metric...

If we were not writing an evaluation and instead were devising a set of tests which any ROLL protocol would need to pass, this would be less useful metric because it would not work for every possible protocol and might pass things like the flooding counterexample.  However, given that these protocols work as they do, it seems fair.

Steve

On Thu, Dec 18, 2008 at 2:17 AM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
 >  Would adding a note about this metric's limitations be a good idea?
  
That sounds like one. I guess if you split control and non-control costs
(which can be argued against, but I'll assume it for now) what is important
is that as well as having a low control cost, you need to also specify that
the control signalling does the job of producing efficient routing, i.e.
enabling low non-control costs. Inefficient routing can occur in at least
three ways
 
- Using multiple routes. Of course some use of multiple routes might be
  a design feature for safety. But I think we're all agreed that uncontrolled
  blind flooding (as an extreme case) is not a good solution.
 
- Creating inefficient routes. Ideally a minimum metric route would be
  found. A solution within a known factor of that might be OK. A solution
  that always goes via a gateway may be acceptable (if the load on, and
  congestion at, the gateway is tolerable). The bad extreme case here is
  random routing (which in a finite sized network will eventally get you to
  your destination, but ...).
 
- Latency. Apart from being an issue in its own right, latency (such as
  waiting for a route finding process to execute, or an extreme case in
  a dynamic network of storing and opportunistically forwarding) adds
  queuing memory costs (or increased packet losses if queuing is
  limited).
 
My point is that saying "control costs should be minimal" ideally needs
a "but control must do a good enough job" qualifier.
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************


------=_Part_18734_12050559.1229630073076-- --===============0779791910== 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 --===============0779791910==-- From roll-bounces@ietf.org Thu Dec 18 12:45:48 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E96D28C10E; Thu, 18 Dec 2008 12:45:48 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22AE728C10E for ; Thu, 18 Dec 2008 12:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VA4VYIhwSNAp for ; Thu, 18 Dec 2008 12:45:46 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 629CB28C0FA for ; Thu, 18 Dec 2008 12:45:46 -0800 (PST) Received: from dnab42207e.stanford.edu ([171.66.32.126]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1LDPkY-0001Uf-GI; Thu, 18 Dec 2008 12:45:38 -0800 Message-Id: <327E11B9-FFF8-440F-AEEE-BFE2731D4845@cs.stanford.edu> From: Philip Levis To: "Dearlove, Christopher (UK)" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 18 Dec 2008 10:28:47 -0800 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <374005f30812050849refe8122i63629f469f8ba7c8@mail.gmail.com> <7471DA6B-7B09-42BB-8291-C30C83576295@cs.stanford.edu> <61D43925-D96D-41A0-A73B-E87B586245E3@thomasclausen.org> <7892795E1A87F04CADFCCF41FADD00FC06ADE37A@xmb-ams-337.emea.cisco.com> <3C687FD9-8ABF-43D6-9F8F-6536417159BE@cs.stanford.edu> X-Mailer: Apple Mail (2.929.2) X-Scan-Signature: 126b1dc68df40fcb6eeab1e6794671ae Cc: Emmanuel Baccelli , roll@ietf.org, Thomas Heide Clausen Subject: Re: [Roll] WorkingGroup LastCall:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Dec 18, 2008, at 2:03 AM, Dearlove, Christopher (UK) wrote: > >> In short, simply sending periodic beacons is not a suitable approach >> for LLNs. > > If your LLN is mostly static then sending exponentially backed-off > beacons is not out of the question. > > (I'm neither arguing for or against using such beacons, merely noting > they are not automatically disqualified.) Absolutely. This discussion came up in the interim meeting. I should have been clearer. Of course one needs to be able to set up routes proactively, e.g., through beacon packets. The issue arises when correct operation of a protocol depends on nodes to send periodic (fixed period) beacons, and this period is uniform across the network. This imposes an energy load on nodes which may be energy starved. The common case of this behavior is inferring packet losses from beacon timers. In these situations, a node MUST send beacons at some pre- defined, static, fixed rate or it cannot participate in the topology; this mechanism is problematic when it comes to low-power operation. The basic point of the control cost metric is to establish that, as the data rate approaches zero, the control rate should approach some very small and tunable epsilon. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Dec 18 12:45:53 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CBDA28C124; Thu, 18 Dec 2008 12:45:53 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4818328C0F2 for ; Thu, 18 Dec 2008 12:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkYTLJBJRti3 for ; Thu, 18 Dec 2008 12:45:51 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 607F728C124 for ; Thu, 18 Dec 2008 12:45:51 -0800 (PST) Received: from dnab42207e.stanford.edu ([171.66.32.126]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1LDPkd-0001Uf-OQ; Thu, 18 Dec 2008 12:45:44 -0800 Message-Id: <2BD0AD28-7D65-4EE8-9D67-999E01671EB6@cs.stanford.edu> From: Philip Levis To: Emmanuel Baccelli In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 18 Dec 2008 10:30:09 -0800 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <3CEA849E-22CD-4DF1-A56B-E1C38572AA77@cisco.com> <6A3B39C4-8126-47D0-B29A-752191F4F487@cs.stanford.edu> <5467B083-1300-4723-9B5D-F45D6AED701B@thomasclausen.org> <260E044E-1C74-4C4D-9BF4-0A79E1A39177@cisco.com> <7F73D017-FBC6-4AB2-9359-78501D90825F@cs.stanford.edu> X-Mailer: Apple Mail (2.929.2) X-Scan-Signature: 2ecb59bd28923317bd193fe54b7794cd Cc: roll@ietf.org Subject: Re: [Roll] Proposal so as to reach a consensus on ** draft-ietf-roll-protocols-survey-02 ** X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Comment inline. On Dec 18, 2008, at 3:02 AM, Emmanuel Baccelli wrote: > > > On Wed, Dec 17, 2008 at 9:05 PM, Philip Levis > wrote: > > On Dec 17, 2008, at 9:04 AM, JP Vasseur wrote: > > > Now, let's try to be constructive and address your concerns. > > 1) Lack of background, context, ... in the document. Emmanuel is > quite right that background is missing in the document as well as a > clear conclusion: "how have we chosen the protocols in the survey, > why protocols X, Y, Z, ... have not been included in the > survey, ...". I saw that Phil agreed to add some text to address > this issue. > Emmanuel, does that address your concern (to be confirmed once you > see the text) ? > Phil, could you please propose some text ? > > The OSPF section will be renamed OSPF/IS-IS and I will add > supporting text that notes the distinctions between the two and why > their analysis is the same. > > I guess that's not all, right? I suppose there will be additional > text justifying why the set of protocols (and not just OSPF/IS-IS) > chosen to be evaluated is indeed a good sample of what is done in > the IETF. Somewhere in this additional text, we also need some > justification why DTN protocols are ignored and why there is not a > word about NEMO-RO. I would rather recommend that one or two > protocols such as PRoPHET (DTN protocol put forward by Stephen > Farrell) be evaluated too, but if there is justification in the > draft why not to do it, it would be OK I guess (at least with me). > In any case, the goal of these additions would be to make the > document both more self-contained and self-explanatory, while easier > to relate with the content of the current charter. > Emmanuel, did you read the rest of my message? I address NEMO/DTN on point 2. Please acknowledge. > > 2) Missing protocols: we had to draw the line somewhere. *LOTS* of > protocols have been proposed over the last decade. We had many > suggestions to also look at protocol X, Y and Z. The decision was > (according to our charter) to limit our survey to existing IETF > protocols (RFC or very mature ID): OSPF, OLSR, TBRPF, RIP, AODV, > DYMO, DSR. The list is already fairly long. The charter mentions > DTN. The WG decided not to include DTN and this needs to be > documented. > Phil, could you please add some text ? Note that this does not mean > that we may not borrow mechanism(s) from existing protocols by the > way if we get re-chartered. > > The current text reads: > > "This document considers "existing routing protocols" to be protocols > that are specified in RFCs or, in the cases of DYMO > [I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very > mature draft which will most likely become an RFC." > > I propose > > "This document considers "existing routing protocols" to be routing > protocols > that are specified in RFCs or, in the cases of DYMO > [I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very > mature draft which will most likely become an RFC. It does not > examine the Network Mobility Basic Support Protocol (NEMO)[cite], > DTN bundles[cite], or the DTN Licklider protocol[cite] because they > are not routing protocols." > Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Dec 18 12:45:56 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C88B028C142; Thu, 18 Dec 2008 12:45:56 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB9AD28C142 for ; Thu, 18 Dec 2008 12:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxB+tlMLbUnZ for ; Thu, 18 Dec 2008 12:45:54 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id ADDAE28C140 for ; Thu, 18 Dec 2008 12:45:54 -0800 (PST) Received: from dnab42207e.stanford.edu ([171.66.32.126]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1LDPkg-0001Uf-S4; Thu, 18 Dec 2008 12:45:47 -0800 Message-Id: <9EF69910-C1CD-457C-BF6A-FD325C37151D@cs.stanford.edu> From: Philip Levis To: Ulrich Herberg In-Reply-To: <25c114b90812171341i12b0bc5fy91049fbfb57d21ac@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 18 Dec 2008 11:08:32 -0800 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <61D43925-D96D-41A0-A73B-E87B586245E3@thomasclausen.org> <7892795E1A87F04CADFCCF41FADD00FC06ADE37A@xmb-ams-337.emea.cisco.com> <3C687FD9-8ABF-43D6-9F8F-6536417159BE@cs.stanford.edu> <25c114b90812171341i12b0bc5fy91049fbfb57d21ac@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) X-Scan-Signature: 1c1d34d4ae2aac1d1f929c6f17b0cb0c Cc: Emmanuel Baccelli , "Dearlove, Christopher \(UK\)" , roll@ietf.org, Thomas Heide Clausen Subject: Re: [Roll] WorkingGroup LastCall:draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Dec 17, 2008, at 1:41 PM, Ulrich Herberg wrote: > > > I don't understand your argument. Why is "control cost" a better > criterion than "total cost"? In terms of energy consumption, even a > very low control cost can inflict very high data traffic cost (e.g. > the broadcast example). It is the total amount of sent frames that > is proportional to the energy consumption, not just the control > traffic. You say "more packets use more battery". Correct, but "more > packets" include more data packets as well as more control packets. Necessary, but not sufficient. That is, the control cost criterion is necessary for a ROLL protocol, but is not a sufficient determinant of its utility. The assumption is that the sufficient conditions, specified in the application requirements documents, preclude such an approach. Such a broadcast protocol, for example, would satisfy neither the node cost nor link cost criteria. A more technical answer is that any analysis of data cost requires a simplification of wireless such that the resulting analysis is neither helpful nor valid, because it must address the temporal properties of links. Don't forget, O() notation deals with the worst case. For most routing protocols, it is fairly simple to construct situations where they will have an unbounded total cost (e.g., cannot deliver packets). Evaluating data cost would therefore require specifying a simplified wireless communication model and assumptions of link behavior, to narrow the "expected" environments such that protocols can be analyzed, such as the independence of link losses, effects of interference, topology, etc. This kind of narrow investigation would itself be an issue of tremendous debate, of dubious worth, and furthermore would not change the conclusion of the document. So why add it? > > > > In short, simply sending periodic beacons is not a suitable approach > for LLNs. It's a non-starter for a ROLL protocol. That's why this > criterion is here: it articulates that control rates cannot surpass > data rates. Of course you'd like them to be *much* lower, but this > criterion sets an upper bound. While you might say that it's too > weak, there are many protocols that don't meet it! > > I think you have to be careful when defining the criteria of a > routing protocol for LLNs not to have a particular routing solution > in mind. Part of the goal of this draft is to set objective criteria > for selecting routing protocols for LLNs. It is dangerous to dismiss > any proactive routing protocol in advance by saying "sending > periodic beacons is not a suitable approach for LLNs", and setting > the selection criteria accordingly. I apologize for writing a bit too tersely there; that's not what I meant. This came up in the interim meeting. The point that a protocol requires all nodes to send beacons at some fixed rate (above a very small epsilon) does not meet the control cost criterion does not preclude proactive routing. I 100% agree that we do not want to preclude such approaches. Please see my response to Christopher. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Dec 18 23:15:02 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFF9B3A67F3; Thu, 18 Dec 2008 23:15:02 -0800 (PST) X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id ADF0D3A67F3; Thu, 18 Dec 2008 23:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081219071501.ADF0D3A67F3@core3.amsl.com> Date: Thu, 18 Dec 2008 23:15:01 -0800 (PST) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-indus-routing-reqs-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Industrial Routing Requirements in Low Power and Lossy Networks Author(s) : D. Networks, et al. Filename : draft-ietf-roll-indus-routing-reqs-03.txt Pages : 24 Date : 2008-12-18 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 by extending the information set available from wired systems. In an industrial environment, low power, high reliability, and easy installation and maintenance are mandatory qualities for wireless devices. The aim of this document is to analyze the requirements for the routing protocol used for Low power and Lossy Networks (LLN) in industrial environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-indus-routing-reqs-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-indus-routing-reqs-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-18230725.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 Thu Dec 18 23:33:36 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A16743A6846; Thu, 18 Dec 2008 23:33:36 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C9D13A6846 for ; Thu, 18 Dec 2008 23:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.316 X-Spam-Level: X-Spam-Status: No, score=-10.316 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5j+15-X2luIO for ; Thu, 18 Dec 2008 23:33:34 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 44AA33A6828 for ; Thu, 18 Dec 2008 23:33:34 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,248,1228089600"; d="scan'208";a="29074819" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 Dec 2008 07:33:23 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mBJ7XNwK026667 for ; Fri, 19 Dec 2008 08:33:23 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBJ7XN2w028306 for ; Fri, 19 Dec 2008 07:33:23 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Dec 2008 08:33:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C961AC.12B1E25D" Date: Fri, 19 Dec 2008 08:33:18 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC06B94252@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-roll-indus-routing-reqs-03 Thread-Index: AclhqHJ/799qfwaGShipMoM6TEMv2wAAvmyw From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 19 Dec 2008 07:33:23.0470 (UTC) FILETIME=[12D09AE0:01C961AC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4277; t=1229672003; x=1230536003; 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:=20FW=3A=20New=20Version=20Notification=20for=20dr aft-ietf-roll-indus-routing-reqs-03=20 |Sender:=20; bh=LyhZw9bK9J0HIgC7YT2Pk+TKBvC+gPtRX7aajUaU4ko=; b=LYurXNd2S/VyL6uSx4PxYw3a5BOJPVRSIQKX+r4YVFMm+xHIn3fa40Hy/S GVCShUtiMJwZ1KFeyn86SwXTYEtPDdS2r5T7+JHkvNFX8OsZ30U1kki2kgQs VHFZGcvH6J; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [Roll] FW: New Version Notification for draft-ietf-roll-indus-routing-reqs-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C961AC.12B1E25D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: We just published a new version (03) of the ROLL industrial routing reqs. Some language was clarified to address off-list comments, in particular around MUSTs and SHOULDs.=20 We clarified the requirement for "autonomicity", that is the need for the device to discover and adapt to its environment. Have a great season, Pascal ------_=_NextPart_001_01C961AC.12B1E25D Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from xbh-ams-331.emea.cisco.com ([144.254.231.71]) by xmb-ams-337.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Dec 2008 08:07:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Dec 2008 08:07:25 +0100 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Dec 2008 23:07:18 -0800 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 19 Dec 2008 07:07:17 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBJ77IIF001873 for ; Thu, 18 Dec 2008 23:07:18 -0800 Received: from sj-inbound-b.cisco.com (sj-inbound-b.cisco.com [128.107.234.205]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mBJ7781o021373 for ; Fri, 19 Dec 2008 07:07:17 GMT Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-b.cisco.com with ESMTP; 19 Dec 2008 07:07:17 +0000 Received: by core3.amsl.com (Postfix, from userid 30) id 185553A6846; Thu, 18 Dec 2008 23:07:25 -0800 (PST) Content-class: urn:content-classes:message Subject: New Version Notification for draft-ietf-roll-indus-routing-reqs-03 Date: Fri, 19 Dec 2008 08:07:25 +0100 Message-ID: <20081219070725.185553A6846@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-roll-indus-routing-reqs-03 Thread-Index: AclhqHJ/799qfwaGShipMoM6TEMv2w== From: "IETF I-D Submission Tool" To: "Pascal Thubert (pthubert)" Cc: , , DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1yb2xsLWluZHVzLXJvdXRpbmctcmVx cy0wMy50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bHkgc3VibWl0dGVkIGJ5IFBhc2NhbCBUaHViZXJ0 IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1p ZXRmLXJvbGwtaW5kdXMtcm91dGluZy1yZXFzDQpSZXZpc2lvbjoJIDAzDQpUaXRsZToJCSBJbmR1 c3RyaWFsIFJvdXRpbmcgUmVxdWlyZW1lbnRzIGluIExvdyBQb3dlciBhbmQgTG9zc3kgTmV0d29y a3MNCkNyZWF0aW9uX2RhdGU6CSAyMDA4LTEyLTE4DQpXRyBJRDoJCSByb2xsDQpOdW1iZXJfb2Zf cGFnZXM6IDI0DQoNCkFic3RyYWN0Og0KV2lyZWxlc3MsIGxvdyBwb3dlciBmaWVsZCBkZXZpY2Vz IGVuYWJsZSBpbmR1c3RyaWFsIHVzZXJzIHRvDQpzaWduaWZpY2FudGx5IGluY3JlYXNlIHRoZSBh bW91bnQgb2YgaW5mb3JtYXRpb24gY29sbGVjdGVkIGFuZCB0aGUNCm51bWJlciBvZiBjb250cm9s IHBvaW50cyB0aGF0IGNhbiBiZSByZW1vdGVseSBtYW5hZ2VkLiAgVGhlDQpkZXBsb3ltZW50IG9m IHRoZXNlIHdpcmVsZXNzIGRldmljZXMgd2lsbCBzaWduaWZpY2FudGx5IGltcHJvdmUgdGhlDQpw cm9kdWN0aXZpdHkgYW5kIHNhZmV0eSBvZiB0aGUgcGxhbnRzIHdoaWxlIGluY3JlYXNpbmcgdGhl IGVmZmljaWVuY3kNCm9mIHRoZSBwbGFudCB3b3JrZXJzIGJ5IGV4dGVuZGluZyB0aGUgaW5mb3Jt YXRpb24gc2V0IGF2YWlsYWJsZSBmcm9tDQp3aXJlZCBzeXN0ZW1zLiAgSW4gYW4gaW5kdXN0cmlh bCBlbnZpcm9ubWVudCwgbG93IHBvd2VyLCBoaWdoDQpyZWxpYWJpbGl0eSwgYW5kIGVhc3kgaW5z dGFsbGF0aW9uIGFuZCBtYWludGVuYW5jZSBhcmUgbWFuZGF0b3J5DQpxdWFsaXRpZXMgZm9yIHdp cmVsZXNzIGRldmljZXMuICBUaGUgYWltIG9mIHRoaXMgZG9jdW1lbnQgaXMgdG8NCmFuYWx5emUg dGhlIHJlcXVpcmVtZW50cyBmb3IgdGhlIHJvdXRpbmcgcHJvdG9jb2wgdXNlZCBmb3IgTG93IHBv d2VyDQphbmQgTG9zc3kgTmV0d29ya3MgKExMTikgaW4gaW5kdXN0cmlhbCBlbnZpcm9ubWVudHMu DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQuDQoN Cg0K ------_=_NextPart_001_01C961AC.12B1E25D 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_001_01C961AC.12B1E25D-- From roll-bounces@ietf.org Fri Dec 19 00:58:18 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CE0528C0DF; Fri, 19 Dec 2008 00:58:18 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06C2928C0DF for ; Fri, 19 Dec 2008 00:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78gsRZzrTeMM for ; Fri, 19 Dec 2008 00:58:16 -0800 (PST) Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by core3.amsl.com (Postfix) with ESMTP id 3A3D73A69D3 for ; Fri, 19 Dec 2008 00:58:16 -0800 (PST) Received: by fxm13 with SMTP id 13so190714fxm.13 for ; Fri, 19 Dec 2008 00:58:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=7beF7BIe7Prf66NCfY7uaNXxUaFlq9fMWp6BU2svlOw=; b=ocd6ObQRFCit5zlcq8gfQgv7kYTSuSkG1VvJXJCee8KxnobdYbGJbP/L0bWmBiO4KW ox94mmwPYW3FrnGaRGiANEWjRA7zfZiXVH670xN3YYELUYumKupbfxu8PEsU8FAhZJhj dlFUFb7uOFC+BDT93Cq+Jm1PMzS5htIbHmaIk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=oJ1Ihx9HM4Ni2V8aiNlr1D6SbXbIeTZLQZSgo0iiqs8ZE9nitPfJFCdls4WBOounMh Xi/irOrygbUjyTxKFRKJmx+UN7UlSpwbI9QgYlMO7BrXtyzAVoFa28BmNEcqLkieCVAK SXZArA/0t5pNVKzCzI3ezg+iCTyXsiEoOrWNM= Received: by 10.103.102.17 with SMTP id e17mr1133855mum.136.1229677086999; Fri, 19 Dec 2008 00:58:06 -0800 (PST) Received: by 10.103.248.12 with HTTP; Fri, 19 Dec 2008 00:58:06 -0800 (PST) Message-ID: Date: Fri, 19 Dec 2008 09:58:06 +0100 From: "Emmanuel Baccelli" To: "ROLL WG" In-Reply-To: <2BD0AD28-7D65-4EE8-9D67-999E01671EB6@cs.stanford.edu> MIME-Version: 1.0 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <3CEA849E-22CD-4DF1-A56B-E1C38572AA77@cisco.com> <6A3B39C4-8126-47D0-B29A-752191F4F487@cs.stanford.edu> <5467B083-1300-4723-9B5D-F45D6AED701B@thomasclausen.org> <260E044E-1C74-4C4D-9BF4-0A79E1A39177@cisco.com> <7F73D017-FBC6-4AB2-9359-78501D90825F@cs.stanford.edu> <2BD0AD28-7D65-4EE8-9D67-999E01671EB6@cs.stanford.edu> X-Google-Sender-Auth: e9d8819a1fe53743 Subject: Re: [Roll] Proposal so as to reach a consensus on ** draft-ietf-roll-protocols-survey-02 ** X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============0019943008==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0019943008== Content-Type: multipart/alternative; boundary="----=_Part_32491_32421777.1229677086983" ------=_Part_32491_32421777.1229677086983 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Thu, Dec 18, 2008 at 7:30 PM, Philip Levis wrote: > Comment inline. > > On Dec 18, 2008, at 3:02 AM, Emmanuel Baccelli wrote: > > >> >> On Wed, Dec 17, 2008 at 9:05 PM, Philip Levis >> wrote: >> >> On Dec 17, 2008, at 9:04 AM, JP Vasseur wrote: >> >> >> Now, let's try to be constructive and address your concerns. >> >> 1) Lack of background, context, ... in the document. Emmanuel is quite >> right that background is missing in the document as well as a clear >> conclusion: "how have we chosen the protocols in the survey, why protocols >> X, Y, Z, ... have not been included in the survey, ...". I saw that Phil >> agreed to add some text to address this issue. >> Emmanuel, does that address your concern (to be confirmed once you see the >> text) ? >> Phil, could you please propose some text ? >> >> The OSPF section will be renamed OSPF/IS-IS and I will add supporting text >> that notes the distinctions between the two and why their analysis is the >> same. >> >> I guess that's not all, right? I suppose there will be additional text >> justifying why the set of protocols (and not just OSPF/IS-IS) chosen to be >> evaluated is indeed a good sample of what is done in the IETF. Somewhere in >> this additional text, we also need some justification why DTN protocols are >> ignored and why there is not a word about NEMO-RO. I would rather recommend >> that one or two protocols such as PRoPHET (DTN protocol put forward by >> Stephen Farrell) be evaluated too, but if there is justification in the >> draft why not to do it, it would be OK I guess (at least with me). In any >> case, the goal of these additions would be to make the document both more >> self-contained and self-explanatory, while easier to relate with the content >> of the current charter. >> >> > > Emmanuel, did you read the rest of my message? I address NEMO/DTN on point > 2. Please acknowledge. > Here are some relevant pointers (non-exhaustive list): http://tools.ietf.org/html/draft-irtf-dtnrg-prophet-01 http://tools.ietf.org/html/draft-thubert-tree-discovery-06 They are in scope (NEMO space and DTN space) and they are describing routing protocols that may be of interest for ROLL. If we just add the line you proposed, there will be no justification why they are not evaluated. Do you agree? So we have a choice to make: either (i) justify why such routing approaches are not in scope, or (ii) evaluate a couple of such protocols in the draft, so as to partially cover DTN and NEMO spaces, as the charter indicates. I suppose the latter wouldn't take so long? It's just a couple of additional paragraphs and a couple of additional lines in the pass/fail table, like for the protocols already evaluated in the draft... Do you agree? Emmanuel > > > >> 2) Missing protocols: we had to draw the line somewhere. *LOTS* of >> protocols have been proposed over the last decade. We had many suggestions >> to also look at protocol X, Y and Z. The decision was (according to our >> charter) to limit our survey to existing IETF protocols (RFC or very mature >> ID): OSPF, OLSR, TBRPF, RIP, AODV, DYMO, DSR. The list is already fairly >> long. The charter mentions DTN. The WG decided not to include DTN and this >> needs to be documented. >> Phil, could you please add some text ? Note that this does not mean that >> we may not borrow mechanism(s) from existing protocols by the way if we get >> re-chartered. >> >> The current text reads: >> >> "This document considers "existing routing protocols" to be protocols >> that are specified in RFCs or, in the cases of DYMO >> [I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very >> mature draft which will most likely become an RFC." >> >> I propose >> >> "This document considers "existing routing protocols" to be routing >> protocols >> that are specified in RFCs or, in the cases of DYMO >> [I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very >> mature draft which will most likely become an RFC. It does not >> examine the Network Mobility Basic Support Protocol (NEMO)[cite], >> DTN bundles[cite], or the DTN Licklider protocol[cite] because they >> are not routing protocols." >> >> > Phil > ------=_Part_32491_32421777.1229677086983 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Thu, Dec 18, 2008 at 7:30 PM, Philip Levis <pal@cs.stanford.edu> wrote:
Comment inline.


On Dec 18, 2008, at 3:02 AM, Emmanuel Baccelli wrote:



On Wed, Dec 17, 2008 at 9:05 PM, Philip Levis <pal@cs.stanford.edu> wrote:

On Dec 17, 2008, at 9:04 AM, JP Vasseur wrote:


Now, let's try to be constructive and address your concerns.

1) Lack of background, context, ... in the document. Emmanuel is quite right that background is missing in the document as well as a clear conclusion: "how have we chosen the protocols in the survey, why protocols X, Y, Z, ... have not been included in the survey, ...". I saw that Phil agreed to add some text to address this issue.
Emmanuel, does that address your concern (to be confirmed once you see the text) ?
Phil, could you please propose some text ?

The OSPF section will be renamed OSPF/IS-IS and I will add supporting text that notes the distinctions between the two and why their analysis is the same.

I guess that's not all, right? I suppose there will be additional text justifying why the set of protocols (and not just OSPF/IS-IS) chosen to be evaluated is indeed a good sample of what is done in the IETF. Somewhere in this additional text, we also need some justification why DTN protocols are ignored and why there is not a word about NEMO-RO. I would rather recommend that one or two protocols such as PRoPHET (DTN protocol put forward by Stephen Farrell) be evaluated too, but if there is justification in the draft why not to do it, it would be OK I guess (at least with me). In any case, the goal of these additions would be to make the document both more self-contained and self-explanatory, while easier to relate with the content of the current charter.



Emmanuel, did you read the rest of my message? I address NEMO/DTN on point 2. Please acknowledge.


Here are some relevant pointers (non-exhaustive list):


They are in scope (NEMO space and DTN space) and they are describing routing protocols that may be of interest for ROLL.

If we just add the line you proposed, there will be no justification why they are not evaluated. Do you agree?

So we have a choice to make: either
(i) justify why such routing approaches are not in scope, or 
(ii) evaluate a couple of such protocols in the draft, so as to partially cover DTN and NEMO spaces, as the charter indicates. 

I suppose the latter wouldn't take so long? It's just a couple of additional paragraphs and a couple of additional lines in the pass/fail table, like for the protocols already evaluated in the draft... Do you agree?

Emmanuel




 



2) Missing protocols: we had to draw the line somewhere. *LOTS* of protocols have been proposed over the last decade. We had many suggestions to also look at protocol X, Y and Z. The decision was (according to our charter) to limit our survey to existing IETF protocols (RFC or very mature ID):  OSPF, OLSR, TBRPF, RIP, AODV, DYMO, DSR. The list is already fairly long. The charter mentions DTN. The WG decided not to include DTN and this needs to be documented.
Phil, could you please add some text ? Note that this does not mean that we may not borrow mechanism(s) from existing protocols by the way if we get re-chartered.

The current text reads:

"This document considers "existing routing protocols" to be protocols
that are specified in RFCs or, in the cases of DYMO
[I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very
mature draft which will most likely become an RFC."

I propose

"This document considers "existing routing protocols" to be routing protocols
that are specified in RFCs or, in the cases of DYMO
[I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very
mature draft which will most likely become an RFC. It does not
examine the Network Mobility Basic Support Protocol (NEMO)[cite],
DTN bundles[cite], or the DTN Licklider protocol[cite] because they
are not routing protocols."


Phil

------=_Part_32491_32421777.1229677086983-- --===============0019943008== 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 --===============0019943008==-- From roll-bounces@ietf.org Fri Dec 19 16:51:10 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C5B83A6A57; Fri, 19 Dec 2008 16:51:10 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B38273A6A57 for ; Fri, 19 Dec 2008 16:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bj67DJ9sW6di for ; Fri, 19 Dec 2008 16:51:07 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id 05E1A3A6A25 for ; Fri, 19 Dec 2008 16:51:06 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so435549yxg.49 for ; Fri, 19 Dec 2008 16:50:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=ahk+bzCwmMWluhkCxQfRZabbRfViG6iSpqQas0lNpuU=; b=L/7hVOhCPh2tfRDiPYo4xaQZ0ujWehBnQLNL5/2MEXemTiYQNPu9HUK8oe3Cps0QTY skcym8YIucYHYWJGgGpRI30Cr2qK87dHpluaNL99JRr9MWN70O0PqOU74iqEeStglCP1 fkDv+0tiTCDDqlHCDy1ELxsa+L/z7T7eZ/AC4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=MVH0O3Rjzl0sTmWhmaIoaF1Or6Q4z83i26JjOKOkoB9I91x3oN9dPiWzDSsN8CpHcx 3qA+w/vl0ZJi8UFWFUNNnc/GGLyV9/db8DCcsYPxiC4aDmT3ZPY+exFBaNtRI5Q/OrYt HMHmcErYjVn1wm6tVFJ6QHw7U4JqNrZomv2ek= Received: by 10.100.253.7 with SMTP id a7mr2613696ani.159.1229734257889; Fri, 19 Dec 2008 16:50:57 -0800 (PST) Received: by 10.100.42.11 with HTTP; Fri, 19 Dec 2008 16:50:57 -0800 (PST) Message-ID: <44680fe70812191650r233e59c5r8cc652c617eaf989@mail.gmail.com> Date: Fri, 19 Dec 2008 16:50:57 -0800 From: "Stephen Dawson-Haggerty" To: "Emmanuel Baccelli" In-Reply-To: MIME-Version: 1.0 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <3CEA849E-22CD-4DF1-A56B-E1C38572AA77@cisco.com> <6A3B39C4-8126-47D0-B29A-752191F4F487@cs.stanford.edu> <5467B083-1300-4723-9B5D-F45D6AED701B@thomasclausen.org> <260E044E-1C74-4C4D-9BF4-0A79E1A39177@cisco.com> <7F73D017-FBC6-4AB2-9359-78501D90825F@cs.stanford.edu> <2BD0AD28-7D65-4EE8-9D67-999E01671EB6@cs.stanford.edu> X-Google-Sender-Auth: c825fe89eaff260e Cc: ROLL WG Subject: Re: [Roll] Proposal so as to reach a consensus on ** draft-ietf-roll-protocols-survey-02 ** X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============0889156309==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0889156309== Content-Type: multipart/alternative; boundary="----=_Part_31767_24856049.1229734257884" ------=_Part_31767_24856049.1229734257884 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, We are making good progress at integrating all this discussion into the next revision; however, there has been a lot of traffic and I want to make sure we hit on everyone's comments. I've put below a preliminary changelog for the document. These are only the major changes so far; there are others which are more typographical and thus not listed. If you feel that I am missing something which we discussed, please let me know either personally or to the list. Thanks, Steve - OSPF changed to OSPF/IS-IS, explain the distinctions and why the analysis is the same - Notes justifying why we don't look at NEMO/DTN (verbatim from JP, Phil) since they're in the charter. - Update the "control cost" metric: note that this metric is "necessary but not sufficient" - Be a more explicit about reqs and limitations in the intro. - Update DYMO to talk about distance, not hopcount - T. Clausen's long email (most should have been considered & addressed) - OLSRv2 changed to ? in the control cost metric, because it might be possible to pass with the right sort of aging of updates. ("Fisheye State Routing in Mobile Ad Hoc Networks"). It would almost certainly require a new specification to say how to do this in a correct and inoperable way, but might not violate the specification. manet-fsr-00 seems like it has not been updated in quite a while. FSR does not alter the "table scalability "; it's not claimed in the paper. On Fri, Dec 19, 2008 at 12:58 AM, Emmanuel Baccelli < Emmanuel.Baccelli@inria.fr> wrote: > > > On Thu, Dec 18, 2008 at 7:30 PM, Philip Levis wrote: > >> Comment inline. >> >> On Dec 18, 2008, at 3:02 AM, Emmanuel Baccelli wrote: >> >> >>> >>> On Wed, Dec 17, 2008 at 9:05 PM, Philip Levis >>> wrote: >>> >>> On Dec 17, 2008, at 9:04 AM, JP Vasseur wrote: >>> >>> >>> Now, let's try to be constructive and address your concerns. >>> >>> 1) Lack of background, context, ... in the document. Emmanuel is quite >>> right that background is missing in the document as well as a clear >>> conclusion: "how have we chosen the protocols in the survey, why protocols >>> X, Y, Z, ... have not been included in the survey, ...". I saw that Phil >>> agreed to add some text to address this issue. >>> Emmanuel, does that address your concern (to be confirmed once you see >>> the text) ? >>> Phil, could you please propose some text ? >>> >>> The OSPF section will be renamed OSPF/IS-IS and I will add supporting >>> text that notes the distinctions between the two and why their analysis is >>> the same. >>> >>> I guess that's not all, right? I suppose there will be additional text >>> justifying why the set of protocols (and not just OSPF/IS-IS) chosen to be >>> evaluated is indeed a good sample of what is done in the IETF. Somewhere in >>> this additional text, we also need some justification why DTN protocols are >>> ignored and why there is not a word about NEMO-RO. I would rather recommend >>> that one or two protocols such as PRoPHET (DTN protocol put forward by >>> Stephen Farrell) be evaluated too, but if there is justification in the >>> draft why not to do it, it would be OK I guess (at least with me). In any >>> case, the goal of these additions would be to make the document both more >>> self-contained and self-explanatory, while easier to relate with the content >>> of the current charter. >>> >>> >> >> Emmanuel, did you read the rest of my message? I address NEMO/DTN on point >> 2. Please acknowledge. >> > > > Here are some relevant pointers (non-exhaustive list): > > http://tools.ietf.org/html/draft-irtf-dtnrg-prophet-01 > http://tools.ietf.org/html/draft-thubert-tree-discovery-06 > > They are in scope (NEMO space and DTN space) and they are describing > routing protocols that may be of interest for ROLL. > > If we just add the line you proposed, there will be no justification why > they are not evaluated. Do you agree? > > So we have a choice to make: either > (i) justify why such routing approaches are not in scope, or > (ii) evaluate a couple of such protocols in the draft, so as to partially > cover DTN and NEMO spaces, as the charter indicates. > > I suppose the latter wouldn't take so long? It's just a couple of > additional paragraphs and a couple of additional lines in the pass/fail > table, like for the protocols already evaluated in the draft... Do you > agree? > > Emmanuel > > > > > > >> >> >> >>> 2) Missing protocols: we had to draw the line somewhere. *LOTS* of >>> protocols have been proposed over the last decade. We had many suggestions >>> to also look at protocol X, Y and Z. The decision was (according to our >>> charter) to limit our survey to existing IETF protocols (RFC or very mature >>> ID): OSPF, OLSR, TBRPF, RIP, AODV, DYMO, DSR. The list is already fairly >>> long. The charter mentions DTN. The WG decided not to include DTN and this >>> needs to be documented. >>> Phil, could you please add some text ? Note that this does not mean that >>> we may not borrow mechanism(s) from existing protocols by the way if we get >>> re-chartered. >>> >>> The current text reads: >>> >>> "This document considers "existing routing protocols" to be protocols >>> that are specified in RFCs or, in the cases of DYMO >>> [I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very >>> mature draft which will most likely become an RFC." >>> >>> I propose >>> >>> "This document considers "existing routing protocols" to be routing >>> protocols >>> that are specified in RFCs or, in the cases of DYMO >>> [I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very >>> mature draft which will most likely become an RFC. It does not >>> examine the Network Mobility Basic Support Protocol (NEMO)[cite], >>> DTN bundles[cite], or the DTN Licklider protocol[cite] because they >>> are not routing protocols." >>> >>> >> Phil >> > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > ------=_Part_31767_24856049.1229734257884 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All,
We are making good progress at integrating all this discussion into the next revision; however, there has been a lot of traffic and I want to make sure we hit on everyone's comments.  I've put below a preliminary changelog for the document.  These are only the major changes so far; there are others which are more typographical and thus not listed.  If you feel that I am missing something which we discussed, please let me know either personally or to the list.

Thanks,
Steve

  - OSPF changed to OSPF/IS-IS, explain the distinctions and why the analysis is the same
  - Notes justifying why we don't look at NEMO/DTN (verbatim from JP, Phil) since they're in the charter.
  - Update the "control cost" metric: note that this metric is "necessary but not sufficient"
  - Be a more explicit about reqs and limitations in the intro.
  - Update DYMO to talk about distance, not hopcount
  - T. Clausen's long email (most should have been considered & addressed)
  - OLSRv2 changed to ? in the control cost metric, because it might be possible to pass with the right sort of aging of updates. ("Fisheye State Routing in Mobile Ad Hoc Networks").  It would almost certainly require a new specification to say how to do this in a correct and inoperable way, but might not violate the specification.  manet-fsr-00 seems like it has not been updated in quite a while.  FSR does not alter the "table scalability "; it's not claimed in the paper.

On Fri, Dec 19, 2008 at 12:58 AM, Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr> wrote:


On Thu, Dec 18, 2008 at 7:30 PM, Philip Levis <pal@cs.stanford.edu> wrote:
Comment inline.


On Dec 18, 2008, at 3:02 AM, Emmanuel Baccelli wrote:



On Wed, Dec 17, 2008 at 9:05 PM, Philip Levis <pal@cs.stanford.edu> wrote:

On Dec 17, 2008, at 9:04 AM, JP Vasseur wrote:


Now, let's try to be constructive and address your concerns.

1) Lack of background, context, ... in the document. Emmanuel is quite right that background is missing in the document as well as a clear conclusion: "how have we chosen the protocols in the survey, why protocols X, Y, Z, ... have not been included in the survey, ...". I saw that Phil agreed to add some text to address this issue.
Emmanuel, does that address your concern (to be confirmed once you see the text) ?
Phil, could you please propose some text ?

The OSPF section will be renamed OSPF/IS-IS and I will add supporting text that notes the distinctions between the two and why their analysis is the same.

I guess that's not all, right? I suppose there will be additional text justifying why the set of protocols (and not just OSPF/IS-IS) chosen to be evaluated is indeed a good sample of what is done in the IETF. Somewhere in this additional text, we also need some justification why DTN protocols are ignored and why there is not a word about NEMO-RO. I would rather recommend that one or two protocols such as PRoPHET (DTN protocol put forward by Stephen Farrell) be evaluated too, but if there is justification in the draft why not to do it, it would be OK I guess (at least with me). In any case, the goal of these additions would be to make the document both more self-contained and self-explanatory, while easier to relate with the content of the current charter.



Emmanuel, did you read the rest of my message? I address NEMO/DTN on point 2. Please acknowledge.


Here are some relevant pointers (non-exhaustive list):


They are in scope (NEMO space and DTN space) and they are describing routing protocols that may be of interest for ROLL.

If we just add the line you proposed, there will be no justification why they are not evaluated. Do you agree?

So we have a choice to make: either
(i) justify why such routing approaches are not in scope, or 
(ii) evaluate a couple of such protocols in the draft, so as to partially cover DTN and NEMO spaces, as the charter indicates. 

I suppose the latter wouldn't take so long? It's just a couple of additional paragraphs and a couple of additional lines in the pass/fail table, like for the protocols already evaluated in the draft... Do you agree?

Emmanuel




 



2) Missing protocols: we had to draw the line somewhere. *LOTS* of protocols have been proposed over the last decade. We had many suggestions to also look at protocol X, Y and Z. The decision was (according to our charter) to limit our survey to existing IETF protocols (RFC or very mature ID):  OSPF, OLSR, TBRPF, RIP, AODV, DYMO, DSR. The list is already fairly long. The charter mentions DTN. The WG decided not to include DTN and this needs to be documented.
Phil, could you please add some text ? Note that this does not mean that we may not borrow mechanism(s) from existing protocols by the way if we get re-chartered.

The current text reads:

"This document considers "existing routing protocols" to be protocols
that are specified in RFCs or, in the cases of DYMO
[I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very
mature draft which will most likely become an RFC."

I propose

"This document considers "existing routing protocols" to be routing protocols
that are specified in RFCs or, in the cases of DYMO
[I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very
mature draft which will most likely become an RFC. It does not
examine the Network Mobility Basic Support Protocol (NEMO)[cite],
DTN bundles[cite], or the DTN Licklider protocol[cite] because they
are not routing protocols."


Phil


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


------=_Part_31767_24856049.1229734257884-- --===============0889156309== 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 --===============0889156309==-- From roll-bounces@ietf.org Fri Dec 19 17:03:45 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C3913A6818; Fri, 19 Dec 2008 17:03:45 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C89B3A6818 for ; Fri, 19 Dec 2008 17:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4u8VJbv2BbI for ; Fri, 19 Dec 2008 17:03:43 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id AA82D3A677E for ; Fri, 19 Dec 2008 17:03:43 -0800 (PST) Received: from [76.14.71.180] (helo=[192.168.2.101]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1LDqFj-0000tY-QT; Fri, 19 Dec 2008 17:03:36 -0800 Message-Id: <51701811-D5A1-4167-96F5-CAADAA98FCF8@cs.stanford.edu> From: Philip Levis To: Emmanuel Baccelli In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 19 Dec 2008 17:03:34 -0800 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <3CEA849E-22CD-4DF1-A56B-E1C38572AA77@cisco.com> <6A3B39C4-8126-47D0-B29A-752191F4F487@cs.stanford.edu> <5467B083-1300-4723-9B5D-F45D6AED701B@thomasclausen.org> <260E044E-1C74-4C4D-9BF4-0A79E1A39177@cisco.com> <7F73D017-FBC6-4AB2-9359-78501D90825F@cs.stanford.edu> <2BD0AD28-7D65-4EE8-9D67-999E01671EB6@cs.stanford.edu> X-Mailer: Apple Mail (2.929.2) X-Scan-Signature: 3e263c829a24e9e508d860775f9d44fb Cc: ROLL WG Subject: Re: [Roll] Proposal so as to reach a consensus on ** draft-ietf-roll-protocols-survey-02 ** X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Dec 19, 2008, at 12:58 AM, Emmanuel Baccelli wrote: > > > Emmanuel, did you read the rest of my message? I address NEMO/DTN on > point 2. Please acknowledge. > > > Here are some relevant pointers (non-exhaustive list): > > http://tools.ietf.org/html/draft-irtf-dtnrg-prophet-01 This one doesn't fit the requirement of "mature draft." > http://tools.ietf.org/html/draft-thubert-tree-discovery-06 This is a multi-tunneling protocol across multiple in a nest NEMO environment. You're right, we should at least mention why this is not included. > > They are in scope (NEMO space and DTN space) and they are describing > routing protocols that may be of interest for ROLL. > > If we just add the line you proposed, there will be no justification > why they are not evaluated. Do you agree? > > So we have a choice to make: either > (i) justify why such routing approaches are not in scope, or > (ii) evaluate a couple of such protocols in the draft, so as to > partially cover DTN and NEMO spaces, as the charter indicates. > > I suppose the latter wouldn't take so long? It's just a couple of > additional paragraphs and a couple of additional lines in the pass/ > fail table, like for the protocols already evaluated in the draft... > Do you agree? > I agree that we need to say something more in depth about the above NEMO draft. Do you agree that the DTN one does not satisfy the requirement? Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Sat Dec 20 02:59:21 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CD8F3A6802; Sat, 20 Dec 2008 02:59:21 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6369F3A6802 for ; Sat, 20 Dec 2008 02:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNct2mGDnWNa for ; Sat, 20 Dec 2008 02:59:19 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 872E63A67FB for ; Sat, 20 Dec 2008 02:59:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,254,1228089600"; d="scan'208";a="29190860" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Dec 2008 10:59:07 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBKAx78h016669; Sat, 20 Dec 2008 11:59:07 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBKAx7FZ006240; Sat, 20 Dec 2008 10:59:07 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 20 Dec 2008 11:59:06 +0100 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 20 Dec 2008 11:59:06 +0100 Message-Id: From: JP Vasseur To: Philip Levis In-Reply-To: <51701811-D5A1-4167-96F5-CAADAA98FCF8@cs.stanford.edu> Mime-Version: 1.0 (Apple Message framework v926) Date: Sat, 20 Dec 2008 11:59:05 +0100 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <3CEA849E-22CD-4DF1-A56B-E1C38572AA77@cisco.com> <6A3B39C4-8126-47D0-B29A-752191F4F487@cs.stanford.edu> <5467B083-1300-4723-9B5D-F45D6AED701B@thomasclausen.org> <260E044E-1C74-4C4D-9BF4-0A79E1A39177@cisco.com> <7F73D017-FBC6-4AB2-9359-78501D90825F@cs.stanford.edu> <2BD0AD28-7D65-4EE8-9D67-999E01671EB6@cs.stanford.edu> <51701811-D5A1-4167-96F5-CAADAA98FCF8@cs.stanford.edu> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 20 Dec 2008 10:59:06.0349 (UTC) FILETIME=[FA2839D0:01C96291] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1851; t=1229770747; x=1230634747; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Proposal=20so=20as=20to=20reac h=20a=20consensus=20on=20**=20draft-ietf-roll-protocols-surv ey-02=20** |Sender:=20; bh=yjo5byOA/K8OYehk4XiOabXaAtgZ9Zbn5h+C51jPPLs=; b=YDuVOrvz0Ix8+zJpXIc1Lr1JbsdaQefJVZh0JiIa8TK+Qh56mvMkat0M5L mZpdx1LHEPSTl0tbWt9Uf7swlmUn6erNgcl0YfmZoIfK2a7KPQfSdAgXXyPm qfIY6EVGA9; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG Subject: Re: [Roll] Proposal so as to reach a consensus on ** draft-ietf-roll-protocols-survey-02 ** X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Dec 20, 2008, at 2:03 AM, Philip Levis wrote: > > On Dec 19, 2008, at 12:58 AM, Emmanuel Baccelli wrote: > >> >> >> Emmanuel, did you read the rest of my message? I address NEMO/DTN >> on point 2. Please acknowledge. >> >> >> Here are some relevant pointers (non-exhaustive list): >> >> http://tools.ietf.org/html/draft-irtf-dtnrg-prophet-01 > > This one doesn't fit the requirement of "mature draft." > >> http://tools.ietf.org/html/draft-thubert-tree-discovery-06 > > This is a multi-tunneling protocol across multiple in a nest NEMO > environment. You're right, we should at least mention why this is > not included. > > There are interesting mechanisms in this ID that we may end up using but again this is an individual submission. >> >> They are in scope (NEMO space and DTN space) and they are >> describing routing protocols that may be of interest for ROLL. > > > > >> >> If we just add the line you proposed, there will be no >> justification why they are not evaluated. Do you agree? >> >> So we have a choice to make: either >> (i) justify why such routing approaches are not in scope, or >> (ii) evaluate a couple of such protocols in the draft, so as to >> partially cover DTN and NEMO spaces, as the charter indicates. >> >> I suppose the latter wouldn't take so long? It's just a couple of >> additional paragraphs and a couple of additional lines in the pass/ >> fail table, like for the protocols already evaluated in the >> draft... Do you agree? >> > > I agree that we need to say something more in depth about the above > NEMO draft. Do you agree that the DTN one does not satisfy the > requirement? > > 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 Sun Dec 21 07:27:41 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CCEB3A69F1; Sun, 21 Dec 2008 07:27:41 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 338C13A69DA for ; Sun, 21 Dec 2008 07:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erz0prJlg8aT for ; Sun, 21 Dec 2008 07:27:07 -0800 (PST) Received: from ip2mx2.uwm.edu (ip2mx2.uwm.edu [129.89.7.80]) by core3.amsl.com (Postfix) with ESMTP id 58E0D3A681C for ; Sun, 21 Dec 2008 07:27:07 -0800 (PST) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mx2.uwm.edu with ESMTP; 21 Dec 2008 09:26:56 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 5F920C085C3; Sun, 21 Dec 2008 09:26:56 -0600 (CST) X-Virus-Scanned: amavisd-new at Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFkKOEBsnmQb; Sun, 21 Dec 2008 09:26:56 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 3AAB9C085C2; Sun, 21 Dec 2008 09:26:56 -0600 (CST) Date: Sun, 21 Dec 2008 09:26:56 -0600 (CST) From: Mukul Goyal To: roll@ietf.org Message-ID: <94335370.10252991229873216152.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <220026788.10252941229873112880.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.10_GA_2638.RHEL4_64 (ZimbraWebClient - IE7 (Win)/5.0.10_GA_2638.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] "Control cost" in Protocol survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi all, I have not gone through all the emails that have been sent recently (and earlier) regarding the protocol survey draft. So, it is possible that this issue has been raised before. I don't think the "control cost" criterion as described in section 4.4 of the draft is complete. The criterion, as described currently in this section, totally ignores the control packet overhead of the routing protocol during the "route discovery" process. So, a protocol like AODV that depends on network-wide broadcast of Route Request messages passes the "control cost" test! In LLNs, frequent route discoveries may be necessary given the dynamic nature of link/node quality. I think the text in section 4.4 should be modified to also include the cost of route discovery/maintenance. That would also make it necessary to re-evaluate the protocols from the perspective of "control cost" criterion. Thanks Mukul _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Sun Dec 21 10:47:08 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B99DB3A6984; Sun, 21 Dec 2008 10:47:08 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CED8C3A6984 for ; Sun, 21 Dec 2008 10:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yXCp+XLYrV8 for ; Sun, 21 Dec 2008 10:47:05 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id ADD3D3A679C for ; Sun, 21 Dec 2008 10:47:05 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so849729yxg.49 for ; Sun, 21 Dec 2008 10:46:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=akYRfSUgCOFdMlARPCfUE1pvzE7lxP9RwPZF37AwSbE=; b=ll9sZNG51aUce6i/Ns6tki35X+REkTIkUsx+ze9nOuL+Ajki1fvcyY83yfw+nQbd8K 1AiTAxq0i/WQZTYYJiqdrHYOMALMnDjpfTcL7PDNwyA4njHn9gAThTFaj6w9VXGQl7kf 9i+0UdHbOtJ3tgD02XieVBFE5AzhA/uaTpjQQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=bL9jE1ruLAdiCq/euEDGGNdMIEsW/RFIenArFoKSdIsKdaKM+UmiC9SuuPPI1x4T0f ME8FYjTb5rIaj1q706IxPapAfsNPpKBgyh9SxpGRGIAGz07TXOcNyyorHlGmdG3wVUlM Zgls+r1DA7k8sMtcM8HFJDgw4ucVRuNxc4Kmk= Received: by 10.100.92.2 with SMTP id p2mr3428011anb.52.1229885216087; Sun, 21 Dec 2008 10:46:56 -0800 (PST) Received: by 10.100.42.11 with HTTP; Sun, 21 Dec 2008 10:46:56 -0800 (PST) Message-ID: <44680fe70812211046i7dc1f52al542df7a62f7bfa34@mail.gmail.com> Date: Sun, 21 Dec 2008 10:46:56 -0800 From: "Stephen Dawson-Haggerty" To: "Mukul Goyal" In-Reply-To: <94335370.10252991229873216152.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 References: <220026788.10252941229873112880.JavaMail.root@mail02.pantherlink.uwm.edu> <94335370.10252991229873216152.JavaMail.root@mail02.pantherlink.uwm.edu> X-Google-Sender-Auth: a68e6c201f83616c Cc: roll@ietf.org Subject: Re: [Roll] "Control cost" in Protocol survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0606784479==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0606784479== Content-Type: multipart/alternative; boundary="----=_Part_41547_31480262.1229885216080" ------=_Part_41547_31480262.1229885216080 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Text which was added to the current version of the draft after discussions on the list: The control cost metric is a necessary but not sufficient condition for a protocol to be a viable routing protocol for LLNs. Protocols not meeting this bound are unacceptable for use in this environment; however, there may be protocols which receive a "pass" for this metric and yet are also unsuitable. The fact is, there are several reasons a protocol may pass the "control cost" metric and yet be unacceptable for use in LLNs; there has been significant discussion on this point recently (see emails between us and Christopher Dearlove). However, as defined, control cost is easy-to-explain, and if protocols *fail* it, they are clearly unacceptable. That's the property we're looking for. Thanks, Steve On Sun, Dec 21, 2008 at 7:26 AM, Mukul Goyal wrote: > Hi all, > > I have not gone through all the emails that have been sent recently (and > earlier) regarding the protocol survey draft. So, it is possible that this > issue has been raised before. > > I don't think the "control cost" criterion as described in section 4.4 of > the draft is complete. The criterion, as described currently in this > section, totally ignores the control packet overhead of the routing protocol > during the "route discovery" process. So, a protocol like AODV that depends > on network-wide broadcast of Route Request messages passes the "control > cost" test! In LLNs, frequent route discoveries may be necessary given the > dynamic nature of link/node quality. > > I think the text in section 4.4 should be modified to also include the cost > of route discovery/maintenance. That would also make it necessary to > re-evaluate the protocols from the perspective of "control cost" criterion. > > Thanks > Mukul > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > ------=_Part_41547_31480262.1229885216080 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Text which was added to the current version of the draft after discussions on the list:
   The control cost metric is a necessary but not sufficient condition
   for a protocol to be a viable routing protocol for LLNs.  Protocols
   not meeting this bound are unacceptable for use in this environment;
   however, there may be protocols which receive a "pass" for this
   metric and yet are also unsuitable.

The fact is, there are several reasons a protocol may pass the "control cost" metric and yet be unacceptable for use in LLNs; there has been significant discussion on this point recently (see emails between us and Christopher Dearlove).  However, as defined, control cost is easy-to-explain, and if protocols fail it, they are clearly unacceptable.  That's the property we're looking for.

Thanks,
Steve

On Sun, Dec 21, 2008 at 7:26 AM, Mukul Goyal <mukul@uwm.edu> wrote:
Hi all,

I have not gone through all the emails that have been sent recently (and earlier) regarding the protocol survey draft. So, it is possible that this issue has been raised before.

I don't think the "control cost" criterion as described in section 4.4 of the draft is complete. The criterion, as described currently in this section, totally ignores the control packet overhead of the routing protocol during the "route discovery" process. So, a protocol like AODV that depends on network-wide broadcast of Route Request messages passes the "control cost" test! In LLNs, frequent route discoveries may be necessary given the dynamic nature of link/node quality.

I think the text in section 4.4 should be modified to also include the cost of route discovery/maintenance. That would also make it necessary to re-evaluate the protocols from the perspective of "control cost" criterion.

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

------=_Part_41547_31480262.1229885216080-- --===============0606784479== 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 --===============0606784479==-- From roll-bounces@ietf.org Sun Dec 21 11:47:54 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAF513A69D0; Sun, 21 Dec 2008 11:47:54 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87AF53A69D0 for ; Sun, 21 Dec 2008 11:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+tydDbhP51x for ; Sun, 21 Dec 2008 11:47:52 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id D42983A6933 for ; Sun, 21 Dec 2008 11:47:52 -0800 (PST) Received: from [76.14.71.180] (helo=[192.168.2.103]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1LEUH9-0001st-Nc; Sun, 21 Dec 2008 11:47:43 -0800 In-Reply-To: <44680fe70812211046i7dc1f52al542df7a62f7bfa34@mail.gmail.com> References: <220026788.10252941229873112880.JavaMail.root@mail02.pantherlink.uwm.edu> <94335370.10252991229873216152.JavaMail.root@mail02.pantherlink.uwm.edu> <44680fe70812211046i7dc1f52al542df7a62f7bfa34@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Philip Levis Date: Sun, 21 Dec 2008 11:45:26 -0800 To: Stephen Dawson-Haggerty X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: 980022258218d8e0da9e8fd80fb6777b Cc: roll@ietf.org Subject: Re: [Roll] "Control cost" in Protocol survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Dec 21, 2008, at 10:46 AM, Stephen Dawson-Haggerty wrote: > Text which was added to the current version of the draft after > discussions on the list: > The control cost metric is a necessary but not sufficient condition > for a protocol to be a viable routing protocol for LLNs. Protocols > not meeting this bound are unacceptable for use in this > environment; > however, there may be protocols which receive a "pass" for this > metric and yet are also unsuitable. > > The fact is, there are several reasons a protocol may pass the > "control cost" metric and yet be unacceptable for use in LLNs; > there has been significant discussion on this point recently (see > emails between us and Christopher Dearlove). However, as defined, > control cost is easy-to-explain, and if protocols fail it, they are > clearly unacceptable. That's the property we're looking for. > > Thanks, > Steve Exactly; the control cost criterion, as defined, is necessary but not sufficient. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Dec 22 00:10:10 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 301BE3A6831; Mon, 22 Dec 2008 00:10:10 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CB763A67F4 for ; Mon, 22 Dec 2008 00:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvEIw7Rhwj2H for ; Mon, 22 Dec 2008 00:10:06 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.189]) by core3.amsl.com (Postfix) with ESMTP id E6C073A6846 for ; Mon, 22 Dec 2008 00:10:05 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id 18so1095598fkq.5 for ; Mon, 22 Dec 2008 00:09:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=oy+ReyoCryRxCUMQVBZqaQggs5zGTiZ0ESf7pIOAdDg=; b=nbkPCbRYODl8smw28YynFi6XA+36o/zc+BTwA+CoSY4Smtdb2h961Kuxzb+iNwP11P wWpOW6rT9LTAGoTEQJ7a6BwpbX9SUsRhKP/m/ahHrlPI4DrKEjkesK48B0V8liQHnEOB B+4MTQC+ffKAP4t/b2taoEj09s6pzaDyl6RIc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=KedAsePYc0wU/A9AJtFaNSi7s8e/DwwKuW2Dx9bWwI3Ftiorbet3RdO6zwuHlg0v0+ Udnujx7heHwAUGfUZwv/RirKmvq61/Gm0OzLShRJjjuAucUUl0e1fSjIIYmnquNsQMsn yOmbiVuduyVhmLp7ejTWiQe8EygH20j9z8aIQ= Received: by 10.103.226.20 with SMTP id d20mr2200429mur.8.1229933396777; Mon, 22 Dec 2008 00:09:56 -0800 (PST) Received: by 10.103.248.12 with HTTP; Mon, 22 Dec 2008 00:09:56 -0800 (PST) Message-ID: Date: Mon, 22 Dec 2008 09:09:56 +0100 From: "Emmanuel Baccelli" To: "ROLL WG" In-Reply-To: <44680fe70812191650r233e59c5r8cc652c617eaf989@mail.gmail.com> MIME-Version: 1.0 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <3CEA849E-22CD-4DF1-A56B-E1C38572AA77@cisco.com> <6A3B39C4-8126-47D0-B29A-752191F4F487@cs.stanford.edu> <5467B083-1300-4723-9B5D-F45D6AED701B@thomasclausen.org> <260E044E-1C74-4C4D-9BF4-0A79E1A39177@cisco.com> <7F73D017-FBC6-4AB2-9359-78501D90825F@cs.stanford.edu> <2BD0AD28-7D65-4EE8-9D67-999E01671EB6@cs.stanford.edu> <44680fe70812191650r233e59c5r8cc652c617eaf989@mail.gmail.com> X-Google-Sender-Auth: fcd0c5cc82e7cb9c Subject: Re: [Roll] Proposal so as to reach a consensus on ** draft-ietf-roll-protocols-survey-02 ** X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============1101770681==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1101770681== Content-Type: multipart/alternative; boundary="----=_Part_63654_13423084.1229933396764" ------=_Part_63654_13423084.1229933396764 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This sounds good to me.Emmanuel On Sat, Dec 20, 2008 at 1:50 AM, Stephen Dawson-Haggerty < stevedh@eecs.berkeley.edu> wrote: > Hi All, > We are making good progress at integrating all this discussion into the > next revision; however, there has been a lot of traffic and I want to make > sure we hit on everyone's comments. I've put below a preliminary changelog > for the document. These are only the major changes so far; there are others > which are more typographical and thus not listed. If you feel that I am > missing something which we discussed, please let me know either personally > or to the list. > > Thanks, > Steve > > - OSPF changed to OSPF/IS-IS, explain the distinctions and why the > analysis is the same > - Notes justifying why we don't look at NEMO/DTN (verbatim from JP, Phil) > since they're in the charter. > - Update the "control cost" metric: note that this metric is "necessary > but not sufficient" > - Be a more explicit about reqs and limitations in the intro. > - Update DYMO to talk about distance, not hopcount > - T. Clausen's long email (most should have been considered & addressed) > - OLSRv2 changed to ? in the control cost metric, because it might be > possible to pass with the right sort of aging of updates. ("Fisheye State > Routing in Mobile Ad Hoc Networks"). It would almost certainly require a > new specification to say how to do this in a correct and inoperable way, but > might not violate the specification. manet-fsr-00 seems like it has not > been updated in quite a while. FSR does not alter the "table scalability "; > it's not claimed in the paper. > > On Fri, Dec 19, 2008 at 12:58 AM, Emmanuel Baccelli < > Emmanuel.Baccelli@inria.fr> wrote: > >> >> >> On Thu, Dec 18, 2008 at 7:30 PM, Philip Levis wrote: >> >>> Comment inline. >>> >>> On Dec 18, 2008, at 3:02 AM, Emmanuel Baccelli wrote: >>> >>> >>>> >>>> On Wed, Dec 17, 2008 at 9:05 PM, Philip Levis >>>> wrote: >>>> >>>> On Dec 17, 2008, at 9:04 AM, JP Vasseur wrote: >>>> >>>> >>>> Now, let's try to be constructive and address your concerns. >>>> >>>> 1) Lack of background, context, ... in the document. Emmanuel is quite >>>> right that background is missing in the document as well as a clear >>>> conclusion: "how have we chosen the protocols in the survey, why protocols >>>> X, Y, Z, ... have not been included in the survey, ...". I saw that Phil >>>> agreed to add some text to address this issue. >>>> Emmanuel, does that address your concern (to be confirmed once you see >>>> the text) ? >>>> Phil, could you please propose some text ? >>>> >>>> The OSPF section will be renamed OSPF/IS-IS and I will add supporting >>>> text that notes the distinctions between the two and why their analysis is >>>> the same. >>>> >>>> I guess that's not all, right? I suppose there will be additional text >>>> justifying why the set of protocols (and not just OSPF/IS-IS) chosen to be >>>> evaluated is indeed a good sample of what is done in the IETF. Somewhere in >>>> this additional text, we also need some justification why DTN protocols are >>>> ignored and why there is not a word about NEMO-RO. I would rather recommend >>>> that one or two protocols such as PRoPHET (DTN protocol put forward by >>>> Stephen Farrell) be evaluated too, but if there is justification in the >>>> draft why not to do it, it would be OK I guess (at least with me). In any >>>> case, the goal of these additions would be to make the document both more >>>> self-contained and self-explanatory, while easier to relate with the content >>>> of the current charter. >>>> >>>> >>> >>> Emmanuel, did you read the rest of my message? I address NEMO/DTN on >>> point 2. Please acknowledge. >>> >> >> >> Here are some relevant pointers (non-exhaustive list): >> >> http://tools.ietf.org/html/draft-irtf-dtnrg-prophet-01 >> http://tools.ietf.org/html/draft-thubert-tree-discovery-06 >> >> They are in scope (NEMO space and DTN space) and they are describing >> routing protocols that may be of interest for ROLL. >> >> If we just add the line you proposed, there will be no justification why >> they are not evaluated. Do you agree? >> >> So we have a choice to make: either >> (i) justify why such routing approaches are not in scope, or >> (ii) evaluate a couple of such protocols in the draft, so as to partially >> cover DTN and NEMO spaces, as the charter indicates. >> >> I suppose the latter wouldn't take so long? It's just a couple of >> additional paragraphs and a couple of additional lines in the pass/fail >> table, like for the protocols already evaluated in the draft... Do you >> agree? >> >> Emmanuel >> >> >> >> >> >> >>> >>> >>> >>>> 2) Missing protocols: we had to draw the line somewhere. *LOTS* of >>>> protocols have been proposed over the last decade. We had many suggestions >>>> to also look at protocol X, Y and Z. The decision was (according to our >>>> charter) to limit our survey to existing IETF protocols (RFC or very mature >>>> ID): OSPF, OLSR, TBRPF, RIP, AODV, DYMO, DSR. The list is already fairly >>>> long. The charter mentions DTN. The WG decided not to include DTN and this >>>> needs to be documented. >>>> Phil, could you please add some text ? Note that this does not mean that >>>> we may not borrow mechanism(s) from existing protocols by the way if we get >>>> re-chartered. >>>> >>>> The current text reads: >>>> >>>> "This document considers "existing routing protocols" to be protocols >>>> that are specified in RFCs or, in the cases of DYMO >>>> [I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very >>>> mature draft which will most likely become an RFC." >>>> >>>> I propose >>>> >>>> "This document considers "existing routing protocols" to be routing >>>> protocols >>>> that are specified in RFCs or, in the cases of DYMO >>>> [I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very >>>> mature draft which will most likely become an RFC. It does not >>>> examine the Network Mobility Basic Support Protocol (NEMO)[cite], >>>> DTN bundles[cite], or the DTN Licklider protocol[cite] because they >>>> are not routing protocols." >>>> >>>> >>> Phil >>> >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> > ------=_Part_63654_13423084.1229933396764 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This sounds good to me.
Emmanuel

On Sat, Dec 20, 2008 at 1:50 AM, Stephen Dawson-Haggerty <stevedh@eecs.berkeley.edu> wrote:
Hi All,
We are making good progress at integrating all this discussion into the next revision; however, there has been a lot of traffic and I want to make sure we hit on everyone's comments.  I've put below a preliminary changelog for the document.  These are only the major changes so far; there are others which are more typographical and thus not listed.  If you feel that I am missing something which we discussed, please let me know either personally or to the list.

Thanks,
Steve

  - OSPF changed to OSPF/IS-IS, explain the distinctions and why the analysis is the same
  - Notes justifying why we don't look at NEMO/DTN (verbatim from JP, Phil) since they're in the charter.
  - Update the "control cost" metric: note that this metric is "necessary but not sufficient"
  - Be a more explicit about reqs and limitations in the intro.
  - Update DYMO to talk about distance, not hopcount
  - T. Clausen's long email (most should have been considered & addressed)
  - OLSRv2 changed to ? in the control cost metric, because it might be possible to pass with the right sort of aging of updates. ("Fisheye State Routing in Mobile Ad Hoc Networks").  It would almost certainly require a new specification to say how to do this in a correct and inoperable way, but might not violate the specification.  manet-fsr-00 seems like it has not been updated in quite a while.  FSR does not alter the "table scalability "; it's not claimed in the paper.

On Fri, Dec 19, 2008 at 12:58 AM, Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr> wrote:


On Thu, Dec 18, 2008 at 7:30 PM, Philip Levis <pal@cs.stanford.edu> wrote:
Comment inline.


On Dec 18, 2008, at 3:02 AM, Emmanuel Baccelli wrote:



On Wed, Dec 17, 2008 at 9:05 PM, Philip Levis <pal@cs.stanford.edu> wrote:

On Dec 17, 2008, at 9:04 AM, JP Vasseur wrote:


Now, let's try to be constructive and address your concerns.

1) Lack of background, context, ... in the document. Emmanuel is quite right that background is missing in the document as well as a clear conclusion: "how have we chosen the protocols in the survey, why protocols X, Y, Z, ... have not been included in the survey, ...". I saw that Phil agreed to add some text to address this issue.
Emmanuel, does that address your concern (to be confirmed once you see the text) ?
Phil, could you please propose some text ?

The OSPF section will be renamed OSPF/IS-IS and I will add supporting text that notes the distinctions between the two and why their analysis is the same.

I guess that's not all, right? I suppose there will be additional text justifying why the set of protocols (and not just OSPF/IS-IS) chosen to be evaluated is indeed a good sample of what is done in the IETF. Somewhere in this additional text, we also need some justification why DTN protocols are ignored and why there is not a word about NEMO-RO. I would rather recommend that one or two protocols such as PRoPHET (DTN protocol put forward by Stephen Farrell) be evaluated too, but if there is justification in the draft why not to do it, it would be OK I guess (at least with me). In any case, the goal of these additions would be to make the document both more self-contained and self-explanatory, while easier to relate with the content of the current charter.



Emmanuel, did you read the rest of my message? I address NEMO/DTN on point 2. Please acknowledge.


Here are some relevant pointers (non-exhaustive list):


They are in scope (NEMO space and DTN space) and they are describing routing protocols that may be of interest for ROLL.

If we just add the line you proposed, there will be no justification why they are not evaluated. Do you agree?

So we have a choice to make: either
(i) justify why such routing approaches are not in scope, or 
(ii) evaluate a couple of such protocols in the draft, so as to partially cover DTN and NEMO spaces, as the charter indicates. 

I suppose the latter wouldn't take so long? It's just a couple of additional paragraphs and a couple of additional lines in the pass/fail table, like for the protocols already evaluated in the draft... Do you agree?

Emmanuel




 



2) Missing protocols: we had to draw the line somewhere. *LOTS* of protocols have been proposed over the last decade. We had many suggestions to also look at protocol X, Y and Z. The decision was (according to our charter) to limit our survey to existing IETF protocols (RFC or very mature ID):  OSPF, OLSR, TBRPF, RIP, AODV, DYMO, DSR. The list is already fairly long. The charter mentions DTN. The WG decided not to include DTN and this needs to be documented.
Phil, could you please add some text ? Note that this does not mean that we may not borrow mechanism(s) from existing protocols by the way if we get re-chartered.

The current text reads:

"This document considers "existing routing protocols" to be protocols
that are specified in RFCs or, in the cases of DYMO
[I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very
mature draft which will most likely become an RFC."

I propose

"This document considers "existing routing protocols" to be routing protocols
that are specified in RFCs or, in the cases of DYMO
[I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very
mature draft which will most likely become an RFC. It does not
examine the Network Mobility Basic Support Protocol (NEMO)[cite],
DTN bundles[cite], or the DTN Licklider protocol[cite] because they
are not routing protocols."


Phil


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



------=_Part_63654_13423084.1229933396764-- --===============1101770681== 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 --===============1101770681==-- From roll-bounces@ietf.org Mon Dec 22 00:17:39 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4533D3A6831; Mon, 22 Dec 2008 00:17:39 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DE893A6828 for ; Mon, 22 Dec 2008 00:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUJqb+RpsP5E for ; Mon, 22 Dec 2008 00:17:37 -0800 (PST) Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by core3.amsl.com (Postfix) with ESMTP id 9E4233A6774 for ; Mon, 22 Dec 2008 00:17:36 -0800 (PST) Received: by fxm13 with SMTP id 13so468879fxm.13 for ; Mon, 22 Dec 2008 00:17:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=YkK7Dd9Lv86uBo4Ag9oI1czmerSrJj359hb5WkaYpHU=; b=jk56cCZ1rpC+CRWoNgxIdfxDFIX8dMbjwbPLuaDPjNTwKuB4UqbfPyQCWRxLzGM9FU GUSRksJk1AXp7uJ8SX1VriHXsk3QOFjrIJ1S8xGOM0b8j+BQ4Uad52Kkuqrswrj0tRwb qTOz6cG1sqZ1y6kM6RSZLszMefxRHnBVeUV5M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=pyG1BvIUhOYdR1p3DEQBBSip0AAF2dVFoqtZEQp/Nlrw6Rf2s7ecfmV2E54cub68ug eCciTqjo77okGRMaZcDRmHjlmx0Izy27D8eGaxWkvLyKJ0/7Kl0nuMBCsMXdmouoHC5v 2HVtvo2C5WG6Noo9o6og4XESXiui1H8c+SjpY= Received: by 10.103.220.18 with SMTP id x18mr2198343muq.38.1229933846712; Mon, 22 Dec 2008 00:17:26 -0800 (PST) Received: by 10.103.248.12 with HTTP; Mon, 22 Dec 2008 00:17:26 -0800 (PST) Message-ID: Date: Mon, 22 Dec 2008 09:17:26 +0100 From: "Emmanuel Baccelli" To: "ROLL WG" In-Reply-To: MIME-Version: 1.0 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <6A3B39C4-8126-47D0-B29A-752191F4F487@cs.stanford.edu> <5467B083-1300-4723-9B5D-F45D6AED701B@thomasclausen.org> <260E044E-1C74-4C4D-9BF4-0A79E1A39177@cisco.com> <7F73D017-FBC6-4AB2-9359-78501D90825F@cs.stanford.edu> <2BD0AD28-7D65-4EE8-9D67-999E01671EB6@cs.stanford.edu> <51701811-D5A1-4167-96F5-CAADAA98FCF8@cs.stanford.edu> X-Google-Sender-Auth: 9c18bc532a22b6b4 Subject: Re: [Roll] Proposal so as to reach a consensus on ** draft-ietf-roll-protocols-survey-02 ** X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============0314695434==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0314695434== Content-Type: multipart/alternative; boundary="----=_Part_63729_22309959.1229933846704" ------=_Part_63729_22309959.1229933846704 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sat, Dec 20, 2008 at 11:59 AM, JP Vasseur wrote: > > On Dec 20, 2008, at 2:03 AM, Philip Levis wrote: > > >> On Dec 19, 2008, at 12:58 AM, Emmanuel Baccelli wrote: >> >> >>> >>> Emmanuel, did you read the rest of my message? I address NEMO/DTN on >>> point 2. Please acknowledge. >>> >>> >>> Here are some relevant pointers (non-exhaustive list): >>> >>> http://tools.ietf.org/html/draft-irtf-dtnrg-prophet-01 >>> >> >> This one doesn't fit the requirement of "mature draft." > > On what do you base this judgement? Are there any such drafts in DTN that are mature enough? If indeed nothing was mature enough, then DTN would not have been mentioned in the charter. Anyways, do you agree that saying "we don't do DTN because there are no DTN routing protocols" is not quite enough? > >> >> http://tools.ietf.org/html/draft-thubert-tree-discovery-06 >>> >> >> This is a multi-tunneling protocol across multiple in a nest NEMO >> environment. You're right, we should at least mention why this is not >> included. >> >> >> > There are interesting mechanisms in this ID that we may end up using but > again this is an individual submission. > I do not see why this is an issue. I think that NEMO is mentioned in the charter because of such RO drafts. Maybe what could be done is add a section that would briefly address/evaluate this NEMO approach and one DTN approach, as side matters that may in fact matter ;) Emmanuel > > > >>> They are in scope (NEMO space and DTN space) and they are describing >>> routing protocols that may be of interest for ROLL. >>> >> >> >> >> >> >>> If we just add the line you proposed, there will be no justification why >>> they are not evaluated. Do you agree? >>> >>> So we have a choice to make: either >>> (i) justify why such routing approaches are not in scope, or >>> (ii) evaluate a couple of such protocols in the draft, so as to partially >>> cover DTN and NEMO spaces, as the charter indicates. >>> >>> I suppose the latter wouldn't take so long? It's just a couple of >>> additional paragraphs and a couple of additional lines in the pass/fail >>> table, like for the protocols already evaluated in the draft... Do you >>> agree? >>> >>> >> I agree that we need to say something more in depth about the above NEMO >> draft. Do you agree that the DTN one does not satisfy the requirement? >> >> Phil >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > > ------=_Part_63729_22309959.1229933846704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Sat, Dec 20, 2008 at 11:59 AM, JP Vasseur <jvasseur@cisco.com> wrote:

On Dec 20, 2008, at 2:03 AM, Philip Levis wrote:


On Dec 19, 2008, at 12:58 AM, Emmanuel Baccelli wrote:



Emmanuel, did you read the rest of my message? I address NEMO/DTN on point 2. Please acknowledge.


Here are some relevant pointers (non-exhaustive list):

http://tools.ietf.org/html/draft-irtf-dtnrg-prophet-01

This one doesn't fit the requirement of "mature draft."

On what do you base this judgement? Are there any such drafts in DTN that are mature enough?  If indeed nothing was mature enough, then DTN would not have been mentioned in the charter. Anyways, do you agree that saying "we don't do DTN because there are no DTN routing protocols" is not quite enough?


 


http://tools.ietf.org/html/draft-thubert-tree-discovery-06

This is a multi-tunneling protocol across multiple in a nest NEMO environment. You're right, we should at least mention why this is not included.



There are interesting mechanisms in this ID that we may end up using but again this is an individual submission.

I do not see why this is an issue. I think that NEMO is mentioned in the charter because of such RO drafts. Maybe what could be done is add a section that would briefly address/evaluate this NEMO approach and one DTN approach, as side matters that may in fact matter ;)

Emmanuel

 



They are in scope (NEMO space and DTN space) and they are describing routing protocols that may be of interest for ROLL.





If we just add the line you proposed, there will be no justification why they are not evaluated. Do you agree?

So we have a choice to make: either
(i) justify why such routing approaches are not in scope, or
(ii) evaluate a couple of such protocols in the draft, so as to partially cover DTN and NEMO spaces, as the charter indicates.

I suppose the latter wouldn't take so long? It's just a couple of additional paragraphs and a couple of additional lines in the pass/fail table, like for the protocols already evaluated in the draft... Do you agree?


I agree that we need to say something more in depth about the above NEMO draft. Do you agree that the DTN one does not satisfy the requirement?

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


------=_Part_63729_22309959.1229933846704-- --===============0314695434== 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 --===============0314695434==-- From roll-bounces@ietf.org Mon Dec 29 14:10:25 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD97F3A677C; Mon, 29 Dec 2008 14:10:25 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC6203A677C for ; Mon, 29 Dec 2008 14:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpMGD3aNtTdQ for ; Mon, 29 Dec 2008 14:10:21 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id E48E93A6452 for ; Mon, 29 Dec 2008 14:10:21 -0800 (PST) Received: from [76.14.71.180] (helo=[192.168.2.101]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1LHQJP-0003yI-5l; Mon, 29 Dec 2008 14:10:11 -0800 Message-Id: <5851ED61-5159-4469-9E89-59496F5021C5@cs.stanford.edu> From: Philip Levis To: Emmanuel Baccelli In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 29 Dec 2008 14:10:10 -0800 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <6A3B39C4-8126-47D0-B29A-752191F4F487@cs.stanford.edu> <5467B083-1300-4723-9B5D-F45D6AED701B@thomasclausen.org> <260E044E-1C74-4C4D-9BF4-0A79E1A39177@cisco.com> <7F73D017-FBC6-4AB2-9359-78501D90825F@cs.stanford.edu> <2BD0AD28-7D65-4EE8-9D67-999E01671EB6@cs.stanford.edu> <51701811-D5A1-4167-96F5-CAADAA98FCF8@cs.stanford.edu> X-Mailer: Apple Mail (2.929.2) X-Scan-Signature: 72f97ea9660f372cf635c7c250d627db Cc: ROLL WG Subject: Re: [Roll] Proposal so as to reach a consensus on ** draft-ietf-roll-protocols-survey-02 ** X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Dec 22, 2008, at 12:17 AM, Emmanuel Baccelli wrote: > > On what do you base this judgement? Are there any such drafts in DTN > that are mature enough? If indeed nothing was mature enough, then > DTN would not have been mentioned in the charter. Anyways, do you > agree that saying "we don't do DTN because there are no DTN routing > protocols" is not quite enough? Emmanuel, The judgement basically was "RFCs except for these two MANET drafts that are evolutions of prior MANET protocols that have RFCs." OLSRv2 and DYMO had both gone through many revisions, and so the call was that they were likely to be stable enough that the analysis based on a draft would not change significantly by the time the drafts become RFCs. The charter doesn't say that all of these protocols will be evaluated in a table. Rather, it reads: "Survey the applicability of existing protocols to LLNs. The aim of this document will be to analyze the scaling and characteristics of existing protocols and identify whether or not they meet the routing requirements of the applications identified above. Existing IGPs, MANET, NEMO, DTN routing protocols will be part of evaluation." I think the key sentence there is "analyze the scaling and characteristics of existing protocols and identify whether or not they meet the routing requirements of the applications identified above" If a protocol is not a routing protocol, then it can't meet the routing requirements. At the time the charter was written, this close examination of NEMO and DTN had not yet occurred. In the process of writing the draft, we as a working group examined the relevant documents and found that their abstractions did not meet the needs of ROLL. We could try to force other kinds of protocols into a table designed for routing protocols, but that seems problematic and misleading. It was important that we look broadly when considering what might work for ROLL, but casting such a wide net meant there were some protocols that were really a bit out of scope. I absolutely agree that the next revision needs to clearly state this reasoning, so that the document is transparent. We're working on fixing that. Do you agree with the reasoning? Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Dec 30 14:05:20 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFA093A69A0; Tue, 30 Dec 2008 14:05:20 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86A5F28C27A for ; Tue, 30 Dec 2008 14:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMcEhHm3ZxhF for ; Tue, 30 Dec 2008 14:05:19 -0800 (PST) Received: from usstuh502.johnsondiversey.com (mail4.johnsondiversey.com [208.251.229.31]) by core3.amsl.com (Postfix) with ESMTP id CD9E23A6403 for ; Tue, 30 Dec 2008 14:05:18 -0800 (PST) From: david.bruemmer@johnsondiversey.com To: roll@ietf.org Message-ID: Date: Tue, 30 Dec 2008 16:04:35 -0600 X-MIMETrack: Serialize by Router on USSTUH502/SVR/CMI(Release 7.0.3FP1|February 24, 2008) at 12/30/2008 16:05:08 MIME-Version: 1.0 Subject: [Roll] David Bruemmer is out of the office. X-BeenThere: roll@ietf.org X-Mailman-Version: 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 will be out of the office starting 12/24/2008 and will not return until 01/02/2009. I will respond to your message when I return. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Dec 31 02:24:32 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 613D03A68F2; Wed, 31 Dec 2008 02:24:32 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 483FF3A68F2 for ; Wed, 31 Dec 2008 02:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.931 X-Spam-Level: X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRJMyy041L00 for ; Wed, 31 Dec 2008 02:24:30 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id EB8763A67F3 for ; Wed, 31 Dec 2008 02:24:29 -0800 (PST) Received: by bwz14 with SMTP id 14so18274246bwz.13 for ; Wed, 31 Dec 2008 02:24:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=Hs8sXzDMvnL+eVYWsdq5LMbtITHccZRs5849jGaTGdU=; b=ogPC+lZ3IiyEhxaVYXvbPdjvV47Pwc6wza7S7aTWiPhiDH7r5gut5ZhpmlCAPmAfF9 82pwL+ywkfmhY3SBBZD5fH+DC+qgInwTR7pDDYKDC0WUijIw2dL/6O5/UofKLbZbSK/S FlXwd0UD5DKUZ877UkSin04/P+PL0QKvtKbnY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=GiB4+TnEsvr+LXQdryp885N9CvPKybu87Llt8+YfZ5VHe78xQAVgj/ND0gSRjHj2Rm 14DNGh26XvRLX6TxlRKQ2NDjPZd2l4nVCzQYlt8NO4XoIjo07IXZQhWSHKu82GTJu8cH gmWyCz66ykByNU1hAwMOr+AVGClLAiRCfYj7U= Received: by 10.103.1.5 with SMTP id d5mr5653132mui.29.1230719056980; Wed, 31 Dec 2008 02:24:16 -0800 (PST) Received: by 10.103.241.1 with HTTP; Wed, 31 Dec 2008 02:24:16 -0800 (PST) Message-ID: Date: Wed, 31 Dec 2008 11:24:16 +0100 From: "Emmanuel Baccelli" To: "ROLL WG" In-Reply-To: <5851ED61-5159-4469-9E89-59496F5021C5@cs.stanford.edu> MIME-Version: 1.0 References: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> <260E044E-1C74-4C4D-9BF4-0A79E1A39177@cisco.com> <7F73D017-FBC6-4AB2-9359-78501D90825F@cs.stanford.edu> <2BD0AD28-7D65-4EE8-9D67-999E01671EB6@cs.stanford.edu> <51701811-D5A1-4167-96F5-CAADAA98FCF8@cs.stanford.edu> <5851ED61-5159-4469-9E89-59496F5021C5@cs.stanford.edu> X-Google-Sender-Auth: 39c678ea18e283b0 Subject: Re: [Roll] Proposal so as to reach a consensus on ** draft-ietf-roll-protocols-survey-02 ** X-BeenThere: roll@ietf.org X-Mailman-Version: 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="===============0025831826==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0025831826== Content-Type: multipart/alternative; boundary="----=_Part_156081_30592526.1230719056967" ------=_Part_156081_30592526.1230719056967 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, Dec 29, 2008 at 11:10 PM, Philip Levis wrote: > > On Dec 22, 2008, at 12:17 AM, Emmanuel Baccelli wrote: > > "analyze the scaling and characteristics of > existing protocols and identify whether or not they meet the routing > requirements of the applications identified above" > > If a protocol is not a routing protocol, then it can't meet the routing > requirements. Let's look at one example I was pointing to, the beginning of the abstract of http://tools.ietf.org/html/draft-thubert-tree-discovery-06 which reads: "This paper describes a simple distance vector protocol that exposes only a default route towards the infrastructure in a nested NEMO configuration." if this is not a routing protocol, what is it? If this is not in scope, then I wonder what is. By the way, I'm sure you'll agree that it makes more sense to evaluate this than to evaluate OSPF, in the context of ROLL... Maybe the next version of the draft will contain a convincing explanation for these choices, but for now, I must say it still eludes me. Emmanuel ------=_Part_156081_30592526.1230719056967 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Mon, Dec 29, 2008 at 11:10 PM, Philip Levis <pal@cs.stanford.edu> wrote:

On Dec 22, 2008, at 12:17 AM, Emmanuel Baccelli wrote:

"analyze the scaling and characteristics of
existing protocols and identify whether or not they meet the routing
requirements of the applications identified above"

If a protocol is not a routing protocol, then it can't meet the routing requirements.


Let's look at one example I was pointing to, the beginning of the abstract of http://tools.ietf.org/html/draft-thubert-tree-discovery-06 which reads:

"This paper describes a simple distance vector protocol that exposes
only a default route towards the infrastructure in a nested NEMO 
configuration."

if this is not a routing protocol, what is it? If this is not in scope, then I wonder what is. 

By the way, I'm sure you'll agree that it makes more sense to evaluate this than to evaluate OSPF, in the context of ROLL... 

Maybe the next version of the draft will contain a convincing explanation for these choices, but for now, I must say it still eludes me.

Emmanuel


------=_Part_156081_30592526.1230719056967-- --===============0025831826== 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 --===============0025831826==--