From zahariad@teihal.gr Mon Aug 1 23:55:43 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08A011E80B7 for ; Mon, 1 Aug 2011 23:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1dNitn34lWl for ; Mon, 1 Aug 2011 23:55:42 -0700 (PDT) Received: from echidna.otenet.gr (echidna.otenet.gr [83.235.69.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3803611E8071 for ; Mon, 1 Aug 2011 23:55:42 -0700 (PDT) Received: from aiolos.otenet.gr (aiolos.otenet.gr [83.235.67.30]) by echidna.otenet.gr (ESMTP) with ESMTP; Tue, 2 Aug 2011 09:55:41 +0300 (EEST) Received: from acer (ppp-94-66-41-207.home.otenet.gr [94.66.41.207]) by aiolos.otenet.gr (8.13.8/8.13.8/Debian-3) with ESMTP id p726tdXu004878; Tue, 2 Aug 2011 09:55:43 +0300 From: "Theodore Zahariadis" To: Date: Tue, 2 Aug 2011 09:55:40 +0300 Organization: TEI of Chalkidas Message-ID: <006301cc50e1$334a41f0$99dec5d0$@gr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Content-language: el Thread-index: AcxQVAedM6RErpezTPuJoGGmovea8gAAJMbQACKz+6A= Cc: TRAKADAS PANOS Subject: [Roll] FW: New I-D on composite routing metrics X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zahariad@teihal.gr List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 06:55:43 -0000 Dear all, My colleague Dr. Panos Trakadas and myself are working on an EC-funded research project, called VITRO (Virtualized Distributed platform of = Smart objects - http://www.vitro-fp7.eu/), which has adopted RPL as the = primary routing protocol and we are currently performing some simulations and = tests. By monitoring roll, we have noticed that three (sorry if we have missed = any) I-D are discussed in the ROLL WG (draft-ietf-roll-minrank-hysteresis-of, draft-ietf-roll-of0, draft-gnawali-roll-etxof), defining RPL Objective Functions related to a single routing metric (either hop-count or ETX). In VITRO, each sensor may be part of many virtual networks (even from different administrative domains) and must be able to concurrently = support multiple user requests even with contradicting QoS characteristics. It = is obvious that in=A0such cases, a composite routing metric is of great importance. In draft-zahariadis-roll-metrics-composition-00 (http://datatracker.ietf.org/doc/draft-zahariadis-roll-metrics-compositio= n/) , we aim at specifying the guidelines for designing efficient composite routing metrics to be applied at RPL routing protocol. =A0 We would be happy to receive your comments =A0 Best Regards, Theodore Zahariadis ------------------------------------ Ass. Prof. Theodore Zahariadis, PhD Technological Educational Institute of Chalkida Psachna, Chalkida, Greece Tel: +30 22280 99550, +30 6932495045 Skype: theodore.zahariadis From pthubert@cisco.com Wed Aug 3 03:32:54 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C9A21F87D9 for ; Wed, 3 Aug 2011 03:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.461 X-Spam-Level: X-Spam-Status: No, score=-10.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+Pl5SlINeUT for ; Wed, 3 Aug 2011 03:32:53 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 218A821F877B for ; Wed, 3 Aug 2011 03:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2594; q=dns/txt; s=iport; t=1312367585; x=1313577185; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=RhgT2wQt/BwayBruNFti6GFrPjBVtKhN7iytlglSAOY=; b=YOSdpagOkA4ZLM9BKCR0GC+4OQeG6yfo+mvjMXkQ9iYbwrYv3h7O8j6G 3e5W37kr1ViUcuBJybxA0hkxrbZKDsVQi3p3i7WZkCE2qXGCwRanFfvkx 1d+qbIjXPyTbIgrgyFAo80CKryHMCJtUhgPu/M8I6Atz1y6AAM/pDFx2v E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucAABMjOU6Q/khR/2dsb2JhbABCmAWPVneBQAEBAQEDAQEBDwEdPgsMBAIBCBEEAQELBhcBBgEmHwgBBQMBAQQBEggah06gSAGeYIVjXwSHK5Bgi1Y X-IronPort-AV: E=Sophos;i="4.67,309,1309737600"; d="scan'208";a="106455311" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 03 Aug 2011 10:33:03 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p73AX09R016464; Wed, 3 Aug 2011 10:33:00 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Aug 2011 12:33:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Aug 2011 12:32:57 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D053A30DC@XMB-AMS-107.cisco.com> In-Reply-To: <006301cc50e1$334a41f0$99dec5d0$@gr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] FW: New I-D on composite routing metrics Thread-Index: AcxQVAedM6RErpezTPuJoGGmovea8gAAJMbQACKz+6AAOi9/kA== References: <006301cc50e1$334a41f0$99dec5d0$@gr> From: "Pascal Thubert (pthubert)" To: , X-OriginalArrivalTime: 03 Aug 2011 10:33:00.0636 (UTC) FILETIME=[B7D461C0:01CC51C8] Cc: TRAKADAS PANOS Subject: Re: [Roll] FW: New I-D on composite routing metrics X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 10:32:54 -0000 Hi Theodore: I'm curious here: you did not explain why you have to build a single = instance with composite metric as opposed to multiple instances each = optimized for a certain flow. In any fashion, you're correct, the OF framework is designed to allow = you to have a mission specific logic with multiple criteria. We expect, = though, that each metric you need is propagated separately and is not = polluted by other metrics. Only the Rank mixes things together, and it = is your OF's responsibility to define how that happens... Cheers; Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of > Theodore Zahariadis > Sent: Tuesday, August 02, 2011 8:56 AM > To: roll@ietf.org > Cc: TRAKADAS PANOS > Subject: [Roll] FW: New I-D on composite routing metrics >=20 > Dear all, > My colleague Dr. Panos Trakadas and myself are working on an EC-funded > research project, called VITRO (Virtualized Distributed platform of = Smart > objects - http://www.vitro-fp7.eu/), which has adopted RPL as the = primary > routing protocol and we are currently performing some simulations and > tests. >=20 > By monitoring roll, we have noticed that three (sorry if we have = missed any) > I-D are discussed in the ROLL WG = (draft-ietf-roll-minrank-hysteresis-of, > draft-ietf-roll-of0, draft-gnawali-roll-etxof), defining RPL Objective > Functions related to a single routing metric (either hop-count or = ETX). >=20 > In VITRO, each sensor may be part of many virtual networks (even from > different administrative domains) and must be able to concurrently = support > multiple user requests even with contradicting QoS characteristics. It = is > obvious that in=A0such cases, a composite routing metric is of great > importance. >=20 > In draft-zahariadis-roll-metrics-composition-00 > = (http://datatracker.ietf.org/doc/draft-zahariadis-roll-metrics-compositio= n/) > , we aim at specifying the guidelines for designing efficient = composite > routing metrics to be applied at RPL routing protocol. >=20 > We would be happy to receive your comments >=20 > Best Regards, > Theodore Zahariadis >=20 >=20 > ------------------------------------ > Ass. Prof. Theodore Zahariadis, PhD > Technological Educational Institute of Chalkida > Psachna, Chalkida, Greece > Tel: +30 22280 99550, +30 6932495045 > Skype: theodore.zahariadis >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From c.chauvenet@watteco.com Wed Aug 3 08:49:06 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F4721F8B20 for ; Wed, 3 Aug 2011 08:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9dIQl6WajKV for ; Wed, 3 Aug 2011 08:49:05 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id B8F8721F8906 for ; Wed, 3 Aug 2011 08:49:04 -0700 (PDT) Received: from mail117-ch1-R.bigfish.com (216.32.181.171) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.22; Wed, 3 Aug 2011 15:49:15 +0000 Received: from mail117-ch1 (localhost.localdomain [127.0.0.1]) by mail117-ch1-R.bigfish.com (Postfix) with ESMTP id A2BFA9A02BF; Wed, 3 Aug 2011 15:49:15 +0000 (UTC) X-SpamScore: -26 X-BigFish: VPS-26(zzc89bh1432Nzz1202hzz1033IL8275dhz2dh2a8h668h839h8aah61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:213.199.187.153; KIP:(null); UIP:(null); IPVD:NLI; SRV:BULK; H:IE2RD2HUB004.red002.local; RD:none; EFVD:NLI Received: from mail117-ch1 (localhost.localdomain [127.0.0.1]) by mail117-ch1 (MessageSwitch) id 1312386533689156_7104; Wed, 3 Aug 2011 15:48:53 +0000 (UTC) Received: from CH1EHSMHS015.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail117-ch1.bigfish.com (Postfix) with ESMTP id BE1F96E80BE; Wed, 3 Aug 2011 15:47:13 +0000 (UTC) Received: from IE2RD2HUB004.red002.local (213.199.187.153) by CH1EHSMHS015.bigfish.com (10.43.70.15) with Microsoft SMTP Server (TLS) id 14.1.225.22; Wed, 3 Aug 2011 15:47:11 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.55]) by IE2RD2HUB004.red002.local ([10.33.16.64]) with mapi; Wed, 3 Aug 2011 08:46:38 -0700 From: C Chauvenet To: "zahariad@teihal.gr" Date: Wed, 3 Aug 2011 08:46:35 -0700 Thread-Topic: [Roll] FW: New I-D on composite routing metrics Thread-Index: AcxR9IcK3URb3biPRRaGZ7OlSXVgwA== Message-ID: References: <006301cc50e1$334a41f0$99dec5d0$@gr> In-Reply-To: <006301cc50e1$334a41f0$99dec5d0$@gr> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: TRAKADAS PANOS , "roll@ietf.org" Subject: Re: [Roll] FW: New I-D on composite routing metrics X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 15:49:06 -0000 Hi Theodore,=20 I found your draft interesting and it gave me some useful guidelines for me= tric's design. I've several comments on this :=20 I fail to understand well the "Order Relation" you use in Table 1. The definition of "metric order relation" given on page 4 doesn't really he= lped me. Could you help me understand the Order Relation column in the table? In this table in particular (Figure 1):=20 - Could you precise your view of the Link-Color metric (Why is it in the = integer domain, why the order relation in "minimum" ?). - As far as I understand the Order Relation, it seems that the LQL order r= elation should not be "maximum" but rather "minimum" (same relation as ETX,= excluding the 0 value). More generally, I would be happy to see in the document some formulas examp= les for metric computation, or maybe some guidelines. Some example of metrics composition would also be great (You mention one in= your draft with is ETX + RE (remainging Energy). Do you have some idea abo= ut other set of metric that would be interesting to bind ? I finally think that it should be worth to add some content about the mecha= nisms that aim to deal with metric's dynamics (Multi Threshold, EWMA, Low p= ass Filters, ...). Some of them are mentioned at the end of the rpl metric = draft. Best, C=E9dric. Le 2 ao=FBt 2011 =E0 02:55, Theodore Zahariadis a =E9crit : > Dear all, > My colleague Dr. Panos Trakadas and myself are working on an EC-funded > research project, called VITRO (Virtualized Distributed platform of Smart > objects - http://www.vitro-fp7.eu/), which has adopted RPL as the primary > routing protocol and we are currently performing some simulations and tes= ts. >=20 > By monitoring roll, we have noticed that three (sorry if we have missed a= ny) > I-D are discussed in the ROLL WG (draft-ietf-roll-minrank-hysteresis-of, > draft-ietf-roll-of0, draft-gnawali-roll-etxof), defining RPL Objective > Functions related to a single routing metric (either hop-count or ETX). >=20 > In VITRO, each sensor may be part of many virtual networks (even from > different administrative domains) and must be able to concurrently suppor= t > multiple user requests even with contradicting QoS characteristics. It is > obvious that in such cases, a composite routing metric is of great > importance. >=20 > In draft-zahariadis-roll-metrics-composition-00 > (http://datatracker.ietf.org/doc/draft-zahariadis-roll-metrics-compositio= n/) > , we aim at specifying the guidelines for designing efficient composite > routing metrics to be applied at RPL routing protocol. > =20 > We would be happy to receive your comments > =20 > Best Regards, > Theodore Zahariadis >=20 >=20 > ------------------------------------ > Ass. Prof. Theodore Zahariadis, PhD > Technological Educational Institute of Chalkida > Psachna, Chalkida, Greece > Tel: +30 22280 99550, +30 6932495045 > Skype: theodore.zahariadis >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From culler@EECS.Berkeley.EDU Wed Aug 3 09:26:10 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06EFA21F8B2E for ; Wed, 3 Aug 2011 09:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.607 X-Spam-Level: X-Spam-Status: No, score=-5.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyFdqY1lDpI0 for ; Wed, 3 Aug 2011 09:26:09 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0B721F8AF1 for ; Wed, 3 Aug 2011 09:26:09 -0700 (PDT) Received: from [192.168.2.103] (64-142-4-199.dsl.static.sonic.net [64.142.4.199]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.5/8.13.5) with ESMTP id p73GP0mH009235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Aug 2011 09:26:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: David Culler In-Reply-To: Date: Tue, 2 Aug 2011 19:00:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4EA5EBD5-17B9-4AF7-913D-D0D8C6577033@EECS.Berkeley.EDU> References: To: Ulrich Herberg X-Mailer: Apple Mail (2.1084) Cc: roll WG Subject: Re: [Roll] Intended status of draft-ietf-roll-applicability-ami-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 16:26:10 -0000 A very good question. I would think applicability statements would in = general be informational. =20 On Jul 29, 2011, at 2:54 PM, Ulrich Herberg wrote: > Hi, >=20 > is the intended status of draft-ietf-roll-applicability-ami-01 really = Standards Track? Or should it be informational? >=20 > Regards > Ulrich > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From zahariad@teihal.gr Wed Aug 3 23:49:17 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4541911E80E8 for ; Wed, 3 Aug 2011 23:49:17 -0700 (PDT) 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_22=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkFA2qeg1lwq for ; Wed, 3 Aug 2011 23:49:16 -0700 (PDT) Received: from chimaera.otenet.gr (chimaera.otenet.gr [83.235.69.15]) by ietfa.amsl.com (Postfix) with ESMTP id DBD3711E80F2 for ; Wed, 3 Aug 2011 23:49:15 -0700 (PDT) Received: from dionisos.otenet.gr (dionisos.otenet.gr [83.235.67.28]) by chimaera.otenet.gr (ESMTP) with ESMTPS; Thu, 4 Aug 2011 09:49:24 +0300 (EEST) Received: from acer (ppp-94-66-67-163.home.otenet.gr [94.66.67.163]) by dionisos.otenet.gr (8.13.8/8.13.8) with ESMTP id p746nMUq031027; Thu, 4 Aug 2011 09:49:25 +0300 From: "Theodore Zahariadis" To: "'Pascal Thubert \(pthubert\)'" , References: <006301cc50e1$334a41f0$99dec5d0$@gr> <6A2A459175DABE4BB11DE2026AA50A5D053A30DC@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D053A30DC@XMB-AMS-107.cisco.com> Date: Thu, 4 Aug 2011 09:49:24 +0300 Organization: TEI of Chalkidas Message-ID: <006201cc5272$a7b4dfe0$f71e9fa0$@gr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Content-language: el Thread-index: AcxQVAedM6RErpezTPuJoGGmovea8gAAJMbQACKz+6AAOi9/kAAqI4Yg Cc: 'TRAKADAS PANOS' Subject: Re: [Roll] FW: New I-D on composite routing metrics X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zahariad@teihal.gr List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 06:49:17 -0000 Hi Pascal, Thanks for your comments! Probably our email caused a misunderstanding. It is not a matter of = single or multiple instances. Our draft tries to analyze and provide guidelines = on the design of proper OF's dealing with more than one routing metrics, propagated separately and not polluted by other metrics, as you = correctly mentioned in your email. For example: Consider the case where the construction of a DODAG is based on two = routing metrics, namely Hop-Count (HC) and link reliability (LR) (the same also holds for e.g. the pair of ETX and link-color), carried separately = within DAG Metric Container Object of the DIO message. HC is aggregated along = the path (C=3D0, O=3D0, A=3D0x00, R=3D0), while the LR is recorded along the = path (C=3D0, O=3D0, A=3D0x02, R=3D1).Furthermore, consider that node A receives DIO = messages from nodes B and C (being potential parents of node A). The pair of (HC, = LR) values advertized by nodes B and C are (3, 4) and (4, 2), respectively. In the case that only the HC value is taken into account for parent selection and Rank evaluation, then the selection of node A parent = easily leads to node B (node A Rank =3D 3). On the contrary, if the LR value is considered, then node A will select = node C as its parent (node A Rank =3D 2).=20 Of course the answer here could be: "Based on the application I would = select either HC or LR". However, in more complex cases e.g. QoS requirement of an optimal path, = the selection of a metric may not be trivial. One OF approach might be: "Each node selects as a parent the node that advertizes the minimum value of HC and in case that there are two (or = more) advertizing the same HC value, then it selects the parent that = advertizes the path with the maximum LR." (draft's lexical approach). Another OF might be: "Combine the pair of HC and LR values in the form = of: HC+LR (additive metric composition)". So, node A will select node C as = its preferred parent. It can be proved that this OF might lead to a = construction of a DODAG where the traversed paths are not optimal! The intention of our draft is to present the properties that the routing metrics must hold to assure that the construction of the DODAG (and consequently the selection of the parent node) leads to optimal and loop-free paths. So, it deals with OF design as you correctly mentioned = in your email: "it is your OF's responsibility to define how that happens". This idea is not new. There are well-defined routing algebras that set = the conditions (routing metric properties) for achieving routing protocol convergence, optimality and loop-freeness, mainly for Internet routing protocols. Our goal is to "transfer" these routing metrics properties in LLN's, providing guidelines for the design of efficient OF's. Best Regards, Theodore & Panos -----Original Message----- From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: Wednesday, August 03, 2011 1:33 PM To: zahariad@teihal.gr; roll@ietf.org Cc: TRAKADAS PANOS Subject: RE: [Roll] FW: New I-D on composite routing metrics Hi Theodore: I'm curious here: you did not explain why you have to build a single instance with composite metric as opposed to multiple instances each optimized for a certain flow. In any fashion, you're correct, the OF framework is designed to allow = you to have a mission specific logic with multiple criteria. We expect, though, that each metric you need is propagated separately and is not polluted = by other metrics. Only the Rank mixes things together, and it is your OF's responsibility to define how that happens... Cheers; Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of > Theodore Zahariadis > Sent: Tuesday, August 02, 2011 8:56 AM > To: roll@ietf.org > Cc: TRAKADAS PANOS > Subject: [Roll] FW: New I-D on composite routing metrics >=20 > Dear all, > My colleague Dr. Panos Trakadas and myself are working on an EC-funded > research project, called VITRO (Virtualized Distributed platform of = Smart > objects - http://www.vitro-fp7.eu/), which has adopted RPL as the = primary > routing protocol and we are currently performing some simulations and > tests. >=20 > By monitoring roll, we have noticed that three (sorry if we have = missed any) > I-D are discussed in the ROLL WG = (draft-ietf-roll-minrank-hysteresis-of, > draft-ietf-roll-of0, draft-gnawali-roll-etxof), defining RPL Objective > Functions related to a single routing metric (either hop-count or = ETX). >=20 > In VITRO, each sensor may be part of many virtual networks (even from > different administrative domains) and must be able to concurrently = support > multiple user requests even with contradicting QoS characteristics. It = is > obvious that in=A0such cases, a composite routing metric is of great > importance. >=20 > In draft-zahariadis-roll-metrics-composition-00 > (http://datatracker.ietf.org/doc/draft-zahariadis-roll-metrics-compositio= n/) > , we aim at specifying the guidelines for designing efficient = composite > routing metrics to be applied at RPL routing protocol. >=20 > We would be happy to receive your comments >=20 > Best Regards, > Theodore Zahariadis >=20 >=20 > ------------------------------------ > Ass. Prof. Theodore Zahariadis, PhD > Technological Educational Institute of Chalkida > Psachna, Chalkida, Greece > Tel: +30 22280 99550, +30 6932495045 > Skype: theodore.zahariadis >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From trakadasp@yahoo.gr Thu Aug 4 22:58:37 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7C85E8005 for ; Thu, 4 Aug 2011 22:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBsvqR-ITidB for ; Thu, 4 Aug 2011 22:58:35 -0700 (PDT) Received: from nm4.bullet.mail.ird.yahoo.com (nm4.bullet.mail.ird.yahoo.com [77.238.189.61]) by ietfa.amsl.com (Postfix) with SMTP id 21C9921F883A for ; Thu, 4 Aug 2011 22:58:34 -0700 (PDT) Received: from [77.238.189.233] by nm4.bullet.mail.ird.yahoo.com with NNFMP; 05 Aug 2011 05:58:47 -0000 Received: from [212.82.108.115] by tm14.bullet.mail.ird.yahoo.com with NNFMP; 05 Aug 2011 05:58:47 -0000 Received: from [127.0.0.1] by omp1024.mail.ird.yahoo.com with NNFMP; 05 Aug 2011 05:58:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 156897.77818.bm@omp1024.mail.ird.yahoo.com Received: (qmail 44079 invoked by uid 60001); 5 Aug 2011 05:58:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.gr; s=s1024; t=1312523927; bh=9oDf6/u/t3tcZvPyzEfbOTpQOKqk3sxBZ6nJkocW7VU=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=di3mivCtxt/sbyWwaI7Op+ekCpZhlNvv+N8++xpBMAc/bpTeStLL8Zojm725t4azIIu4fYk5HVtHyWbvRUJ5TVtKZiWn2m3EXF2hzOgcUUdyV+DKJCCvqDxrTRUNrxzDkrfc2WQErQyy8bkbZH6wpHmuFVT9xwikCedDTzrgc/4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.gr; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=gYxa8N4FTQa0oyoN5O97hn1Ykmw+rUMePxMTUI6r6ZTWoATu39MTAaGyHL5EwRFXZKDtd0zqT9kLSCAUufglV2vKhmpp33mC9lbM9o+4FSczbtpoHW5mCxku2pbys2VYvXcwQCfEaoIs8JtLJFgyfo+ta7Ij7gmPKRTvsCGXvGg=; X-YMail-OSG: LX4ojK8VM1nPK6MYPvTq1b2VAKi1DoCMRTB12HxF99WgJws SfegRuRxgO.yk4rYKEEB1J7MfyoJI4H9uW4E0mck3HpIqs_G9K9Zg.s8V7on d4Lf82oEKTp3watoA0Wrk6C74v9Pz3IVW8JtFw6r38k0GTT3wkXRC9Dvms4S tBNqWj4BUY4Q6h4YxiLHmGSnv02kiLxYgbDUiYlekDYhiqS6uLdGL5_S1xTJ O96DgOvcszYWsA0U80p_eAnzh26RT2f84J5Dj0UEvgmnQOB1_KWXbV9C9Z00 7H7AeCd18nGnX35EfMYu13eu9bW1W63rD6GPxJeMNyTkQKulopv56HJCfJt5 E6LdIJjNEXmK6a_O602u38n_Vygz7WQNSngD_oWHxzqKZg7jG_Kf64wnTe9C jxQ3zsnWqJ.pPuvFFxguN9E.p0sz7ZQdL4iEgi1g4Db8k4eZOzUYETxEn6HH ANP1BDmOxQBLUc95MNE2827HjymTeebxjwVbTvYp1o.PZ1_jd07jnvNXSDWH Awj5jiWsPUHrYzH8x8Dioq5nr1rKxQkaAuZg- Received: from [83.235.46.72] by web29604.mail.ird.yahoo.com via HTTP; Fri, 05 Aug 2011 06:58:46 BST X-Mailer: YahooMailClassic/14.0.3 YahooMailWebService/0.8.113.313619 Message-ID: <1312523926.38437.YahooMailClassic@web29604.mail.ird.yahoo.com> Date: Fri, 5 Aug 2011 06:58:46 +0100 (BST) From: Panos Trakadas To: C Chauvenet In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-437879798-1312523926=:38437" Cc: "roll@ietf.org" Subject: Re: [Roll] FW: New I-D on composite routing metrics X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 05:58:37 -0000 --0-437879798-1312523926=:38437 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear Cedric, We believe that the definition of "order relation" is correct: the order re= lation is used by the OF to compare link/node weights along the path (equiv= alently, metric values) and select parent node. As an example, consider the= case where the ETX is aggregated along the traversed path. If node A recei= ves DIO messages from nodes B and C (potential parents) with ETX values of = 2.5 and 3.2, respectively, then the order relation will help selecting node= B (advertising the minimum value of ETX) as the parent of node A. In this concept, your comment is right; the order relation of LQL must be m= inimum (and not maximum). Please consider it as a typo. Regarding link-color comment: Apart from being used as a 10-bit flag field = (e.g. for indicating the encrypted links, as described in rpl-metrics draft= ), link color may be used to indicate the number of nodes along the path tr= ansmitting at a specific radio channel; in this way interference can be red= uced by selecting transmission in the "least occupied" channel. In this cas= e, the order relation must be "minimum" and the domain is integer. In general, we will re-format Table 1, following the metric description in = rpl-metrics draft. Also, we will replace words "minimum"/"maximum" in the "= order relation" column by "less-than" and "greater-than" in accordance to t= he order relation definition. Before submitting this draft, there was a discussion on whether we should i= nclude examples and formulas in this initial version of the document; it se= ems that our decision was wrong... We will be happy to include examples and= formulas to improve readability of this draft. Finally, we think that "hysteresis" can provably improve RPL performance, a= nd thus it will be included in this draft. To be honest, there is a "hidden= " phrase: "...and if the first component values are equal *or differ less t= han a predefined threshold*..." (section 4.1, first sentence) indicating ou= r effort to include hysteresis in this draft. We will give more emphasis on= that point. Thanks for your valuable comments, Panos. --- =CE=A3=CF=84=CE=B9=CF=82 =CE=A4=CE=B5=CF=84., 03/08/11, =CE=BF/=CE=B7 C= Chauvenet =CE=AD=CE=B3=CF=81=CE=B1=CF=88=CE=B5: =CE=91=CF=80=CF=8C: C Chauvenet =CE=98=CE=AD=CE=BC=CE=B1: Re: [Roll] FW: New I-D on composite routing metri= cs =CE=A0=CF=81=CE=BF=CF=82: "zahariad@teihal.gr" =CE=9A=CE=BF=CE=B9=CE=BD.: "TRAKADAS PANOS" , "roll@ietf= .org" =CE=97=CE=BC=CE=B5=CF=81=CE=BF=CE=BC=CE=B7=CE=BD=CE=AF=CE=B1: =CE=A4=CE=B5= =CF=84=CE=AC=CF=81=CF=84=CE=B7, 3 =CE=91=CF=8D=CE=B3=CE=BF=CF=85=CF=83=CF= =84=CE=BF=CF=82 2011, 18:46 Hi Theodore,=20 I found your draft interesting and it gave me some useful guidelines for me= tric's design. I've several comments on this :=20 I fail to understand well the "Order Relation" you use in Table 1. The definition of "metric order relation" given on page 4 doesn't really he= lped me. Could you help me understand the Order Relation column in the table? In this table in particular (Figure 1):=20 =C2=A0=C2=A0=C2=A0 - Could you precise your view of the=C2=A0 Link-Color me= tric (Why is it in the integer domain, why the order relation in "minimum" = ?). =C2=A0=C2=A0=C2=A0 - As far as I understand the Order Relation, it seems th= at the LQL order relation should not be "maximum" but rather "minimum" (sam= e relation as ETX, excluding the 0 value). More generally, I would be happy to see in the document some formulas examp= les for metric computation, or maybe some guidelines. Some example of metrics composition would also be great (You mention one in= your draft with is ETX + RE (remainging Energy). Do you have some idea abo= ut other set of metric that would be interesting to bind ? I finally think that it should be worth to add some content about the mecha= nisms that aim to deal with metric's dynamics (Multi Threshold, EWMA, Low p= ass Filters, ...). Some of them are mentioned at the end of the rpl metric = draft. Best, C=C3=A9dric. Le 2 ao=C3=BBt 2011 =C3=A0 02:55, Theodore Zahariadis a =C3=A9crit : > Dear all, > My colleague Dr. Panos Trakadas and myself are working on an EC-funded > research project, called VITRO (Virtualized Distributed platform of Smart > objects - http://www.vitro-fp7.eu/), which has adopted RPL as the primary > routing protocol and we are currently performing some simulations and tes= ts. >=20 > By monitoring roll, we have noticed that three (sorry if we have missed a= ny) > I-D are discussed in the ROLL WG (draft-ietf-roll-minrank-hysteresis-of, > draft-ietf-roll-of0, draft-gnawali-roll-etxof), defining RPL Objective > Functions related to a single routing metric (either hop-count or ETX). >=20 > In VITRO, each sensor may be part of many virtual networks (even from > different administrative domains) and must be able to concurrently suppor= t > multiple user requests even with contradicting QoS characteristics. It is > obvious that in such cases, a composite routing metric is of great > importance. >=20 > In draft-zahariadis-roll-metrics-composition-00 > (http://datatracker.ietf.org/doc/draft-zahariadis-roll-metrics-compositio= n/) > , we aim at specifying the guidelines for designing efficient composite > routing metrics to be applied at RPL routing protocol. >=C2=A0=20 > We would be happy to receive your comments >=C2=A0=20 > Best Regards, > Theodore Zahariadis >=20 >=20 > ------------------------------------ > Ass. Prof. Theodore Zahariadis, PhD > Technological Educational Institute of Chalkida > Psachna, Chalkida, Greece > Tel: +30 22280 99550, +30 6932495045 > Skype: theodore.zahariadis >=20 >=20 > _______________________________________________ > 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 --0-437879798-1312523926=:38437 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Dear Cedric,

We believe that the defin= ition of "order relation" is correct: the order relation is used by the OF = to compare link/node weights along the path (equivalently, metric values) a= nd select parent node. As an example, consider the case where the ETX is ag= gregated along the traversed path. If node A receives DIO messages from nod= es B and C (potential parents) with ETX values of 2.5 and 3.2, respectively= , then the order relation will help selecting node B (advertising the minim= um value of ETX) as the parent of node A.
In this concept, your comment = is right; the order relation of LQL must be minimum (and not maximum). Plea= se consider it as a typo.

Regarding link-color comment: Apart from b= eing used as a 10-bit flag field (e.g. for indicating the encrypted links, = as described in rpl-metrics draft), link color may be used to indicate the number of nodes along the path transmitting at a specific radio channel; i= n this way interference can be reduced by selecting transmission in the "le= ast occupied" channel. In this case, the order relation must be "minimum" a= nd the domain is integer.

In general, we will re-format Table 1, fol= lowing the metric description in rpl-metrics draft. Also, we will replace w= ords "minimum"/"maximum" in the "order relation" column by "less-than" and = "greater-than" in accordance to the order relation definition.

Befor= e submitting this draft, there was a discussion on whether we should includ= e examples and formulas in this initial version of the document; it seems t= hat our decision was wrong... We will be happy to include examples and form= ulas to improve readability of this draft.

Finally, we think that "h= ysteresis" can provably improve RPL performance, and thus it will be includ= ed in this draft. To be honest, there is a "hidden" phrase: "...and if the first component values are equal *or differ less than a predefined = threshold*..." (section 4.1, first sentence) indicating our effort to inclu= de hysteresis in this draft. We will give more emphasis on that point.
<= BR>Thanks for your valuable comments,
Panos.


--- =CE=A3=CF=84= =CE=B9=CF=82 =CE=A4=CE=B5=CF=84., 03/08/11, =CE=BF/=CE=B7 C Chauvenet <c.chauvenet@watteco.com> =CE=AD=CE=B3=CF=81=CE=B1=CF=88=CE= =B5:

=CE=91=CF=80=CF=8C: C Chauvenet <c.chauvenet@w= atteco.com>
=CE=98=CE=AD=CE=BC=CE=B1: Re: [Roll] FW: New I-D on compo= site routing metrics
=CE=A0=CF=81=CE=BF=CF=82: "zahariad@teihal.gr" <= zahariad@teihal.gr>
=CE=9A=CE=BF=CE=B9=CE=BD.: "TRAKADAS PANOS" <t= rakadasp@adae.gr>, "roll@ietf.org" <roll@ietf.org>
=CE=97=CE=BC= =CE=B5=CF=81=CE=BF=CE=BC=CE=B7=CE=BD=CE=AF=CE=B1: =CE=A4=CE=B5=CF=84=CE=AC= =CF=81=CF=84=CE=B7, 3 =CE=91=CF=8D=CE=B3=CE=BF=CF=85=CF=83=CF=84=CE=BF=CF= =82 2011, 18:46

Hi Theodore,

I found your draft interesting = and it gave me some useful guidelines for metric's design.

I've seve= ral comments on this :

I fail to understand well the "Order Relatio= n" you use in Table 1.
The definition of "metric order relation" given o= n page 4 doesn't really helped me.
Could you help me understand the Orde= r Relation column in the table?

In this table in particular (Figure = 1):

    - Could you precise your view of the  L= ink-Color metric (Why is it in the integer domain, why the order relation i= n "minimum" ?).

    - As far as I understand the Orde= r Relation, it seems that the LQL order relation should not be "maximum" bu= t rather "minimum" (same relation as ETX, excluding the 0 value).

More generally, I would be happy to see in the document some formulas exa= mples for metric computation, or maybe some guidelines.

Some example of metrics composition would also be great (You mention one in you= r draft with is ETX + RE (remainging Energy). Do you have some idea about o= ther set of metric that would be interesting to bind ?

I finally thi= nk that it should be worth to add some content about the mechanisms that ai= m to deal with metric's dynamics (Multi Threshold, EWMA, Low pass Filters, = ...). Some of them are mentioned at the end of the rpl metric draft.
Best,

C=C3=A9dric.

Le 2 ao=C3=BBt 2011 =C3=A0 02:55, Theodor= e Zahariadis a =C3=A9crit :

> Dear all,
> My colleague Dr. = Panos Trakadas and myself are working on an EC-funded
> research proj= ect, called VITRO (Virtualized Distributed platform of Smart
> object= s - http://www.vitro-f= p7.eu/), which has adopted RPL as the primary
> routing protocol = and we are currently performing some simulations and tests.
>
>= ; By monitoring roll, we have noticed that three (sorry if we have missed any)<= BR>> I-D are discussed in the ROLL WG (draft-ietf-roll-minrank-hysteresi= s-of,
> draft-ietf-roll-of0, draft-gnawali-roll-etxof), defining RPL = Objective
> Functions related to a single routing metric (either hop-= count or ETX).
>
> In VITRO, each sensor may be part of many v= irtual networks (even from
> different administrative domains) and mu= st be able to concurrently support
> multiple user requests even with= contradicting QoS characteristics. It is
> obvious that in such case= s, a composite routing metric is of great
> importance.
>
&= gt; In draft-zahariadis-roll-metrics-composition-00
> (http://datatracker.ietf.org/doc/draft-zahariadis-roll-metrics= -composition/)
> , we aim at specifying the guidelines for designing efficient composite
> routing metrics to be applied at RPL= routing protocol.
> 
> We would be happy to receive your= comments
> 
> Best Regards,
> Theodore Zahariadis<= BR>>
>
> ------------------------------------
> Ass.= Prof. Theodore Zahariadis, PhD
> Technological Educational Institute= of Chalkida
> Psachna, Chalkida, Greece
> Tel: +30 22280 99550= , +30 6932495045
> Skype: theodore.zahariadis
>
>
&g= t; _______________________________________________
> Roll mailing lis= t
> Roll@ietf.org
> https://www= .ietf.org/mailman/listinfo/roll


____________________________= ___________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/= listinfo/roll
--0-437879798-1312523926=:38437-- From dat@exegin.com Fri Aug 5 16:06:46 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C33F11E807B for ; Fri, 5 Aug 2011 16:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6XEUonDnrPp for ; Fri, 5 Aug 2011 16:06:46 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 19F6311E8078 for ; Fri, 5 Aug 2011 16:06:45 -0700 (PDT) Received: by pzk33 with SMTP id 33so124938pzk.18 for ; Fri, 05 Aug 2011 16:07:04 -0700 (PDT) Received: by 10.143.20.28 with SMTP id x28mr2600723wfi.349.1312585624624; Fri, 05 Aug 2011 16:07:04 -0700 (PDT) Received: from [172.16.1.52] ([216.251.130.154]) by mx.google.com with ESMTPS id m7sm3586423pbk.54.2011.08.05.16.07.03 (version=SSLv3 cipher=OTHER); Fri, 05 Aug 2011 16:07:03 -0700 (PDT) Message-ID: <4E3C7795.1030701@exegin.com> Date: Fri, 05 Aug 2011 16:07:01 -0700 From: Dario Tedeschi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: 'ROLL WG' Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] IP-in-IP tunneling for HbH Option X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 23:06:46 -0000 I been through the archived mailing list, but did not find an answer to the following question: What destination address should be used in the outer header of a tunnel when a router needs to add a RPL HbH option on behalf of a non-RPL aware leaf node? There are three possibles I can see: [a]. Use the address of the root node. [b]. Use the destination address of the original IPv6 header. [c]. Use the address of your RPL parent. After some experimentation, I found that both [a] and [b] have issues depending on the final destination (the destination of the original datagram). I had thought of [c] as a solution, but quickly realized it was a bad idea. Problem 1: Final destination is inside the RPL domain and [a] is used. --------- For any destination in the RPL domain, the datagram is always sent to the root node even when the path to the root includes a node having the final destination address or a matching routing entry. This seems inefficient at best. Particularly when used in a storing-mode RPL network. Problem 2: Final destination address is outside the RPL domain via the BR and [b] is used. --------- The BR will not decapsulate, because the destination address of the datagram is not one of the BRs addresses (i.e. the datagram is not meant for it but some other destination). This means the BR will just forward the datagram to the next-hop outside the RPL domain. The final destination is not a tunnel exit-point so it then sends a "Parameter Problem" message with code=1 back to the source (i.e. the entry-point of the tunnel). Problem 3: [c] is used. -------- Decapsulation and encapsulation of the original datagram would be required at every upward hop within the RPL network. Solution 1: Use [a] or [b] depending on whether the final destination is outside or inside the RPL domain. ------- How does a router know whether a destination is inside or outside the RPL domain? Solution 2: Always use [b], but BRs strip off the outer header if forwarding outside the RPL domain or forwarding using source-routing inside the RPL domain. ------- This is a simple approach, but perhaps a little ugly. The forwarding logic in the BR needs to look past the first IPv6 header to see if it's a tunneled packet. If it is tunneled, the outer header is stripped off and the original datagram is forwarded. Dario From c.chauvenet@watteco.com Sat Aug 6 07:32:26 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C2721F85CA for ; Sat, 6 Aug 2011 07:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.848 X-Spam-Level: X-Spam-Status: No, score=-5.848 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9QOStFIW6OW for ; Sat, 6 Aug 2011 07:32:24 -0700 (PDT) Received: from VA3EHSOBE007.bigfish.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9DC21F85CE for ; Sat, 6 Aug 2011 07:32:24 -0700 (PDT) Received: from mail101-va3-R.bigfish.com (10.7.14.254) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.22; Sat, 6 Aug 2011 14:32:44 +0000 Received: from mail101-va3 (localhost.localdomain [127.0.0.1]) by mail101-va3-R.bigfish.com (Postfix) with ESMTP id 1679A150112; Sat, 6 Aug 2011 14:32:44 +0000 (UTC) X-SpamScore: -34 X-BigFish: VPS-34(zzbb2dKc89bh1418M1432Nc857hzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h8aah61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:213.199.187.153; KIP:(null); UIP:(null); IPVD:NLI; SRV:BULK; H:IE2RD2HUB008.red002.local; RD:none; EFVD:NLI Received: from mail101-va3 (localhost.localdomain [127.0.0.1]) by mail101-va3 (MessageSwitch) id 1312641131958650_30923; Sat, 6 Aug 2011 14:32:11 +0000 (UTC) Received: from VA3EHSMHS006.bigfish.com (unknown [10.7.14.239]) by mail101-va3.bigfish.com (Postfix) with ESMTP id 2146C104807E; Sat, 6 Aug 2011 14:30:05 +0000 (UTC) Received: from IE2RD2HUB008.red002.local (213.199.187.153) by VA3EHSMHS006.bigfish.com (10.7.99.16) with Microsoft SMTP Server (TLS) id 14.1.225.22; Sat, 6 Aug 2011 14:29:51 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.55]) by IE2RD2HUB008.red002.local ([10.33.16.156]) with mapi; Sat, 6 Aug 2011 07:29:38 -0700 From: C Chauvenet To: Panos Trakadas Date: Sat, 6 Aug 2011 07:29:35 -0700 Thread-Topic: [Roll] FW: New I-D on composite routing metrics Thread-Index: AcxURUUt6Hy/3Z57SZWKm8yTHWhmZw== Message-ID: <5AC33E43-72B0-4317-A4BA-030855BA6B45@watteco.com> References: <1312523926.38437.YahooMailClassic@web29604.mail.ird.yahoo.com> In-Reply-To: <1312523926.38437.YahooMailClassic@web29604.mail.ird.yahoo.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_5AC33E4372B04317A4BA030855BA6B45wattecocom_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "roll@ietf.org" Subject: Re: [Roll] FW: New I-D on composite routing metrics X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 14:32:26 -0000 --_000_5AC33E4372B04317A4BA030855BA6B45wattecocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClNlZSBpbmxpbmUuDQoNCkxlIDUgYW/Du3QgMjAxMSDDoCAwMTo1OCwgUGFub3MgVHJh a2FkYXMgYSDDqWNyaXQgOg0KDQpEZWFyIENlZHJpYywNCg0KV2UgYmVsaWV2ZSB0aGF0IHRoZSBk ZWZpbml0aW9uIG9mICJvcmRlciByZWxhdGlvbiIgaXMgY29ycmVjdDogdGhlIG9yZGVyIHJlbGF0 aW9uIGlzIHVzZWQgYnkgdGhlIE9GIHRvIGNvbXBhcmUgbGluay9ub2RlIHdlaWdodHMgYWxvbmcg dGhlIHBhdGggKGVxdWl2YWxlbnRseSwgbWV0cmljIHZhbHVlcykgYW5kIHNlbGVjdCBwYXJlbnQg bm9kZS4NCg0KDQpbQy5DXSBJIEFncmVlIHdpdGggeW91ciBkZWZpbml0aW9uLg0KDQpBcyBhbiBl eGFtcGxlLCBjb25zaWRlciB0aGUgY2FzZSB3aGVyZSB0aGUgRVRYIGlzIGFnZ3JlZ2F0ZWQgYWxv bmcgdGhlIHRyYXZlcnNlZCBwYXRoLiBJZiBub2RlIEEgcmVjZWl2ZXMgRElPIG1lc3NhZ2VzIGZy b20gbm9kZXMgQiBhbmQgQyAocG90ZW50aWFsIHBhcmVudHMpIHdpdGggRVRYIHZhbHVlcyBvZiAy LjUgYW5kIDMuMiwgcmVzcGVjdGl2ZWx5LCB0aGVuIHRoZSBvcmRlciByZWxhdGlvbiB3aWxsIGhl bHAgc2VsZWN0aW5nIG5vZGUgQiAoYWR2ZXJ0aXNpbmcgdGhlIG1pbmltdW0gdmFsdWUgb2YgRVRY KSBhcyB0aGUgcGFyZW50IG9mIG5vZGUgQS4NCkluIHRoaXMgY29uY2VwdCwgeW91ciBjb21tZW50 IGlzIHJpZ2h0OyB0aGUgb3JkZXIgcmVsYXRpb24gb2YgTFFMIG11c3QgYmUgbWluaW11bSAoYW5k IG5vdCBtYXhpbXVtKS4gUGxlYXNlIGNvbnNpZGVyIGl0IGFzIGEgdHlwby4NCg0KDQpbQy5DXSBP Sw0KDQoNClJlZ2FyZGluZyBsaW5rLWNvbG9yIGNvbW1lbnQ6IEFwYXJ0IGZyb20gYmVpbmcgdXNl ZCBhcyBhIDEwLWJpdCBmbGFnIGZpZWxkIChlLmcuIGZvciBpbmRpY2F0aW5nIHRoZSBlbmNyeXB0 ZWQgbGlua3MsIGFzIGRlc2NyaWJlZCBpbiBycGwtbWV0cmljcyBkcmFmdCksIGxpbmsgY29sb3Ig bWF5IGJlIHVzZWQgdG8gaW5kaWNhdGUgdGhlIG51bWJlciBvZiBub2RlcyBhbG9uZyB0aGUgcGF0 aCB0cmFuc21pdHRpbmcgYXQgYSBzcGVjaWZpYyByYWRpbyBjaGFubmVsOyBpbiB0aGlzIHdheSBp bnRlcmZlcmVuY2UgY2FuIGJlIHJlZHVjZWQgYnkgc2VsZWN0aW5nIHRyYW5zbWlzc2lvbiBpbiB0 aGUgImxlYXN0IG9jY3VwaWVkIiBjaGFubmVsLiBJbiB0aGlzIGNhc2UsIHRoZSBvcmRlciByZWxh dGlvbiBtdXN0IGJlICJtaW5pbXVtIiBhbmQgdGhlIGRvbWFpbiBpcyBpbnRlZ2VyLg0KDQpbQy5D XSBJIHRoaW5rIHRoYXQgdGhlIGNvbmZ1c2lvbiBpcyBncmVhdGx5IGR1ZSB0byB0aGUgdmVyeSB3 aWRlIHJhbmdlIHRoYXQgdGhlIGxpbmsgY29sb3IgbWV0cmljIG1heSBjb3Zlci4gWW91IGV4YW1w bGUgb2YgdGhlIHVzYWdlIG9mIHRoaXMgbWV0cmljIGlzIGludGVyZXN0aW5nLCBidXQgbWFueSBv dGhlcnMgdXNhZ2UgbWF5IGJlIHBvc3NpYmxlLCBhbmQgc28gYW4gZ2xvYmFsIG9yZGVyIHJlbGF0 aW9uIHNlZW1zIGRpZmZpY3VsdCB0byBmaW5kIGZvciB0aGlzIG1ldHJpYy4NCg0KSW4gZ2VuZXJh bCwgd2Ugd2lsbCByZS1mb3JtYXQgVGFibGUgMSwgZm9sbG93aW5nIHRoZSBtZXRyaWMgZGVzY3Jp cHRpb24gaW4gcnBsLW1ldHJpY3MgZHJhZnQuIEFsc28sIHdlIHdpbGwgcmVwbGFjZSB3b3JkcyAi bWluaW11bSIvIm1heGltdW0iIGluIHRoZSAib3JkZXIgcmVsYXRpb24iIGNvbHVtbiBieSAibGVz cy10aGFuIiBhbmQgImdyZWF0ZXItdGhhbiIgaW4gYWNjb3JkYW5jZSB0byB0aGUgb3JkZXIgcmVs YXRpb24gZGVmaW5pdGlvbi4NCg0KW0MuQ10gSSBhZ3JlZSB0aGF0IGl0IHdvdWxkIGluY3JlYXNl IHRoZSByZWFkYWJpbGl0eS4NCg0KQmVmb3JlIHN1Ym1pdHRpbmcgdGhpcyBkcmFmdCwgdGhlcmUg d2FzIGEgZGlzY3Vzc2lvbiBvbiB3aGV0aGVyIHdlIHNob3VsZCBpbmNsdWRlIGV4YW1wbGVzIGFu ZCBmb3JtdWxhcyBpbiB0aGlzIGluaXRpYWwgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQ7IGl0IHNl ZW1zIHRoYXQgb3VyIGRlY2lzaW9uIHdhcyB3cm9uZy4uLiBXZSB3aWxsIGJlIGhhcHB5IHRvIGlu Y2x1ZGUgZXhhbXBsZXMgYW5kIGZvcm11bGFzIHRvIGltcHJvdmUgcmVhZGFiaWxpdHkgb2YgdGhp cyBkcmFmdC4NCg0KW0MuQ10gTmljZS4gSSB0aGluayB0aGlzIHdvdWxkIHByb3ZpZGUgcHJlY2lv dXMgZ3VpZGVsaW5lcyBmb3IgcmVhZGVycywgYW5kIHNwZWVkIHVwIHNvbWUgUlBMIGRlc2lnbi4N Cg0KRmluYWxseSwgd2UgdGhpbmsgdGhhdCAiaHlzdGVyZXNpcyIgY2FuIHByb3ZhYmx5IGltcHJv dmUgUlBMIHBlcmZvcm1hbmNlLCBhbmQgdGh1cyBpdCB3aWxsIGJlIGluY2x1ZGVkIGluIHRoaXMg ZHJhZnQuIFRvIGJlIGhvbmVzdCwgdGhlcmUgaXMgYSAiaGlkZGVuIiBwaHJhc2U6ICIuLi5hbmQg aWYgdGhlIGZpcnN0IGNvbXBvbmVudCB2YWx1ZXMgYXJlIGVxdWFsICpvciBkaWZmZXIgbGVzcyB0 aGFuIGEgcHJlZGVmaW5lZCB0aHJlc2hvbGQqLi4uIiAoc2VjdGlvbiA0LjEsIGZpcnN0IHNlbnRl bmNlKSBpbmRpY2F0aW5nIG91ciBlZmZvcnQgdG8gaW5jbHVkZSBoeXN0ZXJlc2lzIGluIHRoaXMg ZHJhZnQuIFdlIHdpbGwgZ2l2ZSBtb3JlIGVtcGhhc2lzIG9uIHRoYXQgcG9pbnQuDQoNCltDLkNd IEkgbm90aWNlZCB0aGF0IHJlZmVyZW5jZSwgYnV0IGl0IHNob3VsZCBiZSB3b3J0aCB0byBleHBs aWNpdGx5IHNwZWFrIGFib3V0IGl0LiBJIGFsc28gYWdyZWUgdGhhdCB0aGUgSHlzdGVyZXNpcyBt ZWNoYW5pc20gZGVmaW5lZCBpbiB0aGUgTVJIT0YgZHJhZnQgZ3JlYXRseSBpbXByb3ZlIHRoZSBz dGFiaWxpdHkgb2YgdGhlIHRvcG9sb2d5IGFuZCBzaG91bGQgYmUgaGlnaGx5IHJlY29tbWVuZGVk LiBCVFcsIHNvbWUgZ3VpZGVsaW5lcyBhYm91dCBob3cgdG8gZGV0ZXJtaW5lIHRoZSBnb29kIHRo cmVzaG9sZCB2YWx1ZSB3b3VsZCBiZSBpbnRlcmVzdGluZy4NCg0KVGhhbmtzIGZvciB5b3VyIHZh bHVhYmxlIGNvbW1lbnRzLA0KUGFub3MuDQoNCkPDqWRyaWMuDQoNCg0KLS0tIM6jz4TOuc+CIM6k zrXPhC4sIDAzLzA4LzExLCDOvy/OtyBDIENoYXV2ZW5ldCA8Yy5jaGF1dmVuZXRAd2F0dGVjby5j b208bWFpbHRvOmMuY2hhdXZlbmV0QHdhdHRlY28uY29tPj4gzq3Os8+BzrHPiM61Og0KDQrOkc+A z4w6IEMgQ2hhdXZlbmV0IDxjLmNoYXV2ZW5ldEB3YXR0ZWNvLmNvbTxtYWlsdG86Yy5jaGF1dmVu ZXRAd2F0dGVjby5jb20+Pg0KzpjOrc68zrE6IFJlOiBbUm9sbF0gRlc6IE5ldyBJLUQgb24gY29t cG9zaXRlIHJvdXRpbmcgbWV0cmljcw0KzqDPgc6/z4I6ICJ6YWhhcmlhZEB0ZWloYWwuZ3I8bWFp bHRvOnphaGFyaWFkQHRlaWhhbC5ncj4iIDx6YWhhcmlhZEB0ZWloYWwuZ3I8bWFpbHRvOnphaGFy aWFkQHRlaWhhbC5ncj4+DQrOms6/zrnOvS46ICJUUkFLQURBUyBQQU5PUyIgPHRyYWthZGFzcEBh ZGFlLmdyPG1haWx0bzp0cmFrYWRhc3BAYWRhZS5ncj4+LCAicm9sbEBpZXRmLm9yZzxtYWlsdG86 cm9sbEBpZXRmLm9yZz4iIDxyb2xsQGlldGYub3JnPG1haWx0bzpyb2xsQGlldGYub3JnPj4NCs6X zrzOtc+Bzr/OvM63zr3Or86xOiDOpM61z4TOrM+Bz4TOtywgMyDOkc+NzrPOv8+Fz4PPhM6/z4Ig MjAxMSwgMTg6NDYNCg0KSGkgVGhlb2RvcmUsDQoNCkkgZm91bmQgeW91ciBkcmFmdCBpbnRlcmVz dGluZyBhbmQgaXQgZ2F2ZSBtZSBzb21lIHVzZWZ1bCBndWlkZWxpbmVzIGZvciBtZXRyaWMncyBk ZXNpZ24uDQoNCkkndmUgc2V2ZXJhbCBjb21tZW50cyBvbiB0aGlzIDoNCg0KSSBmYWlsIHRvIHVu ZGVyc3RhbmQgd2VsbCB0aGUgIk9yZGVyIFJlbGF0aW9uIiB5b3UgdXNlIGluIFRhYmxlIDEuDQpU aGUgZGVmaW5pdGlvbiBvZiAibWV0cmljIG9yZGVyIHJlbGF0aW9uIiBnaXZlbiBvbiBwYWdlIDQg ZG9lc24ndCByZWFsbHkgaGVscGVkIG1lLg0KQ291bGQgeW91IGhlbHAgbWUgdW5kZXJzdGFuZCB0 aGUgT3JkZXIgUmVsYXRpb24gY29sdW1uIGluIHRoZSB0YWJsZT8NCg0KSW4gdGhpcyB0YWJsZSBp biBwYXJ0aWN1bGFyIChGaWd1cmUgMSk6DQoNCiAgICAtIENvdWxkIHlvdSBwcmVjaXNlIHlvdXIg dmlldyBvZiB0aGUgIExpbmstQ29sb3IgbWV0cmljIChXaHkgaXMgaXQgaW4gdGhlIGludGVnZXIg ZG9tYWluLCB3aHkgdGhlIG9yZGVyIHJlbGF0aW9uIGluICJtaW5pbXVtIiA/KS4NCg0KICAgIC0g QXMgZmFyIGFzIEkgdW5kZXJzdGFuZCB0aGUgT3JkZXIgUmVsYXRpb24sIGl0IHNlZW1zIHRoYXQg dGhlIExRTCBvcmRlciByZWxhdGlvbiBzaG91bGQgbm90IGJlICJtYXhpbXVtIiBidXQgcmF0aGVy ICJtaW5pbXVtIiAoc2FtZSByZWxhdGlvbiBhcyBFVFgsIGV4Y2x1ZGluZyB0aGUgMCB2YWx1ZSku DQoNCg0KTW9yZSBnZW5lcmFsbHksIEkgd291bGQgYmUgaGFwcHkgdG8gc2VlIGluIHRoZSBkb2N1 bWVudCBzb21lIGZvcm11bGFzIGV4YW1wbGVzIGZvciBtZXRyaWMgY29tcHV0YXRpb24sIG9yIG1h eWJlIHNvbWUgZ3VpZGVsaW5lcy4NCg0KU29tZSBleGFtcGxlIG9mIG1ldHJpY3MgY29tcG9zaXRp b24gd291bGQgYWxzbyBiZSBncmVhdCAoWW91IG1lbnRpb24gb25lIGluIHlvdXIgZHJhZnQgd2l0 aCBpcyBFVFggKyBSRSAocmVtYWluZ2luZyBFbmVyZ3kpLiBEbyB5b3UgaGF2ZSBzb21lIGlkZWEg YWJvdXQgb3RoZXIgc2V0IG9mIG1ldHJpYyB0aGF0IHdvdWxkIGJlIGludGVyZXN0aW5nIHRvIGJp bmQgPw0KDQpJIGZpbmFsbHkgdGhpbmsgdGhhdCBpdCBzaG91bGQgYmUgd29ydGggdG8gYWRkIHNv bWUgY29udGVudCBhYm91dCB0aGUgbWVjaGFuaXNtcyB0aGF0IGFpbSB0byBkZWFsIHdpdGggbWV0 cmljJ3MgZHluYW1pY3MgKE11bHRpIFRocmVzaG9sZCwgRVdNQSwgTG93IHBhc3MgRmlsdGVycywg Li4uKS4gU29tZSBvZiB0aGVtIGFyZSBtZW50aW9uZWQgYXQgdGhlIGVuZCBvZiB0aGUgcnBsIG1l dHJpYyBkcmFmdC4NCg0KQmVzdCwNCg0KQ8OpZHJpYy4NCg0KTGUgMiBhb8O7dCAyMDExIMOgIDAy OjU1LCBUaGVvZG9yZSBaYWhhcmlhZGlzIGEgw6ljcml0IDoNCg0KPiBEZWFyIGFsbCwNCj4gTXkg Y29sbGVhZ3VlIERyLiBQYW5vcyBUcmFrYWRhcyBhbmQgbXlzZWxmIGFyZSB3b3JraW5nIG9uIGFu IEVDLWZ1bmRlZA0KPiByZXNlYXJjaCBwcm9qZWN0LCBjYWxsZWQgVklUUk8gKFZpcnR1YWxpemVk IERpc3RyaWJ1dGVkIHBsYXRmb3JtIG9mIFNtYXJ0DQo+IG9iamVjdHMgLSBodHRwOi8vd3d3LnZp dHJvLWZwNy5ldS8pLCB3aGljaCBoYXMgYWRvcHRlZCBSUEwgYXMgdGhlIHByaW1hcnkNCj4gcm91 dGluZyBwcm90b2NvbCBhbmQgd2UgYXJlIGN1cnJlbnRseSBwZXJmb3JtaW5nIHNvbWUgc2ltdWxh dGlvbnMgYW5kIHRlc3RzLg0KPg0KPiBCeSBtb25pdG9yaW5nIHJvbGwsIHdlIGhhdmUgbm90aWNl ZCB0aGF0IHRocmVlIChzb3JyeSBpZiB3ZSBoYXZlIG1pc3NlZCBhbnkpDQo+IEktRCBhcmUgZGlz Y3Vzc2VkIGluIHRoZSBST0xMIFdHIChkcmFmdC1pZXRmLXJvbGwtbWlucmFuay1oeXN0ZXJlc2lz LW9mLA0KPiBkcmFmdC1pZXRmLXJvbGwtb2YwLCBkcmFmdC1nbmF3YWxpLXJvbGwtZXR4b2YpLCBk ZWZpbmluZyBSUEwgT2JqZWN0aXZlDQo+IEZ1bmN0aW9ucyByZWxhdGVkIHRvIGEgc2luZ2xlIHJv dXRpbmcgbWV0cmljIChlaXRoZXIgaG9wLWNvdW50IG9yIEVUWCkuDQo+DQo+IEluIFZJVFJPLCBl YWNoIHNlbnNvciBtYXkgYmUgcGFydCBvZiBtYW55IHZpcnR1YWwgbmV0d29ya3MgKGV2ZW4gZnJv bQ0KPiBkaWZmZXJlbnQgYWRtaW5pc3RyYXRpdmUgZG9tYWlucykgYW5kIG11c3QgYmUgYWJsZSB0 byBjb25jdXJyZW50bHkgc3VwcG9ydA0KPiBtdWx0aXBsZSB1c2VyIHJlcXVlc3RzIGV2ZW4gd2l0 aCBjb250cmFkaWN0aW5nIFFvUyBjaGFyYWN0ZXJpc3RpY3MuIEl0IGlzDQo+IG9idmlvdXMgdGhh dCBpbiBzdWNoIGNhc2VzLCBhIGNvbXBvc2l0ZSByb3V0aW5nIG1ldHJpYyBpcyBvZiBncmVhdA0K PiBpbXBvcnRhbmNlLg0KPg0KPiBJbiBkcmFmdC16YWhhcmlhZGlzLXJvbGwtbWV0cmljcy1jb21w b3NpdGlvbi0wMA0KPiAoaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16YWhh cmlhZGlzLXJvbGwtbWV0cmljcy1jb21wb3NpdGlvbi8pDQo+ICwgd2UgYWltIGF0IHNwZWNpZnlp bmcgdGhlIGd1aWRlbGluZXMgZm9yIGRlc2lnbmluZyBlZmZpY2llbnQgY29tcG9zaXRlDQo+IHJv dXRpbmcgbWV0cmljcyB0byBiZSBhcHBsaWVkIGF0IFJQTCByb3V0aW5nIHByb3RvY29sLg0KPg0K PiBXZSB3b3VsZCBiZSBoYXBweSB0byByZWNlaXZlIHlvdXIgY29tbWVudHMNCj4NCj4gQmVzdCBS ZWdhcmRzLA0KPiBUaGVvZG9yZSBaYWhhcmlhZGlzDQo+DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBBc3MuIFByb2YuIFRoZW9kb3JlIFphaGFyaWFkaXMsIFBo RA0KPiBUZWNobm9sb2dpY2FsIEVkdWNhdGlvbmFsIEluc3RpdHV0ZSBvZiBDaGFsa2lkYQ0KPiBQ c2FjaG5hLCBDaGFsa2lkYSwgR3JlZWNlDQo+IFRlbDogKzMwIDIyMjgwIDk5NTUwLCArMzAgNjkz MjQ5NTA0NQ0KPiBTa3lwZTogdGhlb2RvcmUuemFoYXJpYWRpcw0KPg0KPg0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBSb2xsIG1haWxpbmcgbGlz dA0KPiBSb2xsQGlldGYub3JnPGh0dHA6Ly9nci5tYzI5Ni5tYWlsLnlhaG9vLmNvbS9tYy9jb21w b3NlP3RvPVJvbGxAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcm9sbA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpSb2xsIG1haWxpbmcgbGlzdA0KUm9sbEBpZXRmLm9yZzxodHRwOi8vZ3IubWMyOTYu bWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1Sb2xsQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQoNCg0K --_000_5AC33E4372B04317A4BA030855BA6B45wattecocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsgIj5IaSwmbmJzcDs8ZGl2Pjxicj48L2Rpdj48ZGl2PlNlZSBpbmxpbmUuPC9kaXY+PGRp dj48YnI+PGRpdj48ZGl2PkxlIDUgYW/Du3QgMjAxMSDDoCAwMTo1OCwgUGFub3MgVHJha2FkYXMg YSDDqWNyaXQgOjwvZGl2PjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+PGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHRhYmxlIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0i MCIgYm9yZGVyPSIwIiBzdHlsZT0icG9zaXRpb246IHN0YXRpYzsgei1pbmRleDogYXV0bzsgIj48 dGJvZHk+PHRyPjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9ImZvbnQ6IGluaGVyaXQ7Ij5EZWFyIENl ZHJpYyw8YnI+PGJyPldlIGJlbGlldmUgdGhhdCB0aGUgZGVmaW5pdGlvbiBvZiAib3JkZXIgcmVs YXRpb24iIGlzIGNvcnJlY3Q6IHRoZSBvcmRlciByZWxhdGlvbiBpcyB1c2VkIGJ5IHRoZSBPRiB0 byBjb21wYXJlIGxpbmsvbm9kZSB3ZWlnaHRzIGFsb25nIHRoZSBwYXRoIChlcXVpdmFsZW50bHks IG1ldHJpYyB2YWx1ZXMpIGFuZCBzZWxlY3QgcGFyZW50IG5vZGUuIDxicj48YnI+PGJyPltDLkNd IEkgQWdyZWUgd2l0aCB5b3VyIGRlZmluaXRpb24uPGJyPjxicj5BcyBhbiBleGFtcGxlLCBjb25z aWRlciB0aGUgY2FzZSB3aGVyZSB0aGUgRVRYIGlzIGFnZ3JlZ2F0ZWQgYWxvbmcgdGhlIHRyYXZl cnNlZCBwYXRoLiBJZiBub2RlIEEgcmVjZWl2ZXMgRElPIG1lc3NhZ2VzIGZyb20gbm9kZXMgQiBh bmQgQyAocG90ZW50aWFsIHBhcmVudHMpIHdpdGggRVRYIHZhbHVlcyBvZiAyLjUgYW5kIDMuMiwg cmVzcGVjdGl2ZWx5LCB0aGVuIHRoZSBvcmRlciByZWxhdGlvbiB3aWxsIGhlbHAgc2VsZWN0aW5n IG5vZGUgQiAoYWR2ZXJ0aXNpbmcgdGhlIG1pbmltdW0gdmFsdWUgb2YgRVRYKSBhcyB0aGUgcGFy ZW50IG9mIG5vZGUgQS48YnI+SW4gdGhpcyBjb25jZXB0LCB5b3VyIGNvbW1lbnQgaXMgcmlnaHQ7 IHRoZSBvcmRlciByZWxhdGlvbiBvZiBMUUwgbXVzdCBiZSBtaW5pbXVtIChhbmQgbm90IG1heGlt dW0pLiBQbGVhc2UgY29uc2lkZXIgaXQgYXMgYSB0eXBvLjxicj48dGFibGUgY2VsbHNwYWNpbmc9 IjAiIGNlbGxwYWRkaW5nPSIwIiBib3JkZXI9IjAiIHN0eWxlPSJwb3NpdGlvbjogc3RhdGljOyB6 LWluZGV4OiBhdXRvOyAiPjx0Ym9keT48dHI+PHRkIHZhbGlnbj0idG9wIiBzdHlsZT0iZm9udDog aW5oZXJpdDsgIj48YnI+PC90ZD48L3RyPjwvdGJvZHk+PC90YWJsZT48dGFibGUgY2VsbHNwYWNp bmc9IjAiIGNlbGxwYWRkaW5nPSIwIiBib3JkZXI9IjAiIHN0eWxlPSJwb3NpdGlvbjogc3RhdGlj OyB6LWluZGV4OiBhdXRvOyAiPjx0Ym9keT48dHI+PHRkIHZhbGlnbj0idG9wIiBzdHlsZT0iZm9u dDogaW5oZXJpdDsgIj5bQy5DXSBPSzwvdGQ+PC90cj48L3Rib2R5PjwvdGFibGU+PGRpdj48ZGl2 Pjxicj48L2Rpdj48L2Rpdj48ZGl2Pjxicj48L2Rpdj5SZWdhcmRpbmcgbGluay1jb2xvciBjb21t ZW50OiBBcGFydCBmcm9tIGJlaW5nIHVzZWQgYXMgYSAxMC1iaXQgZmxhZyBmaWVsZCAoZS5nLiBm b3IgaW5kaWNhdGluZyB0aGUgZW5jcnlwdGVkIGxpbmtzLCBhcyBkZXNjcmliZWQgaW4gcnBsLW1l dHJpY3MgZHJhZnQpLCBsaW5rIGNvbG9yIG1heSBiZSB1c2VkIHRvIGluZGljYXRlIHRoZQ0KIG51 bWJlciBvZiBub2RlcyBhbG9uZyB0aGUgcGF0aCB0cmFuc21pdHRpbmcgYXQgYSBzcGVjaWZpYyBy YWRpbyBjaGFubmVsOyBpbiB0aGlzIHdheSBpbnRlcmZlcmVuY2UgY2FuIGJlIHJlZHVjZWQgYnkg c2VsZWN0aW5nIHRyYW5zbWlzc2lvbiBpbiB0aGUgImxlYXN0IG9jY3VwaWVkIiBjaGFubmVsLiBJ biB0aGlzIGNhc2UsIHRoZSBvcmRlciByZWxhdGlvbiBtdXN0IGJlICJtaW5pbXVtIiBhbmQgdGhl IGRvbWFpbiBpcyBpbnRlZ2VyLjxicj48YnI+W0MuQ10gSSB0aGluayB0aGF0IHRoZSBjb25mdXNp b24gaXMgZ3JlYXRseSBkdWUgdG8gdGhlIHZlcnkgd2lkZSByYW5nZSB0aGF0IHRoZSBsaW5rIGNv bG9yIG1ldHJpYyBtYXkgY292ZXIuIFlvdSBleGFtcGxlIG9mIHRoZSB1c2FnZSBvZiB0aGlzIG1l dHJpYyBpcyBpbnRlcmVzdGluZywgYnV0IG1hbnkgb3RoZXJzIHVzYWdlIG1heSBiZSBwb3NzaWJs ZSwgYW5kIHNvIGFuIGdsb2JhbCBvcmRlciByZWxhdGlvbiBzZWVtcyBkaWZmaWN1bHQgdG8gZmlu ZCBmb3IgdGhpcyBtZXRyaWMuPGJyPjxicj5JbiBnZW5lcmFsLCB3ZSB3aWxsIHJlLWZvcm1hdCBU YWJsZSAxLCBmb2xsb3dpbmcgdGhlIG1ldHJpYyBkZXNjcmlwdGlvbiBpbiBycGwtbWV0cmljcyBk cmFmdC4gQWxzbywgd2Ugd2lsbCByZXBsYWNlIHdvcmRzICJtaW5pbXVtIi8ibWF4aW11bSIgaW4g dGhlICJvcmRlciByZWxhdGlvbiIgY29sdW1uIGJ5ICJsZXNzLXRoYW4iIGFuZCAiZ3JlYXRlci10 aGFuIiBpbiBhY2NvcmRhbmNlIHRvIHRoZSBvcmRlciByZWxhdGlvbiBkZWZpbml0aW9uLjxicj48 YnI+W0MuQ10gSSBhZ3JlZSB0aGF0IGl0IHdvdWxkIGluY3JlYXNlIHRoZSByZWFkYWJpbGl0eS48 YnI+PGJyPkJlZm9yZSBzdWJtaXR0aW5nIHRoaXMgZHJhZnQsIHRoZXJlIHdhcyBhIGRpc2N1c3Np b24gb24gd2hldGhlciB3ZSBzaG91bGQgaW5jbHVkZSBleGFtcGxlcyBhbmQgZm9ybXVsYXMgaW4g dGhpcyBpbml0aWFsIHZlcnNpb24gb2YgdGhlIGRvY3VtZW50OyBpdCBzZWVtcyB0aGF0IG91ciBk ZWNpc2lvbiB3YXMgd3JvbmcuLi4gV2Ugd2lsbCBiZSBoYXBweSB0byBpbmNsdWRlIGV4YW1wbGVz IGFuZCBmb3JtdWxhcyB0byBpbXByb3ZlIHJlYWRhYmlsaXR5IG9mIHRoaXMgZHJhZnQuPGJyPjxi cj5bQy5DXSBOaWNlLiBJIHRoaW5rIHRoaXMgd291bGQgcHJvdmlkZSBwcmVjaW91cyBndWlkZWxp bmVzIGZvciByZWFkZXJzLCBhbmQgc3BlZWQgdXAgc29tZSBSUEwgZGVzaWduLjxicj48YnI+Rmlu YWxseSwgd2UgdGhpbmsgdGhhdCAiaHlzdGVyZXNpcyIgY2FuIHByb3ZhYmx5IGltcHJvdmUgUlBM IHBlcmZvcm1hbmNlLCBhbmQgdGh1cyBpdCB3aWxsIGJlIGluY2x1ZGVkIGluIHRoaXMgZHJhZnQu IFRvIGJlIGhvbmVzdCwgdGhlcmUgaXMgYSAiaGlkZGVuIiBwaHJhc2U6ICIuLi5hbmQNCiBpZiB0 aGUgZmlyc3QgY29tcG9uZW50IHZhbHVlcyBhcmUgZXF1YWwgKm9yIGRpZmZlciBsZXNzIHRoYW4g YSBwcmVkZWZpbmVkIHRocmVzaG9sZCouLi4iIChzZWN0aW9uIDQuMSwgZmlyc3Qgc2VudGVuY2Up IGluZGljYXRpbmcgb3VyIGVmZm9ydCB0byBpbmNsdWRlIGh5c3RlcmVzaXMgaW4gdGhpcyBkcmFm dC4gV2Ugd2lsbCBnaXZlIG1vcmUgZW1waGFzaXMgb24gdGhhdCBwb2ludC48YnI+PGJyPltDLkNd IEkgbm90aWNlZCB0aGF0IHJlZmVyZW5jZSwgYnV0IGl0IHNob3VsZCBiZSB3b3J0aCB0byBleHBs aWNpdGx5IHNwZWFrIGFib3V0IGl0LiBJIGFsc28gYWdyZWUgdGhhdCB0aGUgSHlzdGVyZXNpcyBt ZWNoYW5pc20gZGVmaW5lZCBpbiB0aGUgTVJIT0YgZHJhZnQgZ3JlYXRseSBpbXByb3ZlIHRoZSBz dGFiaWxpdHkgb2YgdGhlIHRvcG9sb2d5IGFuZCBzaG91bGQgYmUgaGlnaGx5IHJlY29tbWVuZGVk LiBCVFcsIHNvbWUgZ3VpZGVsaW5lcyBhYm91dCBob3cgdG8gZGV0ZXJtaW5lIHRoZSBnb29kIHRo cmVzaG9sZCB2YWx1ZSB3b3VsZCBiZSBpbnRlcmVzdGluZy48YnI+PGJyPlRoYW5rcyBmb3IgeW91 ciB2YWx1YWJsZSBjb21tZW50cyw8YnI+UGFub3MuPGJyPjxicj5Dw6lkcmljLjxicj48YnI+PGJy Pi0tLSDOo8+EzrnPgiA8Yj7OpM61z4QuLCAwMy8wOC8xMSwgzr8vzrcgQyBDaGF1dmVuZXQgPGk+ Jmx0OzxhIGhyZWY9Im1haWx0bzpjLmNoYXV2ZW5ldEB3YXR0ZWNvLmNvbSI+Yy5jaGF1dmVuZXRA d2F0dGVjby5jb208L2E+Jmd0OzwvaT48L2I+IM6tzrPPgc6xz4jOtTo8YnI+DQo8YmxvY2txdW90 ZSBzdHlsZT0iUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZU OiByZ2IoMTYsMTYsMjU1KSAycHggc29saWQiPjxicj7Okc+Az4w6IEMgQ2hhdXZlbmV0ICZsdDs8 YSBocmVmPSJtYWlsdG86Yy5jaGF1dmVuZXRAd2F0dGVjby5jb20iPmMuY2hhdXZlbmV0QHdhdHRl Y28uY29tPC9hPiZndDs8YnI+zpjOrc68zrE6IFJlOiBbUm9sbF0gRlc6IE5ldyBJLUQgb24gY29t cG9zaXRlIHJvdXRpbmcgbWV0cmljczxicj7OoM+Bzr/PgjogIjxhIGhyZWY9Im1haWx0bzp6YWhh cmlhZEB0ZWloYWwuZ3IiPnphaGFyaWFkQHRlaWhhbC5ncjwvYT4iICZsdDs8YSBocmVmPSJtYWls dG86emFoYXJpYWRAdGVpaGFsLmdyIj56YWhhcmlhZEB0ZWloYWwuZ3I8L2E+Jmd0Ozxicj7Oms6/ zrnOvS46ICJUUkFLQURBUyBQQU5PUyIgJmx0OzxhIGhyZWY9Im1haWx0bzp0cmFrYWRhc3BAYWRh ZS5nciI+dHJha2FkYXNwQGFkYWUuZ3I8L2E+Jmd0OywgIjxhIGhyZWY9Im1haWx0bzpyb2xsQGll dGYub3JnIj5yb2xsQGlldGYub3JnPC9hPiIgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2xsQGlldGYu b3JnIj5yb2xsQGlldGYub3JnPC9hPiZndDs8YnI+zpfOvM61z4HOv868zrfOvc6vzrE6IM6kzrXP hM6sz4HPhM63LCAzIM6Rz43Os86/z4XPg8+Ezr/PgiAyMDExLCAxODo0Njxicj48YnI+DQo8ZGl2 IGNsYXNzPSJwbGFpbk1haWwiPkhpIFRoZW9kb3JlLCA8YnI+PGJyPkkgZm91bmQgeW91ciBkcmFm dCBpbnRlcmVzdGluZyBhbmQgaXQgZ2F2ZSBtZSBzb21lIHVzZWZ1bCBndWlkZWxpbmVzIGZvciBt ZXRyaWMncyBkZXNpZ24uPGJyPjxicj5JJ3ZlIHNldmVyYWwgY29tbWVudHMgb24gdGhpcyA6IDxi cj48YnI+SSBmYWlsIHRvIHVuZGVyc3RhbmQgd2VsbCB0aGUgIk9yZGVyIFJlbGF0aW9uIiB5b3Ug dXNlIGluIFRhYmxlIDEuPGJyPlRoZSBkZWZpbml0aW9uIG9mICJtZXRyaWMgb3JkZXIgcmVsYXRp b24iIGdpdmVuIG9uIHBhZ2UgNCBkb2Vzbid0IHJlYWxseSBoZWxwZWQgbWUuPGJyPkNvdWxkIHlv dSBoZWxwIG1lIHVuZGVyc3RhbmQgdGhlIE9yZGVyIFJlbGF0aW9uIGNvbHVtbiBpbiB0aGUgdGFi bGU/PGJyPjxicj5JbiB0aGlzIHRhYmxlIGluIHBhcnRpY3VsYXIgKEZpZ3VyZSAxKTogPGJyPjxi cj4mbmJzcDsmbmJzcDsmbmJzcDsgLSBDb3VsZCB5b3UgcHJlY2lzZSB5b3VyIHZpZXcgb2YgdGhl Jm5ic3A7IExpbmstQ29sb3IgbWV0cmljIChXaHkgaXMgaXQgaW4gdGhlIGludGVnZXIgZG9tYWlu LCB3aHkgdGhlIG9yZGVyIHJlbGF0aW9uIGluICJtaW5pbXVtIiA/KS48YnI+PGJyPiZuYnNwOyZu YnNwOyZuYnNwOyAtIEFzIGZhciBhcyBJIHVuZGVyc3RhbmQgdGhlIE9yZGVyIFJlbGF0aW9uLCBp dCBzZWVtcyB0aGF0IHRoZSBMUUwgb3JkZXIgcmVsYXRpb24gc2hvdWxkIG5vdCBiZSAibWF4aW11 bSIgYnV0IHJhdGhlciAibWluaW11bSIgKHNhbWUgcmVsYXRpb24gYXMgRVRYLCBleGNsdWRpbmcg dGhlIDAgdmFsdWUpLjxicj48YnI+PGJyPk1vcmUgZ2VuZXJhbGx5LCBJIHdvdWxkIGJlIGhhcHB5 IHRvIHNlZSBpbiB0aGUgZG9jdW1lbnQgc29tZSBmb3JtdWxhcyBleGFtcGxlcyBmb3IgbWV0cmlj IGNvbXB1dGF0aW9uLCBvciBtYXliZSBzb21lIGd1aWRlbGluZXMuPGJyPjxicj5Tb21lDQogZXhh bXBsZSBvZiBtZXRyaWNzIGNvbXBvc2l0aW9uIHdvdWxkIGFsc28gYmUgZ3JlYXQgKFlvdSBtZW50 aW9uIG9uZSBpbiB5b3VyIGRyYWZ0IHdpdGggaXMgRVRYICsgUkUgKHJlbWFpbmdpbmcgRW5lcmd5 KS4gRG8geW91IGhhdmUgc29tZSBpZGVhIGFib3V0IG90aGVyIHNldCBvZiBtZXRyaWMgdGhhdCB3 b3VsZCBiZSBpbnRlcmVzdGluZyB0byBiaW5kID88YnI+PGJyPkkgZmluYWxseSB0aGluayB0aGF0 IGl0IHNob3VsZCBiZSB3b3J0aCB0byBhZGQgc29tZSBjb250ZW50IGFib3V0IHRoZSBtZWNoYW5p c21zIHRoYXQgYWltIHRvIGRlYWwgd2l0aCBtZXRyaWMncyBkeW5hbWljcyAoTXVsdGkgVGhyZXNo b2xkLCBFV01BLCBMb3cgcGFzcyBGaWx0ZXJzLCAuLi4pLiBTb21lIG9mIHRoZW0gYXJlIG1lbnRp b25lZCBhdCB0aGUgZW5kIG9mIHRoZSBycGwgbWV0cmljIGRyYWZ0Ljxicj48YnI+QmVzdCw8YnI+ PGJyPkPDqWRyaWMuPGJyPjxicj5MZSAyIGFvw7t0IDIwMTEgw6AgMDI6NTUsIFRoZW9kb3JlIFph aGFyaWFkaXMgYSDDqWNyaXQgOjxicj48YnI+Jmd0OyBEZWFyIGFsbCw8YnI+Jmd0OyBNeSBjb2xs ZWFndWUgRHIuIFBhbm9zIFRyYWthZGFzIGFuZCBteXNlbGYgYXJlIHdvcmtpbmcgb24gYW4gRUMt ZnVuZGVkPGJyPiZndDsgcmVzZWFyY2ggcHJvamVjdCwgY2FsbGVkIFZJVFJPIChWaXJ0dWFsaXpl ZCBEaXN0cmlidXRlZCBwbGF0Zm9ybSBvZiBTbWFydDxicj4mZ3Q7IG9iamVjdHMgLSA8YSBocmVm PSJodHRwOi8vd3d3LnZpdHJvLWZwNy5ldS8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LnZp dHJvLWZwNy5ldS88L2E+KSwgd2hpY2ggaGFzIGFkb3B0ZWQgUlBMIGFzIHRoZSBwcmltYXJ5PGJy PiZndDsgcm91dGluZyBwcm90b2NvbCBhbmQgd2UgYXJlIGN1cnJlbnRseSBwZXJmb3JtaW5nIHNv bWUgc2ltdWxhdGlvbnMgYW5kIHRlc3RzLjxicj4mZ3Q7IDxicj4mZ3Q7IEJ5DQogbW9uaXRvcmlu ZyByb2xsLCB3ZSBoYXZlIG5vdGljZWQgdGhhdCB0aHJlZSAoc29ycnkgaWYgd2UgaGF2ZSBtaXNz ZWQgYW55KTxicj4mZ3Q7IEktRCBhcmUgZGlzY3Vzc2VkIGluIHRoZSBST0xMIFdHIChkcmFmdC1p ZXRmLXJvbGwtbWlucmFuay1oeXN0ZXJlc2lzLW9mLDxicj4mZ3Q7IGRyYWZ0LWlldGYtcm9sbC1v ZjAsIGRyYWZ0LWduYXdhbGktcm9sbC1ldHhvZiksIGRlZmluaW5nIFJQTCBPYmplY3RpdmU8YnI+ Jmd0OyBGdW5jdGlvbnMgcmVsYXRlZCB0byBhIHNpbmdsZSByb3V0aW5nIG1ldHJpYyAoZWl0aGVy IGhvcC1jb3VudCBvciBFVFgpLjxicj4mZ3Q7IDxicj4mZ3Q7IEluIFZJVFJPLCBlYWNoIHNlbnNv ciBtYXkgYmUgcGFydCBvZiBtYW55IHZpcnR1YWwgbmV0d29ya3MgKGV2ZW4gZnJvbTxicj4mZ3Q7 IGRpZmZlcmVudCBhZG1pbmlzdHJhdGl2ZSBkb21haW5zKSBhbmQgbXVzdCBiZSBhYmxlIHRvIGNv bmN1cnJlbnRseSBzdXBwb3J0PGJyPiZndDsgbXVsdGlwbGUgdXNlciByZXF1ZXN0cyBldmVuIHdp dGggY29udHJhZGljdGluZyBRb1MgY2hhcmFjdGVyaXN0aWNzLiBJdCBpczxicj4mZ3Q7IG9idmlv dXMgdGhhdCBpbiBzdWNoIGNhc2VzLCBhIGNvbXBvc2l0ZSByb3V0aW5nIG1ldHJpYyBpcyBvZiBn cmVhdDxicj4mZ3Q7IGltcG9ydGFuY2UuPGJyPiZndDsgPGJyPiZndDsgSW4gZHJhZnQtemFoYXJp YWRpcy1yb2xsLW1ldHJpY3MtY29tcG9zaXRpb24tMDA8YnI+Jmd0OyAoPGEgaHJlZj0iaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16YWhhcmlhZGlzLXJvbGwtbWV0cmljcy1j b21wb3NpdGlvbi8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXphaGFyaWFkaXMtcm9sbC1tZXRyaWNzLWNvbXBvc2l0aW9uLzwvYT4pPGJyPiZn dDsgLCB3ZSBhaW0gYXQgc3BlY2lmeWluZyB0aGUgZ3VpZGVsaW5lcyBmb3INCiBkZXNpZ25pbmcg ZWZmaWNpZW50IGNvbXBvc2l0ZTxicj4mZ3Q7IHJvdXRpbmcgbWV0cmljcyB0byBiZSBhcHBsaWVk IGF0IFJQTCByb3V0aW5nIHByb3RvY29sLjxicj4mZ3Q7Jm5ic3A7IDxicj4mZ3Q7IFdlIHdvdWxk IGJlIGhhcHB5IHRvIHJlY2VpdmUgeW91ciBjb21tZW50czxicj4mZ3Q7Jm5ic3A7IDxicj4mZ3Q7 IEJlc3QgUmVnYXJkcyw8YnI+Jmd0OyBUaGVvZG9yZSBaYWhhcmlhZGlzPGJyPiZndDsgPGJyPiZn dDsgPGJyPiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPiZndDsg QXNzLiBQcm9mLiBUaGVvZG9yZSBaYWhhcmlhZGlzLCBQaEQ8YnI+Jmd0OyBUZWNobm9sb2dpY2Fs IEVkdWNhdGlvbmFsIEluc3RpdHV0ZSBvZiBDaGFsa2lkYTxicj4mZ3Q7IFBzYWNobmEsIENoYWxr aWRhLCBHcmVlY2U8YnI+Jmd0OyBUZWw6ICszMCAyMjI4MCA5OTU1MCwgKzMwIDY5MzI0OTUwNDU8 YnI+Jmd0OyBTa3lwZTogdGhlb2RvcmUuemFoYXJpYWRpczxicj4mZ3Q7IDxicj4mZ3Q7IDxicj4m Z3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZn dDsgUm9sbCBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyA8YSBocmVmPSJodHRwOi8vZ3IubWMyOTYubWFp bC55YWhvby5jb20vbWMvY29tcG9zZT90bz1Sb2xsQGlldGYub3JnIiB5bWFpbHRvPSJtYWlsdG86 Um9sbEBpZXRmLm9yZyI+Um9sbEBpZXRmLm9yZzwvYT48YnI+Jmd0OyA8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGw8L2E+PGJyPjxicj48YnI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Um9sbCBtYWls aW5nIGxpc3Q8YnI+PGEgaHJlZj0iaHR0cDovL2dyLm1jMjk2Lm1haWwueWFob28uY29tL21jL2Nv bXBvc2U/dG89Um9sbEBpZXRmLm9yZyIgeW1haWx0bz0ibWFpbHRvOlJvbGxAaWV0Zi5vcmciPlJv bGxAaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcm9sbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcm9sbDwvYT48YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjwvdGQ+PC90cj48L3Ri b2R5PjwvdGFibGU+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_5AC33E4372B04317A4BA030855BA6B45wattecocom_-- From trakadasp@yahoo.gr Sun Aug 7 02:58:07 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7993E21F8511 for ; Sun, 7 Aug 2011 02:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9r0M4ot90jxq for ; Sun, 7 Aug 2011 02:58:06 -0700 (PDT) Received: from nm17.bullet.mail.ird.yahoo.com (nm17.bullet.mail.ird.yahoo.com [77.238.189.70]) by ietfa.amsl.com (Postfix) with SMTP id 059F321F8505 for ; Sun, 7 Aug 2011 02:58:05 -0700 (PDT) Received: from [77.238.189.48] by nm17.bullet.mail.ird.yahoo.com with NNFMP; 07 Aug 2011 09:58:22 -0000 Received: from [212.82.108.125] by tm1.bullet.mail.ird.yahoo.com with NNFMP; 07 Aug 2011 09:58:22 -0000 Received: from [127.0.0.1] by omp1034.mail.ird.yahoo.com with NNFMP; 07 Aug 2011 09:58:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 241905.75179.bm@omp1034.mail.ird.yahoo.com Received: (qmail 34049 invoked by uid 60001); 7 Aug 2011 09:58:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.gr; s=s1024; t=1312711102; bh=IrSOTHkbfzZvXGay1yO2e0qV/eZmu7SUJjND8edHlQM=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=2ceNeHNqjp/btN3PxxL9hJB4ur6UAxjs2o29plOP1kBVQ0UHPfg87kLGZixT0CrUAe1i9UIRbxGOnWTCkQd0Y4vcMNKApMXf+mQ8nNljjb+3KNf9XVnnmISFZMigc9kx8cU+tyihPbHJAG6+rewyKSQum9ELEbHWlPhtxwNH5uI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.gr; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=iCTLwhCfA2uxW3g4CNUZ0qwyTTXtLlpEjymO1cCMBJ5+Iup3yd0U00rB49rVOjjpmAriZaEV51GHdhiMy8HbwcO4I/4uTl6kBr/4BOlfA7XMxPEFomo7XkVdFzNWaL/Kp/xL2KdbvtV3NbtfpXjNaX/F/HHL4tf4r3dBaQpI+yQ=; X-YMail-OSG: e4TzNgEVM1kNE.WhODsQcXwn83DYmgwV9HrG2ee0sN1ZFiZ Ss3IzwShJ9su2j0D4WF6WHLMTxKBEuIsVqNiymIeQ8AO5dw0bwmZmH1e0fdA i7_JcyUkhEXgMzqhz.bwpEGyqwQjfbLiomZ.hajEFYD23yonuKW__pP_UzAD vUPS_zYsW5gBU1IkvA0JMgol2p6WtMkW4mJPlYQtR.piAM7zUCiZDxLgvMVb nwTNV1y3y6tNmPPnpKqTw13zV3Nij8hSmfiL0.DijrCqv7dB70moRBIElspP 13js5aYeRyFZ2fKu8ANe18UyE5Nr73oY2B9NTQY7rf.BbcSi5h.n6lk2Fbn5 uvZb_BvuV3uMVr_rdyu78_dXNTUMNY44eRxPf23TuvDcY2f25DbGFb5JVauo FDxnDW7yY78Otx6rsH.S1f76S0I.SGooHSfM3Bd0xgS0SXcsAGcM4oypjPrF wS0XKFtM.NSWQT8xpm59F_okY1ZbDkZzdCfXMRGTEi0FAyiAlXDQuEYh.dPj oakVoH6j3GoLtu1bqyUvaHbj8XwyRLpJKthVtWg-- Received: from [213.249.15.131] by web29605.mail.ird.yahoo.com via HTTP; Sun, 07 Aug 2011 10:58:21 BST X-Mailer: YahooMailWebService/0.8.113.313619 Message-ID: <1312711101.34041.YahooMailMobile@web29605.mail.ird.yahoo.com> Date: Sun, 7 Aug 2011 10:58:21 +0100 (BST) From: Panos Trakadas To: C Chauvenet MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-513987289-1312711101=:34041" Cc: roll@ietf.org Subject: [Roll] =?utf-8?b?zqPPh861z4Q6IFJlOiAgRlc6IE5ldyBJLUQgb24gY29tcG9z?= =?utf-8?q?ite_routing_metrics?= X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2011 09:58:07 -0000 --0-513987289-1312711101=:34041 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Cedric,=0AWe will take into consideration your comments in the newer ver= sion of our draft.=0AFurthermore, we are developing RPL for JSim simulation= platform (hopefully it will be ready by mid August).=0AWe could benefit fr= om this simulator towards many directions such as evaluation of several QoS= composite metrics, experimentation with multiple application-specific inst= ances, as well as accurate estimation on hysteresis threshold.=0ABest regar= ds,=0ATheodore and Panos. --0-513987289-1312711101=:34041 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Cedric,
We will take into conside= ration your comments in the newer version of our draft.
Furthermore, w= e are developing RPL for JSim simulation platform (hopefully it will be rea= dy by mid August).
We could benefit from this simulator towards many d= irections such as evaluation of several QoS composite metrics, experimentat= ion with multiple application-specific instances, as well as accurate estim= ation on hysteresis threshold.
Best regards,
Theodore and Panos.<= /div>
=0A =
=0A=
=0A
=0A = =0A =0A =0A = From:=0A = =0A C Chauvenet <c.chauvenet@watt= eco.com>;
=0A = =0A To:= =0A =0A Pa= nos Trakadas <trakadasp@yahoo.gr>; =
=0A =0A = Cc:=0A = =0A zahariad@teihal.gr <z= ahariad@teihal.gr>; roll@ietf.org <roll@ietf.org>; =
=0A = =0A Subject:=0A =0A = Re: [Roll] FW: New I-D on composite routing metrics=
=0A =0A = Sent:=0A= =0A Sat, Aug 6, = 2011 2:29:35 PM
=0A = =0A
=0A = =0A = =0A =0A = =


Regarding link-color comment: Ap= art from being used as a 10-bit flag field (e.g. for indicating the encrypt= ed links, as described in rpl-metrics draft), link color may be used to ind= icate the number of nodes along the path transmitting at a specific radio channel; i= n this way interference can be reduced by selecting transmission in the &qu= ot;least occupied" channel. In this case, the order relation must be &= quot;minimum" and the domain is integer.

[C.C] I think that the= confusion is greatly due to the very wide range that the link color metric= may cover. You example of the usage of this metric is interesting, but man= y others usage may be possible, and so an global order relation seems diffi= cult to find for this metric.

In general, we will re-format Table 1,= following the metric description in rpl-metrics draft. Also, we will repla= ce words "minimum"/"maximum" in the "order relatio= n" column by "less-than" and "greater-than" in acc= ordance to the order relation definition.

[C.C] I agree that it woul= d increase the readability.

Before submitting this draft, there was a discussion on whether we should include examples and formulas = in this initial version of the document; it seems that our decision was wro= ng... We will be happy to include examples and formulas to improve readabil= ity of this draft.

[C.C] Nice. I think this would provide precious g= uidelines for readers, and speed up some RPL design.

Finally, we thi= nk that "hysteresis" can provably improve RPL performance, and th= us it will be included in this draft. To be honest, there is a "hidden= " phrase: "...and if the first component values are equal *or differ less than a predefined = threshold*..." (section 4.1, first sentence) indicating our effort to = include hysteresis in this draft. We will give more emphasis on that point.=

[C.C] I noticed that reference, but it should be worth to explicitl= y speak about it. I also agree that the Hysteresis mechanism defined in the= MRHOF draft greatly improve the stability of the topology and should be hi= ghly recommended. BTW, some guidelines about how to determine the good thre= shold value would be interesting.

Thanks for your valuable comments,=
Panos.

C=C3=A9dric.


--- =CE=A3=CF=84=CE=B9=CF=82 = =CE=A4=CE=B5=CF=84., 03/08/11, =CE=BF/=CE=B7 C Chauvenet <c.chauvenet@watteco.com> =CE=AD=CE=B3= =CF=81=CE=B1=CF=88=CE=B5:

=CE=91=CF=80=CF=8C: C Chauvenet <c.chauvenet@watteco.com>
=CE=98=CE=AD=CE=BC=CE=B1= : Re: [Roll] FW: New I-D on composite routing metrics
=CE=A0=CF=81=CE=BF= =CF=82: "zahariad@teihal.gr" <= zahariad@teihal.gr>
=CE=9A=CE=BF=CE= =B9=CE=BD.: "TRAKADAS PANOS" <traka= dasp@adae.gr>, "roll@ietf.org" = <roll@ietf.org>
=CE=97=CE=BC=CE=B5=CF= =81=CE=BF=CE=BC=CE=B7=CE=BD=CE=AF=CE=B1: =CE=A4=CE=B5=CF=84=CE=AC=CF=81=CF= =84=CE=B7, 3 =CE=91=CF=8D=CE=B3=CE=BF=CF=85=CF=83=CF=84=CE=BF=CF=82 2011, 1= 8:46

Hi Theodore,

I found your draft interestin= g and it gave me some useful guidelines for metric's design.

I&#= 39;ve several comments on this :

I fail to understand well the &quo= t;Order Relation" you use in Table 1.
The definition of "metri= c order relation" given on page 4 doesn't really helped me.
Cou= ld you help me understand the Order Relation column in the table?

In= this table in particular (Figure 1):

    - Could yo= u precise your view of the  Link-Color metric (Why is it in the intege= r domain, why the order relation in "minimum" ?).

 &n= bsp;  - As far as I understand the Order Relation, it seems that the L= QL order relation should not be "maximum" but rather "minimu= m" (same relation as ETX, excluding the 0 value).


More gene= rally, I would be happy to see in the document some formulas examples for metric computation, or maybe some guidelines.

Some example of metrics composition would also be great (You mention one in you= r draft with is ETX + RE (remainging Energy). Do you have some idea about o= ther set of metric that would be interesting to bind ?

I finally thi= nk that it should be worth to add some content about the mechanisms that ai= m to deal with metric's dynamics (Multi Threshold, EWMA, Low pass Filte= rs, ...). Some of them are mentioned at the end of the rpl metric draft.
Best,

C=C3=A9dric.

Le 2 ao=C3=BBt 2011 =C3=A0 02:55, The= odore Zahariadis a =C3=A9crit :

> Dear all,
> My colleague = Dr. Panos Trakadas and myself are working on an EC-funded
> research = project, called VITRO (Virtualized Distributed platform of Smart
> ob= jects - http://www.vitro-fp7.eu/), which has adopted RPL as the primary> routing protocol and we are currently performing some simulations and= tests.
>
> By monitoring roll, we have noticed that three (sorry if we have missed any)<= br>> I-D are discussed in the ROLL WG (draft-ietf-roll-minrank-hysteresi= s-of,
> draft-ietf-roll-of0, draft-gnawali-roll-etxof), defining RPL = Objective
> Functions related to a single routing metric (either hop-= count or ETX).
>
> In VITRO, each sensor may be part of many v= irtual networks (even from
> different administrative domains) and mu= st be able to concurrently support
> multiple user requests even with= contradicting QoS characteristics. It is
> obvious that in such case= s, a composite routing metric is of great
> importance.
>
&= gt; In draft-zahariadis-roll-metrics-composition-00
> (http://datatracker.ietf.org/doc/draft-zaha= riadis-roll-metrics-composition/)
> , we aim at specifying the guidelines for designing efficient composite
> routing metrics to be applied at RPL= routing protocol.
> 
> We would be happy to receive your= comments
> 
> Best Regards,
> Theodore Zahariadis<= br>>
>
> ------------------------------------
> Ass.= Prof. Theodore Zahariadis, PhD
> Technological Educational Institute= of Chalkida
> Psachna, Chalkida, Greece
> Tel: +30 22280 99550= , +30 6932495045
> Skype: theodore.zahariadis
>
>
&g= t; _______________________________________________
> Roll mailing lis= t
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


________= _______________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mail= man/listinfo/roll
Hi, 

See inline.

Le 5 ao= =C3=BBt 2011 =C3=A0 01:58, Panos Trakadas a =C3=A9crit :

<= td valign=3D"top" style=3D"font:inherit;">
Dear Cedric,

We believe that the definition = of "order relation" is correct: the order relation is used by the= OF to compare link/node weights along the path (equivalently, metric value= s) and select parent node.


[C.C] I Agree with your definition.<= br>
As an example, consider the case where the ETX is aggregated along t= he traversed path. If node A receives DIO messages from nodes B and C (pote= ntial parents) with ETX values of 2.5 and 3.2, respectively, then the order= relation will help selecting node B (advertising the minimum value of ETX)= as the parent of node A.
In this concept, your comment is right; the order relation of L= QL must be minimum (and not maximum). Please consider it as a typo.
[C.C] OK

=0A = =0A =0A <= /table>=0A
=0A =0A = =0A --0-513987289-1312711101=:34041-- From rdroms.ietf@gmail.com Mon Aug 8 16:23:50 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8E221F8B57; Mon, 8 Aug 2011 16:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfUn-cM-Gyir; Mon, 8 Aug 2011 16:23:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0477421F8B3D; Mon, 8 Aug 2011 16:23:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Ralph Droms To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110808232350.30897.61741.idtracker@ietfa.amsl.com> Date: Mon, 08 Aug 2011 16:23:50 -0700 Cc: roll@ietf.org, draft-ietf-roll-of0@tools.ietf.org, roll-chairs@tools.ietf.org Subject: [Roll] Ralph Droms' Discuss on draft-ietf-roll-of0-15: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 23:23:51 -0000 Ralph Droms has entered the following ballot position for draft-ietf-roll-of0-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 1. I would like to discuss the interoperability and deployability of nodes in a RPL Instance that uses OF0. If I understand section 4.1 correctly, a node is free to compute step-of-rank using any method it chooses. There is a suggestion that using link properties for the computation is preferred, but the specific link properties and the method of computation are not specified. Later, section 4.1 defines two parameters, rank_factor and stretch_factor, that modify step_of_rank to generate a "stretched step_of_rank". The latter value is then multiplied by the MinHopRankIncrease to compute the node's rank_increase. My concern is the degrees of freedom provided to the implementation in the computation of rank_increase. I'm hoping I can get an explanation of some reason to believe that independent implementations, using different methods to compute step_of_rank and potentially different configured values for rank_factor and stretch_factor, will interoperate successfully to form an operational network. More specifically, if a simple metric that leads to a hop-count computation for path lengths and route computation is know to yield unusable performance, why is it not required that a node use some sort of computation based on link characteristics? And, if the computation of the step_factor is entirely up to the node, why are the rank_factor and stretch_factor needed? Why not just leave the entire computation to the implementation, with limitations that the resulting step_factor lie in the range MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK? 2. I would also like to discuss the requirement for a mandatory-to-implement OF, whether OF0 is that mandatory-to-implement OF and where the requirement to implement OF0 is specified. 3. In section 7.1, why is support of the DODAG Configuration option only a SHOULD? An OF0 implementation SHOULD support the DODAG Configuration option as specified in section 6.7.6 of [I-D.ietf-roll-rpl] and apply the parameters contained therein. 4. This point is more editorial than completely technical, but I list it as a Discuss because of the potential for confusion among implementors. I found the use of "DODAG Version" a little confusing, because it appears sometimes to mean one of the successive Versions of one DODAG and at other times to mean a specific DODAG chosen from several DODAGs. For example, from the Introduction: RPL forms Directed Acyclic Graphs (DAGs) as collections of Destination Oriented DAGs (DODAGs) within instances of the protocol. Each instance is associated with a specialized Objective Function. A DODAG is periodically reconstructed as a new DODAG Version to enable a global reoptimization of the graph. An instance of RPL running on a device uses an Objective Function to help it determine which DODAG Version it should join. The OF is also used by the RPL instance to select a number of routers within the DODAG Version to serve as parents or as feasible successors. In my opinion, the first use of "DODAG Version" refers to a sucessive Version of one DODAG, while the second use refers to a selection of one DODAG from many DODAGs. Would it be possible to just use "DODAG" for the second intended use? Or am I confused about the intended meanings? 5. In section 4.2.1, what does it mean to "validate a router"? Why would a router that passes validation ("succeeded that validation process") only be "preferable"? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1. I consider the following comment to be a technical rather than an editorial suggestion because of the redundancy and potential conflict between the text in the Introduction of this document and the contents of draft-ietf-roll-rpl-19. It would improve the document to edit the Introduction down to a paragrpah that combines the following sentence from the first paragraph with the content from the last paragraph: An Objective Function defines how a RPL node selects and optimizes routes within a RPL Instance based on the information objects available. Editing out the text describing RPL would also presumably address Stewart's Discuss about the use of multiple OFs in one RPL Instance. 2. I don't understand this phrase from the last paragraph of the Introduction: [...] OF0 enforces normalized values for the rank_increase of a normal link and its acceptable range Do I have it right that a node uses OF0 to determine the rank_increase for a successor within the range: MINIMUM_STEP_OF_RANK < stretched step_of_rank < MAXIMUM_STEP_OF_RANK Unless I'm missing something, these limits on the stretched step_of_rank enforce (indirectly) a range on rank_increase, but don't normalize rank_increase by some normalizing factor. 3. Is there a reason to switch between "successor" and "parent" throughout the document? For example, the title of section 4.2 is "Feasible Successors Selection" and the title of the immediately following section 4.2.1 is "Selection Of The Preferred Parent". Are "successor" and "parent" are synonymous in this context? Would it be asking for foolish consistency to choose one or the other? 4. In section 7.1, what is "build-time"? At build-time [...] Also in section 7.1, what is a "fixed constant" (as opposed to any other kind of "constant"). Why are overridden values - I assume these are overriden by some administrative method like CLI configuration or some management protocol? - only applied at the next Version of the DODAG? 5. In section 3, how is "good enough" defined? From reading the rest of the spec, I don't see where any assessment of quality is applied to ensure that "good enough" is more than basic connectivity. I suggest just dropping "good enough". From pthubert@cisco.com Tue Aug 9 02:12:03 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027EB21F8513; Tue, 9 Aug 2011 02:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.436 X-Spam-Level: X-Spam-Status: No, score=-10.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTZUYqjexR05; Tue, 9 Aug 2011 02:12:01 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1A36D21F851F; Tue, 9 Aug 2011 02:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=8222; q=dns/txt; s=iport; t=1312881149; x=1314090749; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=mT4+e3eo9NPCRUaHHKvhgywCYhjoZZ6HDwrSvnwz3fw=; b=RYXfn+hU5dy6P5qc0Dkv2VCCG5Zc4/i88oTNzPhDXVsobwp/EOJGnAbu BSV80QrRRfv+cLPdAWJEVMk8pjnZlkb6jUTRY7Wfesn8tGYy3tGl/JFWt HwOfVXMysxQF8hxZZR0rqCPpkmV9LM4LQuxLJRvLWZI5j68AUyxeu8qM5 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQAAIj5QE6Q/khN/2dsb2JhbABCl1qPW3eBQAEBAQEDAQEBDwEdCjQLDAQCAQgOAwQBAQsGFwEGASYfCQgBAQQBEggBGYdPnmQBnn2FZ18EmBeLWw X-IronPort-AV: E=Sophos;i="4.67,342,1309737600"; d="scan'208";a="108272749" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 09 Aug 2011 09:12:23 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p799CNkf007695; Tue, 9 Aug 2011 09:12:23 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Aug 2011 11:12:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Aug 2011 11:12:20 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D053A3AD7@XMB-AMS-107.cisco.com> In-Reply-To: <20110808232350.30897.61741.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Ralph Droms' Discuss on draft-ietf-roll-of0-15: (withDISCUSS and COMMENT) Thread-Index: AcxWIlCXhu0G8NxMSBu5SzdLqUunTQAUQM4w References: <20110808232350.30897.61741.idtracker@ietfa.amsl.com> From: "Pascal Thubert (pthubert)" To: "Ralph Droms" , "The IESG" X-OriginalArrivalTime: 09 Aug 2011 09:12:23.0535 (UTC) FILETIME=[732BD7F0:01CC5674] Cc: roll@ietf.org, draft-ietf-roll-of0@tools.ietf.org, roll-chairs@tools.ietf.org Subject: Re: [Roll] Ralph Droms' Discuss on draft-ietf-roll-of0-15: (withDISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 09:12:03 -0000 Hello Ralph; If that's what it takes, so be it. The drawback of removing such text as opposed to making it more clear is that more and more people will interpret as Stewart did that mixing OFs could create loops. This was in fact an arbitrary decision by the WG to keep things simple and guarantee a global optimization. This also constrains RPL more than actually needed and we might end up blocking deployments that the group did not foresee at the time. My original "bubbles" work allowed to mix plugins - which RPL dubbed OFs later -, and this allowed deployments like cars from different car makers in a parking lot having different goals yet forming a DAG. Loops will not form, but the cars will not necessarily get the connectivity they expect. Cheers, Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Ralph Droms > Sent: Tuesday, August 09, 2011 1:24 AM > To: The IESG > Cc: roll@ietf.org; draft-ietf-roll-of0@tools.ietf.org; roll-chairs@tools.ietf.org > Subject: [Roll] Ralph Droms' Discuss on draft-ietf-roll-of0-15: (withDISCUSS > and COMMENT) >=20 > Ralph Droms has entered the following ballot position for > draft-ietf-roll-of0-15: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > 1. I would like to discuss the interoperability and deployability of > nodes in a RPL Instance that uses OF0. If I understand section 4.1 > correctly, a node is free to compute step-of-rank using any method it > chooses. There is a suggestion that using link properties for the > computation is preferred, but the specific link properties and the > method of computation are not specified. Later, section 4.1 defines > two parameters, rank_factor and stretch_factor, that modify > step_of_rank to generate a "stretched step_of_rank". The latter value > is then multiplied by the MinHopRankIncrease to compute the node's > rank_increase. >=20 > My concern is the degrees of freedom provided to the implementation in > the computation of rank_increase. I'm hoping I can get an explanation > of some reason to believe that independent implementations, using > different methods to compute step_of_rank and potentially different > configured values for rank_factor and stretch_factor, will > interoperate successfully to form an operational network. >=20 > More specifically, if a simple metric that leads to a hop-count > computation for path lengths and route computation is know to yield > unusable performance, why is it not required that a node use some sort > of computation based on link characteristics? And, if the computation > of the step_factor is entirely up to the node, why are the rank_factor > and stretch_factor needed? Why not just leave the entire computation > to the implementation, with limitations that the resulting step_factor > lie in the range MINIMUM_STEP_OF_RANK and > MAXIMUM_STEP_OF_RANK? >=20 > 2. I would also like to discuss the requirement for a > mandatory-to-implement OF, whether OF0 is that mandatory-to-implement > OF and where the requirement to implement OF0 is specified. >=20 > 3. In section 7.1, why is support of the DODAG Configuration option > only a SHOULD? >=20 > An OF0 implementation SHOULD support the DODAG Configuration option > as specified in section 6.7.6 of [I-D.ietf-roll-rpl] and apply the > parameters contained therein. >=20 > 4. This point is more editorial than completely technical, but I list > it as a Discuss because of the potential for confusion among > implementors. I found the use of "DODAG Version" a little confusing, > because it appears sometimes to mean one of the successive Versions of > one DODAG and at other times to mean a specific DODAG chosen from > several DODAGs. For example, from the Introduction: >=20 > RPL forms Directed Acyclic Graphs (DAGs) as collections of > Destination Oriented DAGs (DODAGs) within instances of the protocol. > Each instance is associated with a specialized Objective Function. A > DODAG is periodically reconstructed as a new DODAG Version to enable > a global reoptimization of the graph. >=20 > An instance of RPL running on a device uses an Objective Function to > help it determine which DODAG Version it should join. The OF is also > used by the RPL instance to select a number of routers within the > DODAG Version to serve as parents or as feasible successors. >=20 > In my opinion, the first use of "DODAG Version" refers to a sucessive > Version of one DODAG, while the second use refers to a selection of > one DODAG from many DODAGs. Would it be possible to just use "DODAG" > for the second intended use? Or am I confused about the intended > meanings? >=20 > 5. In section 4.2.1, what does it mean to "validate a router"? Why > would a router that passes validation ("succeeded that validation > process") only be "preferable"? >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > 1. I consider the following comment to be a technical rather than an > editorial suggestion because of the redundancy and potential conflict > between the text in the Introduction of this document and the contents > of draft-ietf-roll-rpl-19. It would improve the document to edit the > Introduction down to a paragrpah that combines the following sentence > from the first paragraph with the content from the last paragraph: >=20 > An Objective Function > defines how a RPL node selects and optimizes routes within a RPL > Instance based on the information objects available. >=20 > Editing out the text describing RPL would also presumably address > Stewart's Discuss about the use of multiple OFs in one RPL Instance. >=20 > 2. I don't understand this phrase from the last paragraph of the > Introduction: >=20 > [...] OF0 enforces normalized values for the rank_increase of a > normal link and its acceptable range >=20 > Do I have it right that a node uses OF0 to determine the rank_increase > for a successor within the range: >=20 > MINIMUM_STEP_OF_RANK < stretched step_of_rank < > MAXIMUM_STEP_OF_RANK >=20 > Unless I'm missing something, these limits on the stretched > step_of_rank enforce (indirectly) a range on rank_increase, but don't > normalize rank_increase by some normalizing factor. >=20 > 3. Is there a reason to switch between "successor" and "parent" > throughout the document? For example, the title of section 4.2 is > "Feasible Successors Selection" and the title of the immediately > following section 4.2.1 is "Selection Of The Preferred Parent". Are > "successor" and "parent" are synonymous in this context? Would it be > asking for foolish consistency to choose one or the other? >=20 > 4. In section 7.1, what is "build-time"? >=20 > At build-time [...] >=20 > Also in section 7.1, what is a "fixed constant" (as opposed to any > other kind of "constant"). Why are overridden values - I assume these > are overriden by some administrative method like CLI configuration or > some management protocol? - only applied at the next Version of the > DODAG? >=20 > 5. In section 3, how is "good enough" defined? From reading the rest > of the spec, I don't see where any assessment of quality is applied to > ensure that "good enough" is more than basic connectivity. I suggest > just dropping "good enough". >=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Tue Aug 9 08:26:34 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32E221F8C66; Tue, 9 Aug 2011 08:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qc0CUSuxzTkd; Tue, 9 Aug 2011 08:26:33 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id E453C21F8C60; Tue, 9 Aug 2011 08:26:33 -0700 (PDT) Received: from marajade.sandelman.ca (74-115-197-34.eng.wind.ca [74.115.197.34]) by relay.sandelman.ca (Postfix) with ESMTPS id 2280F3418E; Tue, 9 Aug 2011 11:26:33 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 16F7798C68; Tue, 9 Aug 2011 10:52:24 -0400 (EDT) From: Michael Richardson To: Ralph Droms In-Reply-To: <20110808232350.30897.61741.idtracker@ietfa.amsl.com> References: <20110808232350.30897.61741.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 09 Aug 2011 10:52:24 -0400 Message-ID: <2982.1312901544@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org, draft-ietf-roll-of0@tools.ietf.org, The IESG , roll-chairs@tools.ietf.org Subject: Re: [Roll] Ralph Droms' Discuss on draft-ietf-roll-of0-15: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 15:26:34 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Ralph" =3D=3D Ralph Droms writes: Ralph> 5. In section 4.2.1, what does it mean to "validate a Ralph> router"? Why would a router that passes validation Ralph> ("succeeded that validation process") only be "preferable"? I think, it refers to rpl-19 section 3.2.3, to the "authenticated" mode. This mode is completely unworkable with asymmetric crypto. I guess I need to write an ID that explains this better. The reason why an authenticated router is only preferred is because the node might need to get online in order to actually validate things. Any node which will pass enough traffic so that a new node can validate some certificate chain is good enough.=20=20 While a new node can do all manner of DOS attacks to prevent the prospective node from validating some security properties, none of them (if you trust your crypto) are worse than having the prospective node find itself without any network. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATkFJp4CLcPvd0N1lAQK4hAgArFZWRRl9PLPj4juxPBPVJE4BU4bCdyr+ /Nb2+JyINBkEqtGBV2DUWS0kKMh+QnWZXrNCv8TNSqCNeqVh9yabfw2rb+vea/VV xGTUb/TOXBT1IwMrLcFYB4u0G3mbOi6+vIZYzuypee44ZD7X+pmLG2YYWoNfkmmc uvQH+l/Wfv0McowFv46w/hnpkb4kzo2wnDCnR0961gsis8wTtQt3jqrRtgI3a9kG lic2N3hHWvR2g7zEu37VqAExC1TEZkiIrE1afUQD26UJhRVDfR0yJyXF8oCHilD0 v1aUyHkFlK3UtxoXBGaiAXyfVczq/29Yq+fZ5x0ibV8E/6xPI2UJEw== =NQ8/ -----END PGP SIGNATURE----- --=-=-=-- From rdroms.ietf@gmail.com Tue Aug 9 09:08:34 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E1E21F8B78; Tue, 9 Aug 2011 09:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.339 X-Spam-Level: X-Spam-Status: No, score=-103.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yt53--pfE9yM; Tue, 9 Aug 2011 09:08:33 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7070B21F8B68; Tue, 9 Aug 2011 09:08:33 -0700 (PDT) Received: by qwc23 with SMTP id 23so98510qwc.31 for ; Tue, 09 Aug 2011 09:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=pK2V3PZm2qFOZhI3B+bRz53vhOsH/g1+BuHv6VK0Xjo=; b=Y6EdALKBd15FuPOd+ziizyMtfc9Cwha2tMEIwcsuw2vnKjYOcGHiCzJlJ2G8AcRWFC 7fB0epzQ65vWj7h0qRUpFfr+hTKc18UHD19OOX7HBvJ9VzBVDX0iLuJ688FEg5O3zRxL 8/PUH5dQ2xXSZfpCp2lDFe+uYm0ZErD7yboPk= Received: by 10.224.200.200 with SMTP id ex8mr5730692qab.246.1312906140311; Tue, 09 Aug 2011 09:09:00 -0700 (PDT) Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id b6sm48500qcb.11.2011.08.09.09.08.57 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Aug 2011 09:08:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D053A3AD7@XMB-AMS-107.cisco.com> Date: Tue, 9 Aug 2011 12:08:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9BF57281-8CB0-4D5E-AE2B-6BE836CCAD08@gmail.com> References: <20110808232350.30897.61741.idtracker@ietfa.amsl.com> <6A2A459175DABE4BB11DE2026AA50A5D053A3AD7@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1084) Cc: roll@ietf.org, draft-ietf-roll-of0@tools.ietf.org, roll-chairs@tools.ietf.org, The IESG Subject: Re: [Roll] Ralph Droms' Discuss on draft-ietf-roll-of0-15: (withDISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 16:08:34 -0000 Pascal... On Aug 9, 2011, at 5:12 AM 8/9/11, Pascal Thubert (pthubert) wrote: > Hello Ralph; >=20 > If that's what it takes, so be it. The drawback of removing such text = as > opposed to making it more clear is that more and more people will > interpret as Stewart did that mixing OFs could create loops. I think the issue is sufficiently clarified in the RPL spec and need not = be revisited here. =20 > This was in fact an arbitrary decision by the WG to keep things simple > and guarantee a global optimization. This also constrains RPL more = than > actually needed and we might end up blocking deployments that the = group > did not foresee at the time. Do I have it right, then, that OF0 sidesteps the WG decision for a = single OF throughout a RPL Instance by allowing each node to compute its = rank increase using whatever mechanism it chooses? I know the document has gone through last call but I don't think I saw = that this specific point was discussed. If it is the case that OF0 allows each node to choose its own = computation, why not simplify the OF0 spec to state "OF0 allows a node = to choose any value for rank_increase, subject to the specified = constraints" , along with whatever constraints are required on the value = of the rank increase to ensure loop-free operation? Those constraints = may already exist in the RPL spec, in which case the OF0 spec can simply = cite a reference to the constraints in the RPL spec. > My original "bubbles" work allowed to mix plugins - which RPL dubbed = OFs > later -, and this allowed deployments like cars from different car > makers in a parking lot having different goals yet forming a DAG. = Loops > will not form, but the cars will not necessarily get the connectivity > they expect. But "not necessarily get the connectivity they expect" doesn't sound = like a particularly useful characteristic of an OF ... especially if = node A uses OFi, expecting one kind of connectivity, and node B uses = OFj, optimizing for a different kind of connectivity, and A has no way = to know what OF B is using. How can A make any informed choice about = what RPL Instance to join? - Ralph > Cheers, >=20 > Pascal >=20 >=20 >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of >> Ralph Droms >> Sent: Tuesday, August 09, 2011 1:24 AM >> To: The IESG >> Cc: roll@ietf.org; draft-ietf-roll-of0@tools.ietf.org; > roll-chairs@tools.ietf.org >> Subject: [Roll] Ralph Droms' Discuss on draft-ietf-roll-of0-15: > (withDISCUSS >> and COMMENT) >>=20 >> Ralph Droms has entered the following ballot position for >> draft-ietf-roll-of0-15: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut > this >> introductory paragraph, however.) >>=20 >> Please refer to > http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> 1. I would like to discuss the interoperability and deployability of >> nodes in a RPL Instance that uses OF0. If I understand section 4.1 >> correctly, a node is free to compute step-of-rank using any method it >> chooses. There is a suggestion that using link properties for the >> computation is preferred, but the specific link properties and the >> method of computation are not specified. Later, section 4.1 defines >> two parameters, rank_factor and stretch_factor, that modify >> step_of_rank to generate a "stretched step_of_rank". The latter = value >> is then multiplied by the MinHopRankIncrease to compute the node's >> rank_increase. >>=20 >> My concern is the degrees of freedom provided to the implementation = in >> the computation of rank_increase. I'm hoping I can get an = explanation >> of some reason to believe that independent implementations, using >> different methods to compute step_of_rank and potentially different >> configured values for rank_factor and stretch_factor, will >> interoperate successfully to form an operational network. >>=20 >> More specifically, if a simple metric that leads to a hop-count >> computation for path lengths and route computation is know to yield >> unusable performance, why is it not required that a node use some = sort >> of computation based on link characteristics? And, if the = computation >> of the step_factor is entirely up to the node, why are the = rank_factor >> and stretch_factor needed? Why not just leave the entire computation >> to the implementation, with limitations that the resulting = step_factor >> lie in the range MINIMUM_STEP_OF_RANK and >> MAXIMUM_STEP_OF_RANK? >>=20 >> 2. I would also like to discuss the requirement for a >> mandatory-to-implement OF, whether OF0 is that mandatory-to-implement >> OF and where the requirement to implement OF0 is specified. >>=20 >> 3. In section 7.1, why is support of the DODAG Configuration option >> only a SHOULD? >>=20 >> An OF0 implementation SHOULD support the DODAG Configuration option >> as specified in section 6.7.6 of [I-D.ietf-roll-rpl] and apply the >> parameters contained therein. >>=20 >> 4. This point is more editorial than completely technical, but I list >> it as a Discuss because of the potential for confusion among >> implementors. I found the use of "DODAG Version" a little confusing, >> because it appears sometimes to mean one of the successive Versions = of >> one DODAG and at other times to mean a specific DODAG chosen from >> several DODAGs. For example, from the Introduction: >>=20 >> RPL forms Directed Acyclic Graphs (DAGs) as collections of >> Destination Oriented DAGs (DODAGs) within instances of the > protocol. >> Each instance is associated with a specialized Objective Function. > A >> DODAG is periodically reconstructed as a new DODAG Version to > enable >> a global reoptimization of the graph. >>=20 >> An instance of RPL running on a device uses an Objective Function > to >> help it determine which DODAG Version it should join. The OF is > also >> used by the RPL instance to select a number of routers within the >> DODAG Version to serve as parents or as feasible successors. >>=20 >> In my opinion, the first use of "DODAG Version" refers to a sucessive >> Version of one DODAG, while the second use refers to a selection of >> one DODAG from many DODAGs. Would it be possible to just use "DODAG" >> for the second intended use? Or am I confused about the intended >> meanings? >>=20 >> 5. In section 4.2.1, what does it mean to "validate a router"? Why >> would a router that passes validation ("succeeded that validation >> process") only be "preferable"? >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >>=20 >> 1. I consider the following comment to be a technical rather than an >> editorial suggestion because of the redundancy and potential conflict >> between the text in the Introduction of this document and the = contents >> of draft-ietf-roll-rpl-19. It would improve the document to edit the >> Introduction down to a paragrpah that combines the following sentence >> from the first paragraph with the content from the last paragraph: >>=20 >> An Objective Function >> defines how a RPL node selects and optimizes routes within a RPL >> Instance based on the information objects available. >>=20 >> Editing out the text describing RPL would also presumably address >> Stewart's Discuss about the use of multiple OFs in one RPL Instance. >>=20 >> 2. I don't understand this phrase from the last paragraph of the >> Introduction: >>=20 >> [...] OF0 enforces normalized values for the rank_increase of a >> normal link and its acceptable range >>=20 >> Do I have it right that a node uses OF0 to determine the = rank_increase >> for a successor within the range: >>=20 >> MINIMUM_STEP_OF_RANK < stretched step_of_rank < >> MAXIMUM_STEP_OF_RANK >>=20 >> Unless I'm missing something, these limits on the stretched >> step_of_rank enforce (indirectly) a range on rank_increase, but don't >> normalize rank_increase by some normalizing factor. >>=20 >> 3. Is there a reason to switch between "successor" and "parent" >> throughout the document? For example, the title of section 4.2 is >> "Feasible Successors Selection" and the title of the immediately >> following section 4.2.1 is "Selection Of The Preferred Parent". Are >> "successor" and "parent" are synonymous in this context? Would it be >> asking for foolish consistency to choose one or the other? >>=20 >> 4. In section 7.1, what is "build-time"? >>=20 >> At build-time [...] >>=20 >> Also in section 7.1, what is a "fixed constant" (as opposed to any >> other kind of "constant"). Why are overridden values - I assume = these >> are overriden by some administrative method like CLI configuration or >> some management protocol? - only applied at the next Version of the >> DODAG? >>=20 >> 5. In section 3, how is "good enough" defined? =46rom reading the = rest >> of the spec, I don't see where any assessment of quality is applied = to >> ensure that "good enough" is more than basic connectivity. I suggest >> just dropping "good enough". >>=20 >>=20 >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll From rdroms.ietf@gmail.com Tue Aug 9 09:22:49 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6AE21F8CC2; Tue, 9 Aug 2011 09:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.382 X-Spam-Level: X-Spam-Status: No, score=-103.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2AxV2HEESeH; Tue, 9 Aug 2011 09:22:48 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6A521F856C; Tue, 9 Aug 2011 09:22:48 -0700 (PDT) Received: by qyk35 with SMTP id 35so90237qyk.10 for ; Tue, 09 Aug 2011 09:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Wya+0AnszqhHVNo3imerf5fLeTWIf/W5tUMEcwoRS5M=; b=wwtluXDFbIQBQBRYer7WcF62ubl9FCi+eN5ZlsYV8HJyyhHTQHJ3gyTFIO+4Q1YFB2 +nYqrZJO68wc1sfMgowRoWaXhyev2TsSYGK0ZKz22pP5rP78YUW+cEOgJGozlbp+tPfO FT8U7JjMWvCJgsFlGu97igpnMwvMXF07eRsgg= Received: by 10.229.29.71 with SMTP id p7mr1640479qcc.226.1312906997235; Tue, 09 Aug 2011 09:23:17 -0700 (PDT) Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id k14sm49320qct.45.2011.08.09.09.23.15 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Aug 2011 09:23:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <2982.1312901544@marajade.sandelman.ca> Date: Tue, 9 Aug 2011 12:23:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <73AD8D4B-A9F9-49EC-A8C3-07BAA3924943@gmail.com> References: <20110808232350.30897.61741.idtracker@ietfa.amsl.com> <2982.1312901544@marajade.sandelman.ca> To: draft-ietf-roll-of0@tools.ietf.org X-Mailer: Apple Mail (2.1084) Cc: roll@ietf.org, The IESG , roll-chairs@tools.ietf.org Subject: Re: [Roll] Ralph Droms' Discuss on draft-ietf-roll-of0-15: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 16:22:49 -0000 On Aug 9, 2011, at 10:52 AM 8/9/11, Michael Richardson wrote: >=20 >>>>>> "Ralph" =3D=3D Ralph Droms writes: > Ralph> 5. In section 4.2.1, what does it mean to "validate a > Ralph> router"? Why would a router that passes validation > Ralph> ("succeeded that validation process") only be "preferable"? >=20 > I think, it refers to rpl-19 section 3.2.3, to the "authenticated" = mode. > This mode is completely unworkable with asymmetric crypto. I guess I > need to write an ID that explains this better. Pascal - can you confirm that section 4.2.1 refers to rpl-19 section = 3.2.3? - Ralph > The reason why an authenticated router is only preferred is because = the > node might need to get online in order to actually validate things. = Any > node which will pass enough traffic so that a new node can validate = some > certificate chain is good enough. =20 >=20 > While a new node can do all manner of DOS attacks to prevent the > prospective node from validating some security properties, none of = them > (if you trust your crypto) are worse than having the prospective node > find itself without any network. >=20 > --=20 > ] He who is tired of Weird Al is tired of life! | = firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net = architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ = |device driver[ > Kyoto Plus: watch the video = > then sign the petition.=20 From pthubert@cisco.com Tue Aug 9 09:43:49 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB5821F8CAA; Tue, 9 Aug 2011 09:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.456 X-Spam-Level: X-Spam-Status: No, score=-10.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGQ5hfLSVLAo; Tue, 9 Aug 2011 09:43:48 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFB421F8C94; Tue, 9 Aug 2011 09:43:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=11441; q=dns/txt; s=iport; t=1312908257; x=1314117857; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=AzT2sVyZcukIsGleFoCVkLAUbYxCxeKoxqQCQ61JHr0=; b=TlIXvELHbI9OdEcG6CfJzMMTjBDP6tAxK0TQ8A35oujYthYxPn3SxEsy hLFi0eDOCj7T6kQa5qCVop275NWVFB5VnorpRJQdNb4pIbptcOjMSDWJD yJQCuc+unIo5DHiqkTWAOStTq3KjCxVBcuE59MWUy7axjnZ1ggHgTEsis A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAAADBjQU6Q/khN/2dsb2JhbABCl2CPXneBQAEBAQECAQEBAQ8BHQo0CwUHBAIBCA4DBAEBCwYXAQYBJh8JCAEBBBMIARmHSwSgFwGea4VnXwSYF4tb X-IronPort-AV: E=Sophos;i="4.67,344,1309737600"; d="scan'208";a="108477653" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 09 Aug 2011 16:44:15 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p79GiFn9021317; Tue, 9 Aug 2011 16:44:15 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Aug 2011 18:44:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Aug 2011 18:44:14 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D053A3C84@XMB-AMS-107.cisco.com> In-Reply-To: <9BF57281-8CB0-4D5E-AE2B-6BE836CCAD08@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Ralph Droms' Discuss on draft-ietf-roll-of0-15: (withDISCUSS and COMMENT) Thread-Index: AcxWrq3+gVbpeiUzSA2hp0ow5At9+gAAKtCQ References: <20110808232350.30897.61741.idtracker@ietfa.amsl.com> <6A2A459175DABE4BB11DE2026AA50A5D053A3AD7@XMB-AMS-107.cisco.com> <9BF57281-8CB0-4D5E-AE2B-6BE836CCAD08@gmail.com> From: "Pascal Thubert (pthubert)" To: "Ralph Droms" X-OriginalArrivalTime: 09 Aug 2011 16:44:14.0951 (UTC) FILETIME=[92D59F70:01CC56B3] Cc: roll@ietf.org, draft-ietf-roll-of0@tools.ietf.org, The IESG , roll-chairs@tools.ietf.org Subject: Re: [Roll] Ralph Droms' Discuss on draft-ietf-roll-of0-15: (withDISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 16:43:49 -0000 Hello Ralph; > > > > If that's what it takes, so be it. The drawback of removing such text as > > opposed to making it more clear is that more and more people will > > interpret as Stewart did that mixing OFs could create loops. >=20 > I think the issue is sufficiently clarified in the RPL spec and need not be > revisited here. [Pascal] Fine then. I think what you're pointing out is compatible with Stewart's proposed change. > > This was in fact an arbitrary decision by the WG to keep things simple > > and guarantee a global optimization. This also constrains RPL more than > > actually needed and we might end up blocking deployments that the group > > did not foresee at the time. >=20 > Do I have it right, then, that OF0 sidesteps the WG decision for a single OF > throughout a RPL Instance by allowing each node to compute its rank > increase using whatever mechanism it chooses? >=20 [Pascal] I do not think so. The spirit of the law is conserved. There is room in OF0 for implementation to bring in some variations. This is needed because OF0 may make different computations of different links. But the variations are normalized from excellent (1) to worst acceptable (9) with normal (3) in the middle. That, plus the fact that the Goal (G) is specified, makes it so that OF0 stays within the spirit of a single OF. > I know the document has gone through last call but I don't think I saw that > this specific point was discussed. >=20 [Pascal] It was, at least with Phil Levis.=20 > If it is the case that OF0 allows each node to choose its own computation, > why not simplify the OF0 spec to state "OF0 allows a node to choose any > value for rank_increase, subject to the specified constraints" , along with > whatever constraints are required on the value of the rank increase to > ensure loop-free operation? Those constraints may already exist in the RPL > spec, in which case the OF0 spec can simply cite a reference to the > constraints in the RPL spec. >=20 [Pascal] This is looser than what OF0 does.=20 OF0 ranks the step of rank from 0 to 9 based on implementation preference but an average like should be 3. The rest of the computation (G bit, rank factor) is imposed by OF0. > > My original "bubbles" work allowed to mix plugins - which RPL dubbed OFs > > later -, and this allowed deployments like cars from different car > > makers in a parking lot having different goals yet forming a DAG. Loops > > will not form, but the cars will not necessarily get the connectivity > > they expect. >=20 > But "not necessarily get the connectivity they expect" doesn't sound like a > particularly useful characteristic of an OF ... especially if node A uses OFi, > expecting one kind of connectivity, and node B uses OFj, optimizing for a > different kind of connectivity, and A has no way to know what OF B is using. > How can A make any informed choice about what RPL Instance to join? [Pascal] Exactly. Different OFs provide loop avoidance but no other guarantee.=20 Further guidance might relate different OFs that share a same goal in which case we'd get something workable. That is barred in RPL so there is no point discussing it in OF0.=20 I'd like to convey somewhere why we made that decision, what the consequences are, etc... and in particular that it is not to avoid loops. But OF0 is probably not the right place for that... I'll answer all the other points separately. Cheers, >=20 > - Ralph >=20 >=20 > > Cheers, > > > > Pascal > > > > > >> -----Original Message----- > >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > > Of > >> Ralph Droms > >> Sent: Tuesday, August 09, 2011 1:24 AM > >> To: The IESG > >> Cc: roll@ietf.org; draft-ietf-roll-of0@tools.ietf.org; > > roll-chairs@tools.ietf.org > >> Subject: [Roll] Ralph Droms' Discuss on draft-ietf-roll-of0-15: > > (withDISCUSS > >> and COMMENT) > >> > >> Ralph Droms has entered the following ballot position for > >> draft-ietf-roll-of0-15: Discuss > >> > >> When responding, please keep the subject line intact and reply to all > >> email addresses included in the To and CC lines. (Feel free to cut > > this > >> introductory paragraph, however.) > >> > >> Please refer to > > http://www.ietf.org/iesg/statement/discuss-criteria.html > >> for more information about IESG DISCUSS and COMMENT positions. > >> > >> > >> > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> 1. I would like to discuss the interoperability and deployability of > >> nodes in a RPL Instance that uses OF0. If I understand section 4.1 > >> correctly, a node is free to compute step-of-rank using any method it > >> chooses. There is a suggestion that using link properties for the > >> computation is preferred, but the specific link properties and the > >> method of computation are not specified. Later, section 4.1 defines > >> two parameters, rank_factor and stretch_factor, that modify > >> step_of_rank to generate a "stretched step_of_rank". The latter value > >> is then multiplied by the MinHopRankIncrease to compute the node's > >> rank_increase. > >> > >> My concern is the degrees of freedom provided to the implementation in > >> the computation of rank_increase. I'm hoping I can get an explanation > >> of some reason to believe that independent implementations, using > >> different methods to compute step_of_rank and potentially different > >> configured values for rank_factor and stretch_factor, will > >> interoperate successfully to form an operational network. > >> > >> More specifically, if a simple metric that leads to a hop-count > >> computation for path lengths and route computation is know to yield > >> unusable performance, why is it not required that a node use some sort > >> of computation based on link characteristics? And, if the computation > >> of the step_factor is entirely up to the node, why are the rank_factor > >> and stretch_factor needed? Why not just leave the entire computation > >> to the implementation, with limitations that the resulting step_factor > >> lie in the range MINIMUM_STEP_OF_RANK and > >> MAXIMUM_STEP_OF_RANK? > >> > >> 2. I would also like to discuss the requirement for a > >> mandatory-to-implement OF, whether OF0 is that mandatory-to- > implement > >> OF and where the requirement to implement OF0 is specified. > >> > >> 3. In section 7.1, why is support of the DODAG Configuration option > >> only a SHOULD? > >> > >> An OF0 implementation SHOULD support the DODAG Configuration > option > >> as specified in section 6.7.6 of [I-D.ietf-roll-rpl] and apply the > >> parameters contained therein. > >> > >> 4. This point is more editorial than completely technical, but I list > >> it as a Discuss because of the potential for confusion among > >> implementors. I found the use of "DODAG Version" a little confusing, > >> because it appears sometimes to mean one of the successive Versions of > >> one DODAG and at other times to mean a specific DODAG chosen from > >> several DODAGs. For example, from the Introduction: > >> > >> RPL forms Directed Acyclic Graphs (DAGs) as collections of > >> Destination Oriented DAGs (DODAGs) within instances of the > > protocol. > >> Each instance is associated with a specialized Objective Function. > > A > >> DODAG is periodically reconstructed as a new DODAG Version to > > enable > >> a global reoptimization of the graph. > >> > >> An instance of RPL running on a device uses an Objective Function > > to > >> help it determine which DODAG Version it should join. The OF is > > also > >> used by the RPL instance to select a number of routers within the > >> DODAG Version to serve as parents or as feasible successors. > >> > >> In my opinion, the first use of "DODAG Version" refers to a sucessive > >> Version of one DODAG, while the second use refers to a selection of > >> one DODAG from many DODAGs. Would it be possible to just use > "DODAG" > >> for the second intended use? Or am I confused about the intended > >> meanings? > >> > >> 5. In section 4.2.1, what does it mean to "validate a router"? Why > >> would a router that passes validation ("succeeded that validation > >> process") only be "preferable"? > >> > >> > >> > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> > >> 1. I consider the following comment to be a technical rather than an > >> editorial suggestion because of the redundancy and potential conflict > >> between the text in the Introduction of this document and the contents > >> of draft-ietf-roll-rpl-19. It would improve the document to edit the > >> Introduction down to a paragrpah that combines the following sentence > >> from the first paragraph with the content from the last paragraph: > >> > >> An Objective Function > >> defines how a RPL node selects and optimizes routes within a RPL > >> Instance based on the information objects available. > >> > >> Editing out the text describing RPL would also presumably address > >> Stewart's Discuss about the use of multiple OFs in one RPL Instance. > >> > >> 2. I don't understand this phrase from the last paragraph of the > >> Introduction: > >> > >> [...] OF0 enforces normalized values for the rank_increase of a > >> normal link and its acceptable range > >> > >> Do I have it right that a node uses OF0 to determine the rank_increase > >> for a successor within the range: > >> > >> MINIMUM_STEP_OF_RANK < stretched step_of_rank < > >> MAXIMUM_STEP_OF_RANK > >> > >> Unless I'm missing something, these limits on the stretched > >> step_of_rank enforce (indirectly) a range on rank_increase, but don't > >> normalize rank_increase by some normalizing factor. > >> > >> 3. Is there a reason to switch between "successor" and "parent" > >> throughout the document? For example, the title of section 4.2 is > >> "Feasible Successors Selection" and the title of the immediately > >> following section 4.2.1 is "Selection Of The Preferred Parent". Are > >> "successor" and "parent" are synonymous in this context? Would it be > >> asking for foolish consistency to choose one or the other? > >> > >> 4. In section 7.1, what is "build-time"? > >> > >> At build-time [...] > >> > >> Also in section 7.1, what is a "fixed constant" (as opposed to any > >> other kind of "constant"). Why are overridden values - I assume these > >> are overriden by some administrative method like CLI configuration or > >> some management protocol? - only applied at the next Version of the > >> DODAG? > >> > >> 5. In section 3, how is "good enough" defined? From reading the rest > >> of the spec, I don't see where any assessment of quality is applied to > >> ensure that "good enough" is more than basic connectivity. I suggest > >> just dropping "good enough". > >> > >> > >> > >> _______________________________________________ > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Tue Aug 9 09:47:48 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D8821F8B07; Tue, 9 Aug 2011 09:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.462 X-Spam-Level: X-Spam-Status: No, score=-10.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EazbQqqPz45F; Tue, 9 Aug 2011 09:47:47 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3E92C21F85CA; Tue, 9 Aug 2011 09:47:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=3414; q=dns/txt; s=iport; t=1312908497; x=1314118097; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=4YSDHldBsk2k+smzFW+nJmdkf3HfjIjaPGuryq8l6aQ=; b=fjsQuFuq7yF4GdZDxfXR/4Ma/6Q543/CyPhIjZr0B3XhxPfYbLldcFtk SzXi0NxCLCoKqjND1lag4MD4bYptU2PH52bHfjVQxnRlCdMnhJB0lna3e 0KiHaw/7gpVMLpJnJtSL2klwC+vRQ7eBAhvc6ZcKDM895PeVOm0gLwKwa 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAAACxkQU6Q/khL/2dsb2JhbABCl2CPXneBQAEBAQEDAQEBDwEdCjQLDAQCAQgOAwQBAQEKBhcBBgEgBh8JCAEBBAESCBEJh0+gEQGRPY0uhWdfBJgXhF2Gfg X-IronPort-AV: E=Sophos;i="4.67,344,1309737600"; d="scan'208";a="108480872" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 09 Aug 2011 16:48:15 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p79GmFrh010210; Tue, 9 Aug 2011 16:48:15 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Aug 2011 18:48:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Aug 2011 18:48:12 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D053A3C87@XMB-AMS-107.cisco.com> In-Reply-To: <73AD8D4B-A9F9-49EC-A8C3-07BAA3924943@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Ralph Droms' Discuss on draft-ietf-roll-of0-15: (withDISCUSS and COMMENT) Thread-Index: AcxWsLF8tY6XtYNDT6yiceUPhA5eAwAAgh3w References: <20110808232350.30897.61741.idtracker@ietfa.amsl.com><2982.1312901544@marajade.sandelman.ca> <73AD8D4B-A9F9-49EC-A8C3-07BAA3924943@gmail.com> From: "Pascal Thubert (pthubert)" To: "Ralph Droms" , X-OriginalArrivalTime: 09 Aug 2011 16:48:15.0579 (UTC) FILETIME=[22428AB0:01CC56B4] Cc: roll@ietf.org, The IESG , roll-chairs@tools.ietf.org Subject: Re: [Roll] Ralph Droms' Discuss on draft-ietf-roll-of0-15: (withDISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 16:47:48 -0000 Hi Ralph; I agree with you that this text would benefit from being more specific. RPL requires a number of validations to happen. A deployment might require additional policies, and use for instance L2 crypto to enforce them. So validating a router involves security concerns, like link access, and/or RPL security as Michael indicates. Additionally, RPL section 13 requires a continuous link quality validation. So this refers but is not limited to RPL sections 3.2.3 and 13. Suggestion: 2. An implementation SHOULD validate a router prior to selecting it as preferred. This validation process is implementation and link type dependent, and is out of scope. A router that succeeded that validation process is preferable. =3D> 2. An implementation SHOULD validate a router prior to selecting it as preferred. This validation process is implementation and link type dependent, and is out of scope. The validation involves but is not limited to application of [RPL] sections 3.2.3 and 13 as=20 appropriate, and may involve deployment specific policies as well. A router that succeeded that validation process is preferable.=20 What do you think? Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Ralph Droms > Sent: Tuesday, August 09, 2011 6:23 PM > To: draft-ietf-roll-of0@tools.ietf.org > Cc: roll@ietf.org; The IESG; roll-chairs@tools.ietf.org > Subject: Re: [Roll] Ralph Droms' Discuss on draft-ietf-roll-of0-15: > (withDISCUSS and COMMENT) >=20 >=20 > On Aug 9, 2011, at 10:52 AM 8/9/11, Michael Richardson wrote: >=20 > > > >>>>>> "Ralph" =3D=3D Ralph Droms writes: > > Ralph> 5. In section 4.2.1, what does it mean to "validate a > > Ralph> router"? Why would a router that passes validation > > Ralph> ("succeeded that validation process") only be "preferable"? > > > > I think, it refers to rpl-19 section 3.2.3, to the "authenticated" mode. > > This mode is completely unworkable with asymmetric crypto. I guess I > > need to write an ID that explains this better. >=20 > Pascal - can you confirm that section 4.2.1 refers to rpl-19 section 3.2.3? >=20 > - Ralph >=20 > > The reason why an authenticated router is only preferred is because the > > node might need to get online in order to actually validate things. Any > > node which will pass enough traffic so that a new node can validate some > > certificate chain is good enough. > > > > While a new node can do all manner of DOS attacks to prevent the > > prospective node from validating some security properties, none of them > > (if you trust your crypto) are worse than having the prospective node > > find itself without any network. > > > > -- > > ] He who is tired of Weird Al is tired of life! | firewalls [ > > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ > |device driver[ > > Kyoto Plus: watch the video > > > then sign the petition. >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Tue Aug 9 09:59:00 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDFD21F8C44; Tue, 9 Aug 2011 09:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.467 X-Spam-Level: X-Spam-Status: No, score=-10.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoKbsgbrIc3W; Tue, 9 Aug 2011 09:58:59 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3E05E21F8C3D; Tue, 9 Aug 2011 09:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2974; q=dns/txt; s=iport; t=1312909168; x=1314118768; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=lRoBp0TJdAoLpaGwUcXU8M9M7V9cKFop4P3wxctAtRk=; b=DcD4HNRjbdbdFefRoEOTErlVgG3qMdE9NP/3oAtWFsYa8M/DfzUdTSeW lxWKMBcBTia2sO9H8BYc4G4uNrM8BvDkI6bEehTeKOBSokcUuNZKql7ne 55F3K79oySl/X/uaV6YutUMbDVKw86Ix+gIP9yhoxmHJK4we21KawpQQQ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAClnQU6Q/khL/2dsb2JhbABCpz53gUABAQEBAgESAR0KPwUNARYUBhgHVwEEARoah0ugEQGea4VnXwSYF4tb X-IronPort-AV: E=Sophos;i="4.67,344,1309737600"; d="scan'208";a="48297315" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 09 Aug 2011 16:59:27 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p79GxRx2020240; Tue, 9 Aug 2011 16:59:27 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Aug 2011 18:59:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Aug 2011 18:59:23 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D053A3C8F@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ralph Droms' Discuss 1 on draft-ietf-roll-of0-15 Thread-Index: AcxWta5HvYJoN9srRXaYVgvvQWCc5g== From: "Pascal Thubert (pthubert)" To: "Ralph Droms" , "The IESG" X-OriginalArrivalTime: 09 Aug 2011 16:59:27.0697 (UTC) FILETIME=[B2DF9C10:01CC56B5] Cc: roll@ietf.org, draft-ietf-roll-of0@tools.ietf.org, roll-chairs@tools.ietf.org Subject: [Roll] Ralph Droms' Discuss 1 on draft-ietf-roll-of0-15 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 16:59:00 -0000 > 1. I would like to discuss the interoperability and deployability of > nodes in a RPL Instance that uses OF0. If I understand section 4.1 > correctly, a node is free to compute step-of-rank using any method it > chooses. There is a suggestion that using link properties for the > computation is preferred, but the specific link properties and the > method of computation are not specified. Later, section 4.1 defines > two parameters, rank_factor and stretch_factor, that modify > step_of_rank to generate a "stretched step_of_rank". The latter value > is then multiplied by the MinHopRankIncrease to compute the node's > rank_increase. >=20 > My concern is the degrees of freedom provided to the implementation in > the computation of rank_increase. I'm hoping I can get an explanation > of some reason to believe that independent implementations, using > different methods to compute step_of_rank and potentially different > configured values for rank_factor and stretch_factor, will > interoperate successfully to form an operational network. >=20 [Pascal] Success is defined as reaching the Goal (a set of nodes or the Internet), using the best links possible. OF0 does not guarantee a particular optimization for a certain metric, but trusts the implementation to rank a usable link from 1 to 9. Section 6.2 indicates that , rank_factor and stretch_of_rank are configured parameters. Maybe section 7.1 should indicate that a deployment should ensure they are homogeneous? > More specifically, if a simple metric that leads to a hop-count > computation for path lengths and route computation is known to yield > unusable performance, why is it not required that a node use some sort > of computation based on link characteristics? And, if the computation [Pascal] this is RECOMMENDED for links such as radio in section 4.1. But RPL (and OF0) also apply to other links, including 802.3 and 802.11. If you have a switched fabric as backbone, hop count or similar is appropriate there. > of the step_factor is entirely up to the node, why are the rank_factor > and stretch_factor needed? Why not just leave the entire computation > to the implementation, with limitations that the resulting step_factor > lie in the range MINIMUM_STEP_OF_RANK and > MAXIMUM_STEP_OF_RANK? [Pascal] There is only one factor, the rank_factor. It is used to discriminate different link types. Eg in homenet, 802.15.4 could have a huge rank_factor (3 or 4), a WIFI would use say 2 and G/ Ethernet 1.=20 This is a parameter that must be configured the same for all nodes for a given type of link and it has a consequent action on the rank_increase regardless of implementation. The result is that the topology OF0 builds can be deployed so as to limit the wireless hops, and favor .11 over .15.4. I think that is what you are really asking for and thus we are probably on the same line. What do you think? Pascal From rdroms.ietf@gmail.com Tue Aug 9 11:39:17 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DDB21F8C6E for ; Tue, 9 Aug 2011 11:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ju9xdyi9p9M3 for ; Tue, 9 Aug 2011 11:39:17 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id E460621F8C6C for ; Tue, 9 Aug 2011 11:39:16 -0700 (PDT) Received: by qwc23 with SMTP id 23so186249qwc.31 for ; Tue, 09 Aug 2011 11:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=9CQDAZmDA8OcQtGHwg4abfc73WDWdILim0J7MaI7nhI=; b=e95hjr/HWXj3kNLF51oQJTT8SCN7u7m3vO8O1/OElQfmoy93N6aDmAlHO6lpBnL7Kf l8s8g58TnDty9sZJU9QxEtEOb10bDA6lRG4+uklask9Vy5cnqSGQ31Nu/yS8DiXZSYUu YRlj3M/jt/P3jcqUho2Ui7e5aa6pZCi+9O2DE= Received: by 10.229.13.100 with SMTP id b36mr5408744qca.230.1312915186015; Tue, 09 Aug 2011 11:39:46 -0700 (PDT) Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id d12sm142394qcd.26.2011.08.09.11.39.44 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Aug 2011 11:39:45 -0700 (PDT) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Aug 2011 14:39:41 -0400 Message-Id: <3D21B0E7-C9D1-4335-B849-87DF61B2D6CD@gmail.com> To: roll@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Roll] Question/clarification about applicability of OF0 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 18:39:17 -0000 After reading through the mailing list threads on OF0, I have a couple = of questions about the applicability of and use cases for OF0. OF0, when it generates a rank_increase based on hop count, is = characterized as inappropriate for wireless meshes. I wonder if = "wireless" is really the right descriptive term here. More generally, a = hop count metric is inappropriate for subnets composed of links in which = a route with a higher hop count might perform better than a router with = a lower hop count. Such subnets can be either wireless or wired; for = example, as I understand the technology, it's possible for an IEEE1901.2 = network to exhibit connectivity and transmission quality characteristics = for which a route through more higher quality hops might be better than = a router through fewer lower quality hops. I'm also confused about some of the use cases for RPL. Is there a use = case in which RPL would be used in a non-LLN environment in place of = other routing protocols like RIP, OSPF and ISIS? - Ralph From pthubert@cisco.com Wed Aug 10 01:03:14 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DE421F8713 for ; Wed, 10 Aug 2011 01:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.481 X-Spam-Level: X-Spam-Status: No, score=-10.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOm2TGS28Q1s for ; Wed, 10 Aug 2011 01:03:14 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF7021F86DE for ; Wed, 10 Aug 2011 01:03:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2827; q=dns/txt; s=iport; t=1312963425; x=1314173025; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Irvo1QCMuqd9ZkpAg/hrmyO1CygXozEfQ9AUs3m5qGQ=; b=TZ/aQuukPHPEQZXqsWNY8AO5/lKYaMdxKFuZg8g689zLm67gp33qOQ6i YiQfkAbZoJRAj+C9+A8DHsHVJhNR7NHd/yXzdRfWvKEb5RApA6e1MgPot viQC6z0ULKMgl21JQKimOagK8otJ91vXkxiKHPbAaqFNv52j+cWAmNKvg w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8KADk6Qk6Q/khL/2dsb2JhbABBkx6UKwZxgTkHAQEBAQIBEgEdCkQLAgEIDhQGGAYBVgEBBAEaEweHS58XAZ5EhWdfBJgci1w X-IronPort-AV: E=Sophos;i="4.67,349,1309737600"; d="scan'208";a="48708738" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 10 Aug 2011 08:03:44 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7A83i38019003; Wed, 10 Aug 2011 08:03:44 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Aug 2011 10:03:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Aug 2011 10:03:40 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D053A3D61@XMB-AMS-107.cisco.com> In-Reply-To: <3D21B0E7-C9D1-4335-B849-87DF61B2D6CD@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Question/clarification about applicability of OF0 Thread-Index: AcxWw7rXpRwn7kCnTE6Txv02eVjcQQAbbvoQ References: <3D21B0E7-C9D1-4335-B849-87DF61B2D6CD@gmail.com> From: "Pascal Thubert (pthubert)" To: "Ralph Droms" , X-OriginalArrivalTime: 10 Aug 2011 08:03:44.0420 (UTC) FILETIME=[06668640:01CC5734] Subject: Re: [Roll] Question/clarification about applicability of OF0 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 08:03:15 -0000 Hi Ralph > OF0, when it generates a rank_increase based on hop count, is characterized > as inappropriate for wireless meshes. I wonder if "wireless" is really the right > descriptive term here. More generally, a hop count metric is inappropriate > for subnets composed of links in which a route with a higher hop count might > perform better than a router with a lower hop count. Such subnets can be > either wireless or wired; for example, as I understand the technology, it's > possible for an IEEE1901.2 network to exhibit connectivity and transmission > quality characteristics for which a route through more higher quality hops > might be better than a router through fewer lower quality hops. [Pascal] You're correct. OF0 does not know the type of link it can be applied to so it leaves the computation of the step_of_rank to the implementation that knows better. > I'm also confused about some of the use cases for RPL. Is there a use case in > which RPL would be used in a non-LLN environment in place of other routing > protocols like RIP, OSPF and ISIS? [Pascal] RPL is a DV routing protocol. It has the pros and cons of its family. But yes, it could apply in many places. It is a matter of network engineering to select the most adapted tool for a given situation, knowing that: -As opposed to the classical bunch, it does not compute the optimal end to end path for all nodes.=20 -RPL does not try to fix any broken situation as soon as it occurs.=20 -RPL requires looking inside the packets for datapath validation, and RPL adds a (set of) L3 "VLANs" we call instances If you look at it, a spanning tree is not much different, just a lot simpler (just a tree, no TTL). So in a situation where a (mesh_under) spanning tree is used today a (route_over) RPL solution could actually provide a positive replacement. Benefits would be: - no risk of meltdown (that's TTL for you) thus faster convergence. - end to end IP (that's route_over vs. mesh_under) - multipath ( that's coming from RPL's DAG) - Goal (the root is picked at a sensible place) Another example: If you have a number of access points at home, and you want to mesh them, then the link quality is asserted by the association process so hop count could work. You'll note that with hop count, a cost is traditionally associated to link speed and that would apply too since WIFI reduces the link speed to maintain the link quality. This is a case where RPL could easily replace a proprietary mesh technology, either using (hop count, line speed), something a bit fancier, like ETX, or something more proprietary if that can provide a market advantage. OF0 will allow all those to interoperate and you'll get a DAG that reaches the goal, if that's possible at all. Cheers, Pascal From daniel.gavelle@nxp.com Wed Aug 10 01:25:22 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88AAF21F8715 for ; Wed, 10 Aug 2011 01:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+A3N0P3Pxf4 for ; Wed, 10 Aug 2011 01:25:21 -0700 (PDT) Received: from be1ssnxpe1.nxp.com (be1ssnxpe1.nxp.com [57.67.164.69]) by ietfa.amsl.com (Postfix) with ESMTP id 844CA21F86BD for ; Wed, 10 Aug 2011 01:25:21 -0700 (PDT) Received: from eu1rdcrdc1vw040.exi.nxp.com ([134.27.176.148]) by be1ssnxpe1.nxp.com (8.14.4/8.14.4) with ESMTP id p7A8Pl2f022099 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 10 Aug 2011 10:25:47 +0200 Received: from eu1rdcrdc1wx032.exi.nxp.com ([134.27.179.186]) by eu1rdcrdc1vw040.exi.nxp.com ([134.27.176.148]) with mapi; Wed, 10 Aug 2011 10:25:47 +0200 From: Daniel Gavelle To: Dario Tedeschi , "'ROLL WG'" Date: Wed, 10 Aug 2011 10:25:44 +0200 Thread-Topic: [Roll] IP-in-IP tunneling for HbH Option Thread-Index: AcxTxGflZ90I4MIvQ3mtBgN9ydaCzADbxoGA Message-ID: <78B923726E7D59429936580CF127E943A17BFBFF1A@eu1rdcrdc1wx032.exi.nxp.com> References: <4E3C7795.1030701@exegin.com> In-Reply-To: <4E3C7795.1030701@exegin.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-08-10_02:2011-08-10, 2011-08-09, 1970-01-01 signatures=0 Subject: Re: [Roll] IP-in-IP tunneling for HbH Option X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 08:25:22 -0000 I like solution [2]. The rules are simpler on the router node. When using= 6LowPAN compression, the overhead for using a tunnel is about three bytes = rather than five. All the router nodes on the way up need to look past the= outer IP header to get to the hop by hop header to adjust the rank, so I d= on't think it's too bad that the root node also needs to look past the oute= r header in order to strip out the outer header and hop by hop header befor= e passing up. The root node doesn't need to look into or past the inner he= ader. In Zigbee, we always route off network through the root node and form a sep= arate DAG for each off network connection in a LowPAN. If it is possible f= or a single DAG to have multiple off network connections through multiple r= outer nodes, a modified solution [1] may be the better choice. The hop by = hop header would use the destination address of the router where the packet= will go off the network. I don't know how the routers would learn which n= odes perform the off network connection for which prefixes. This (and othe= r) reasons may make it impractical to ever route off network through any no= de but the root. Regards, Daniel. -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Dar= io Tedeschi Sent: 06 August 2011 00:07 To: 'ROLL WG' Subject: [Roll] IP-in-IP tunneling for HbH Option I been through the archived mailing list, but did not find an answer to=20 the following question: What destination address should be used in the outer header of a tunnel=20 when a router needs to add a RPL HbH option on behalf of a non-RPL aware=20 leaf node? There are three possibles I can see: [a]. Use the address of the root node. [b]. Use the destination address of the original IPv6 header. [c]. Use the address of your RPL parent. After some experimentation, I found that both [a] and [b] have issues=20 depending on the final destination (the destination of the original=20 datagram). I had thought of [c] as a solution, but quickly realized it=20 was a bad idea. Problem 1: Final destination is inside the RPL domain and [a] is used. --------- For any destination in the RPL domain, the datagram is always sent to=20 the root node even when the path to the root includes a node having the=20 final destination address or a matching routing entry. This seems=20 inefficient at best. Particularly when used in a storing-mode RPL network. Problem 2: Final destination address is outside the RPL domain via the=20 BR and [b] is used. --------- The BR will not decapsulate, because the destination address of the=20 datagram is not one of the BRs addresses (i.e. the datagram is not meant=20 for it but some other destination). This means the BR will just forward=20 the datagram to the next-hop outside the RPL domain. The final=20 destination is not a tunnel exit-point so it then sends a "Parameter=20 Problem" message with code=3D1 back to the source (i.e. the entry-point of= =20 the tunnel). Problem 3: [c] is used. -------- Decapsulation and encapsulation of the original datagram would be=20 required at every upward hop within the RPL network. Solution 1: Use [a] or [b] depending on whether the final destination=20 is outside or inside the RPL domain. ------- How does a router know whether a destination is inside or outside the=20 RPL domain? Solution 2: Always use [b], but BRs strip off the outer header if=20 forwarding outside the RPL domain or forwarding using source-routing=20 inside the RPL domain. ------- This is a simple approach, but perhaps a little ugly. The forwarding=20 logic in the BR needs to look past the first IPv6 header to see if it's=20 a tunneled packet. If it is tunneled, the outer header is stripped off=20 and the original datagram is forwarded. Dario _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Wed Aug 10 06:21:44 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C6621F8865 for ; Wed, 10 Aug 2011 06:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2W5W8u7IUP1 for ; Wed, 10 Aug 2011 06:21:43 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 108DC21F873D for ; Wed, 10 Aug 2011 06:21:37 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 164D43418E; Wed, 10 Aug 2011 09:21:39 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id E711298411; Wed, 10 Aug 2011 09:22:03 -0400 (EDT) From: Michael Richardson To: Ralph Droms In-Reply-To: <3D21B0E7-C9D1-4335-B849-87DF61B2D6CD@gmail.com> References: <3D21B0E7-C9D1-4335-B849-87DF61B2D6CD@gmail.com> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 10 Aug 2011 09:22:03 -0400 Message-ID: <6490.1312982523@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] Question/clarification about applicability of OF0 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 13:21:44 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Ralph" =3D=3D Ralph Droms writes: Ralph> I'm also confused about some of the use cases for RPL. Is Ralph> there a use case in which RPL would be used in a non-LLN Ralph> environment in place of other routing protocols like RIP, Ralph> OSPF and ISIS? RPL fills a different niche than RIP/OSPF/ISIS. RIP/OSPF primarily is about connecting broadcast subnets together. While you can inject /32s(/128s) into OSPF, and maybe you can do this for RIPv2 (I never tried), it's not really the problem space that they were designed for. RPL really provides a replacement in some sense for layer-2 STP, doing the work at layer-3, and optimizing it for the case of not much bandwidth, and also for limited broadcast/multicast availability. If power and bandwidth were free, one could imagine using things like MSTP, and indeed there are things like 802.1s which do this at layer 2. The key thing is that the LLN wants to be a single subnet, not a series of layer-3 subnets which are tied together. The closest thing to RPL in a non-LLN situation today is, I think, TRILL. It however, is a layer-3-technology solution to a layer-2 problem, while RPL is a layer-2-technology solution at a layer-3. But, to answer your direct question, I don't think any of the use cases written imagine a purely non-LLN network. Some of them will, I think, have RPL running over a network in which parts of it are distinctly not low power or lossy, but that will be only *part* of the network.=20=20=20 I do not believe, btw, the documented use cases are comprehensive. The space is very much open, and RPL excites me because it can potentially bridge many layer-2 technologies. The use cases represent a set of requirements from industries that have sufficiently matured to articulate their problems.=20=20 =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATkKF+4CLcPvd0N1lAQIPEAf/ai29pqp9DiwycoCt4twrIRpWb4XVvuVh pB3YRbrCWeUTIR/fRCkq25/4c72OcGa8/ZYLQy5SrGonAwKtb9ItYdlx7cYYHs7y dlhhR0km2+i3MzHc1VJfwGMm9Vo9WOLSnwQr9Dn5XZd32yuyHIVmjghqaZvXIkaN wTizf7A2NXEhTH0QK+hgg+QSqggYO7HPHHzFjmu9wbX8Mnr50NxOYygEQ7UNixFa LcTaPN3wSTU4FzztMaQnjCkU8KD13kyTMq9MOBAzklfYsyDQJgYemAbPHhLI0YDw xMmc9EmtKb1J31Vn99QceSY8rvJ7Ipqe09HzOLRAoddVigB7VB19Ww== =NSVA -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Wed Aug 10 06:29:13 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8947C21F86DD; Wed, 10 Aug 2011 06:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.888 X-Spam-Level: X-Spam-Status: No, score=-0.888 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwjWNyr16W4T; Wed, 10 Aug 2011 06:29:13 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF9721F85FF; Wed, 10 Aug 2011 06:29:13 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 3DF9A341EB; Wed, 10 Aug 2011 09:29:17 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 2BF5D98411; Wed, 10 Aug 2011 09:29:42 -0400 (EDT) From: Michael Richardson In-Reply-To: <2982.1312901544@marajade.sandelman.ca> References: <20110808232350.30897.61741.idtracker@ietfa.amsl.com> <2982.1312901544@marajade.sandelman.ca> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Wed, 10 Aug 2011 09:29:42 -0400 Message-ID: <7609.1312982982@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org, draft-ietf-roll-of0@tools.ietf.org, roll-chairs@tools.ietf.org, The IESG Subject: Re: [Roll] Ralph Droms' Discuss on draft-ietf-roll-of0-15: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 13:29:13 -0000 >>>>> "Michael" == Michael Richardson writes: >>>>> "Ralph" == Ralph Droms writes: Ralph> 5. In section 4.2.1, what does it mean to "validate a Ralph> router"? Why would a router that passes validation Ralph> ("succeeded that validation process") only be "preferable"? Michael> I think, it refers to rpl-19 section 3.2.3, to the Michael> "authenticated" mode. This mode is completely unworkable Michael> with asymmetric crypto. I guess I need to write an ID that Michael> explains this better. Should read: This mode is completely unworkable *without* asymmetric crypto. From prvs=196a07912=Tzeta.Tsao@cooperindustries.com Wed Aug 10 08:03:31 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5AD21F8747; Wed, 10 Aug 2011 08:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZesO50orwdXE; Wed, 10 Aug 2011 08:03:30 -0700 (PDT) Received: from cooperlighting-sw.cooperlighting.com (cooperlighting-sw.cooperlighting.com [216.130.131.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1B13421F86D6; Wed, 10 Aug 2011 08:03:26 -0700 (PDT) Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.67,351,1309752000"; d="scan'208";a="21105930" Received: from cipt0175.nam.ci.root ([10.132.108.175]) by cooperlighting-sw.cooperlighting.com with ESMTP; 10 Aug 2011 11:03:58 -0400 Received: from EVS4.NAM.CI.ROOT ([10.132.108.172]) by cipt0175.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Aug 2011 11:03:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Aug 2011 11:03:18 -0400 Message-ID: <9BB070DB2D281946859EA89837931EEE01AE607A@EVS4.nam.ci.root> In-Reply-To: <7609.1312982982@marajade.sandelman.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Ralph Droms' Discuss on draft-ietf-roll-of0-15: (withDISCUSS and COMMENT) thread-index: AcxXYZST06Z+j2+nRXqGeukhmW+pyAADJH4A References: <20110808232350.30897.61741.idtracker@ietfa.amsl.com><2982.1312901544@marajade.sandelman.ca> <7609.1312982982@marajade.sandelman.ca> From: "Tsao, Tzeta" To: "Michael Richardson" X-OriginalArrivalTime: 10 Aug 2011 15:03:57.0730 (UTC) FILETIME=[BAB45020:01CC576E] Cc: roll@ietf.org, draft-ietf-roll-of0@tools.ietf.org, The IESG , roll-chairs@tools.ietf.org Subject: Re: [Roll] Ralph Droms' Discuss on draft-ietf-roll-of0-15: (withDISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 15:03:31 -0000 Hi Michael, I have tried to find your previous comments on the issue of using symmetric key for authentication but could still not quite understand. Could you give a summary here before the ID is available? Thanks, Tzeta > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Michael Richardson > Sent: Wednesday, August 10, 2011 9:30 AM > Cc: roll@ietf.org; draft-ietf-roll-of0@tools.ietf.org; roll- > chairs@tools.ietf.org; The IESG > Subject: Re: [Roll] Ralph Droms' Discuss on draft-ietf-roll-of0-15: > (withDISCUSS and COMMENT) >=20 >=20 > >>>>> "Michael" =3D=3D Michael Richardson writes: > >>>>> "Ralph" =3D=3D Ralph Droms writes: > Ralph> 5. In section 4.2.1, what does it mean to "validate a > Ralph> router"? Why would a router that passes validation > Ralph> ("succeeded that validation process") only be "preferable"? >=20 > Michael> I think, it refers to rpl-19 section 3.2.3, to the > Michael> "authenticated" mode. This mode is completely unworkable > Michael> with asymmetric crypto. I guess I need to write an ID > that > Michael> explains this better. >=20 > Should read: > This mode is completely unworkable *without* asymmetric crypto. >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Wed Aug 10 09:33:53 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659E121F8922 for ; Wed, 10 Aug 2011 09:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.131 X-Spam-Level: X-Spam-Status: No, score=-10.131 tagged_above=-999 required=5 tests=[AWL=0.468, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B35ROWLG3EeU for ; Wed, 10 Aug 2011 09:33:52 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 33A1521F88DC for ; Wed, 10 Aug 2011 09:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=3573; q=dns/txt; s=iport; t=1312994064; x=1314203664; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=oh7do61QfsIbU5MOQrnxj1ITWQU+oi0zLfgwW2N02Pc=; b=kxRtxfQUSDeuIjAoKC7LufbvA32Ebvv3ASMU5+oDOHspKZCaAwaeXCLD Zkitp2+YLsPFDALDaQHQHlT1CauQj0ZqydXHIGOHIUNtzB90XQslmsDP9 j7xmjQTmMw175Bd6DAApqfTLekYbGP54Ddy5kg+py1CPNtSrlwkmR6RzV I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0AACOyQk6Q/khM/2dsb2JhbABCl3CPRneBQAEBAQEDEgEdCj8MBAIBCA4DBAEBCwYXAQYBICUJCAEBBBMIEQIHh1CfUAGRQY0UhWdfBJgchF6Gfg X-IronPort-AV: E=Sophos;i="4.67,351,1309737600"; d="scan'208";a="109204612" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 10 Aug 2011 16:34:20 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7AGYKX5016725; Wed, 10 Aug 2011 16:34:20 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Aug 2011 18:34:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Aug 2011 18:34:17 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D05465999@XMB-AMS-107.cisco.com> In-Reply-To: <6490.1312982523@marajade.sandelman.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Question/clarification about applicability of OF0 Thread-Index: AcxXYInpBq2cxSIyQ82J4NDqWagD9AAGY+uw References: <3D21B0E7-C9D1-4335-B849-87DF61B2D6CD@gmail.com> <6490.1312982523@marajade.sandelman.ca> From: "Pascal Thubert (pthubert)" To: "Michael Richardson" X-OriginalArrivalTime: 10 Aug 2011 16:34:20.0932 (UTC) FILETIME=[5B2F4440:01CC577B] Cc: roll@ietf.org, "Ralph Droms \(rdroms\)" Subject: Re: [Roll] Question/clarification about applicability of OF0 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 16:33:53 -0000 Hello Michael I like the text a lot : ) and deeply agree for the most part. Please note that RPL is not limited to intra-subnet though it has special methods for that case. RPL can also route between subnets/aggregations, which is actually a simpler case.=20 For instance, this can be used between mobile routers for nested NEMO route optimization. The key things are rather: - the shape of network RPL builds with the concept of root that plays a major role. RPL builds an edge network, as opposed to incumbent IGPs that build a core with any-to-any optimization. - the metrics (RPL is a lot richer than incumbents). - the instances (RPL allows routing and forwarding along multiple topologies) The edge used to be the PC to router like. In a home network that was a PC with a modem. Now it's getting a lot more than that as the HOMENET people are figuring out at this very moment.=20 Cheers, Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Michael Richardson > Sent: Wednesday, August 10, 2011 3:22 PM > To: Ralph Droms > Cc: roll@ietf.org > Subject: Re: [Roll] Question/clarification about applicability of OF0 >=20 >=20 > >>>>> "Ralph" =3D=3D Ralph Droms writes: > Ralph> I'm also confused about some of the use cases for RPL. Is > Ralph> there a use case in which RPL would be used in a non-LLN > Ralph> environment in place of other routing protocols like RIP, > Ralph> OSPF and ISIS? >=20 > RPL fills a different niche than RIP/OSPF/ISIS. RIP/OSPF primarily is > about connecting broadcast subnets together. While you can inject > /32s(/128s) into OSPF, and maybe you can do this for RIPv2 (I never > tried), it's not really the problem space that they were designed for. >=20 > RPL really provides a replacement in some sense for layer-2 STP, doing > the work at layer-3, and optimizing it for the case of not much > bandwidth, and also for limited broadcast/multicast availability. > If power and bandwidth were free, one could imagine using things like > MSTP, and indeed there are things like 802.1s which do this at layer 2. >=20 > The key thing is that the LLN wants to be a single subnet, not a series > of layer-3 subnets which are tied together. >=20 > The closest thing to RPL in a non-LLN situation today is, I think, > TRILL. It however, is a layer-3-technology solution to a layer-2 > problem, while RPL is a layer-2-technology solution at a layer-3. >=20 > But, to answer your direct question, I don't think any of the use > cases written imagine a purely non-LLN network. Some of them will, I > think, have RPL running over a network in which parts of it are > distinctly not low power or lossy, but that will be only *part* of the > network. >=20 > I do not believe, btw, the documented use cases are comprehensive. > The space is very much open, and RPL excites me because it can > potentially bridge many layer-2 technologies. The use cases represent a > set of requirements from industries that have sufficiently matured to > articulate their problems. >=20 > -- > ] He who is tired of Weird Al is tired of life! | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ > |device driver[ > Kyoto Plus: watch the video > > then sign the petition. >=20 From dat@exegin.com Fri Aug 12 14:55:54 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFA321F8770 for ; Fri, 12 Aug 2011 14:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Sm4pRIKuoto for ; Fri, 12 Aug 2011 14:55:53 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC2221F873D for ; Fri, 12 Aug 2011 14:55:50 -0700 (PDT) Received: by iye1 with SMTP id 1so2640260iye.27 for ; Fri, 12 Aug 2011 14:56:28 -0700 (PDT) Received: by 10.231.4.41 with SMTP id 41mr2695135ibp.44.1313186188783; Fri, 12 Aug 2011 14:56:28 -0700 (PDT) Received: from [172.16.1.52] ([216.251.130.154]) by mx.google.com with ESMTPS id x18sm582264ibe.40.2011.08.12.14.56.27 (version=SSLv3 cipher=OTHER); Fri, 12 Aug 2011 14:56:28 -0700 (PDT) Message-ID: <4E45A195.9040303@exegin.com> Date: Fri, 12 Aug 2011 14:56:37 -0700 From: Dario Tedeschi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Daniel Gavelle References: <4E3C7795.1030701@exegin.com> <78B923726E7D59429936580CF127E943A17BFBFF1A@eu1rdcrdc1wx032.exi.nxp.com> In-Reply-To: <78B923726E7D59429936580CF127E943A17BFBFF1A@eu1rdcrdc1wx032.exi.nxp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'ROLL WG' Subject: Re: [Roll] IP-in-IP tunneling for HbH Option X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 21:55:54 -0000 Hi Daniel > I like solution [2]. As do I, for simplicity and efficiency sake. > All the router nodes on the way up need to look past the outer IP header to get to the hop by hop header to adjust the rank, ... Not so. An intermediate router never looks past the outer header, unless the destination address in the outer header is one of its own. Solution 2 would bend that rule, but only at the BR. The reason tunneling is used for the upward path is to add the RPL HbH option if one was not already present in the original packet. Think of a host sending a packet to it's default router (a RPL aware router): The host knows nothing about RPL and, therefore, can't add a RPL HbH option. In order for the router to forward the packet in the RPL network, it must add the HbH option. Tunneling allows it to do that without modifying the original packet. It also means that a forwarding error within the RPL network, for that packet, will be sent back to the router and not the host, since the source address of the outer header is the address of the router. The router would, thus, have a chance to act on the error (e.g re-parent or reset the trickle timer). Dario > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Dario Tedeschi > Sent: 06 August 2011 00:07 > To: 'ROLL WG' > Subject: [Roll] IP-in-IP tunneling for HbH Option > > > I been through the archived mailing list, but did not find an answer to > the following question: > > What destination address should be used in the outer header of a tunnel > when a router needs to add a RPL HbH option on behalf of a non-RPL aware > leaf node? There are three possibles I can see: > [a]. Use the address of the root node. > [b]. Use the destination address of the original IPv6 header. > [c]. Use the address of your RPL parent. > > After some experimentation, I found that both [a] and [b] have issues > depending on the final destination (the destination of the original > datagram). I had thought of [c] as a solution, but quickly realized it > was a bad idea. > > Problem 1: Final destination is inside the RPL domain and [a] is used. > --------- > For any destination in the RPL domain, the datagram is always sent to > the root node even when the path to the root includes a node having the > final destination address or a matching routing entry. This seems > inefficient at best. Particularly when used in a storing-mode RPL network. > > Problem 2: Final destination address is outside the RPL domain via the > BR and [b] is used. > --------- > The BR will not decapsulate, because the destination address of the > datagram is not one of the BRs addresses (i.e. the datagram is not meant > for it but some other destination). This means the BR will just forward > the datagram to the next-hop outside the RPL domain. The final > destination is not a tunnel exit-point so it then sends a "Parameter > Problem" message with code=1 back to the source (i.e. the entry-point of > the tunnel). > > Problem 3: [c] is used. > -------- > Decapsulation and encapsulation of the original datagram would be > required at every upward hop within the RPL network. > > > Solution 1: Use [a] or [b] depending on whether the final destination > is outside or inside the RPL domain. > ------- > How does a router know whether a destination is inside or outside the > RPL domain? > > > Solution 2: Always use [b], but BRs strip off the outer header if > forwarding outside the RPL domain or forwarding using source-routing > inside the RPL domain. > ------- > This is a simple approach, but perhaps a little ugly. The forwarding > logic in the BR needs to look past the first IPv6 header to see if it's > a tunneled packet. If it is tunneled, the outer header is stripped off > and the original datagram is forwarded. > > > Dario > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Thu Aug 18 00:24:27 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879175E8015 for ; Thu, 18 Aug 2011 00:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.222 X-Spam-Level: X-Spam-Status: No, score=-106.222 tagged_above=-999 required=5 tests=[AWL=-3.623, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCWC7YTQrRcD for ; Thu, 18 Aug 2011 00:24:26 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1825E800B for ; Thu, 18 Aug 2011 00:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=280; q=dns/txt; s=iport; t=1313652320; x=1314861920; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=iluN/sHIrtnY1Sg+Sc0TZTCHLSeXeHvG0GQBf6be9cM=; b=ls2z1c9exQiK0Q5YgUN46klGXzMG8B/LnNv/j86i3pMnhT0JM8lQ/bqp eTLmjqavh8N4CppxsDCXbXxtCTgtpJn3KsXdc1JlCx3ClvLBXdVc3eLQr iO8kcb4Ao8A1ZEbEy75Vro6QfyhHiFZCk3LA+zEHwzlOTcsa2jjiOk1rc E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEACO+TE6tJV2Z/2dsb2JhbABBqG93gVkBJ4F9HBmHUpg0gSMBnnWFaV8EkxOFFYti X-IronPort-AV: E=Sophos;i="4.68,243,1312156800"; d="scan'208";a="14224593" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 18 Aug 2011 07:25:20 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7I7P6s7004084 for ; Thu, 18 Aug 2011 07:25:19 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Aug 2011 09:25:18 +0200 Received: from ams-jvasseur-8914.cisco.com ([10.55.86.16]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Aug 2011 09:25:18 +0200 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Aug 2011 09:25:17 +0200 Message-Id: To: "roll@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 18 Aug 2011 07:25:18.0265 (UTC) FILETIME=[FB213290:01CC5D77] Subject: [Roll] IETF-81 ROLL WG Draft Minutes Posted X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 07:24:27 -0000 Dear all, The draft ROLL IETF-81 meeting minutes have been posted: = http://www.ietf.org/proceedings/81/minutes/roll.txt Please get back to us by Aug 25th if you have any comment. Special thank to Meral, Laurent and Dan for having taken the minutes. Thanks. JP.= From prvs=2089e48b2=mukul@uwm.edu Sun Aug 21 23:11:07 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8A721F8507 for ; Sun, 21 Aug 2011 23:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.092 X-Spam-Level: X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FkPGbaLmRiY for ; Sun, 21 Aug 2011 23:11:06 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7496E21F8500 for ; Sun, 21 Aug 2011 23:11:06 -0700 (PDT) Received: from mta01.pantherlink.uwm.edu ([129.89.7.132]) by ip2mta.uwm.edu with ESMTP; 22 Aug 2011 01:11:37 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 101C8E6A74 for ; Mon, 22 Aug 2011 01:12:09 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6rvYVNgfsVq for ; Mon, 22 Aug 2011 01:12:08 -0500 (CDT) Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id E45C1E6A70 for ; Mon, 22 Aug 2011 01:12:08 -0500 (CDT) Date: Mon, 22 Aug 2011 01:12:08 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <1886891399.50075.1313993528396.JavaMail.root@mail05.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] draft-goyal-roll-rpl-compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 06:11:07 -0000 Hi all I would like to solicit comments from the working group regarding the RPL message compression format specified in draft-goyal-roll-rpl-compression. I would like to know what are the perceived shortcomings of the draft that we could address. Regards Mukul From internet-drafts@ietf.org Mon Aug 22 07:14:21 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C80B21F8AF1; Mon, 22 Aug 2011 07:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgZNPYhICpKt; Mon, 22 Aug 2011 07:14:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39DC721F853E; Mon, 22 Aug 2011 07:14:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.59 Message-ID: <20110822141421.24632.22165.idtracker@ietfa.amsl.com> Date: Mon, 22 Aug 2011 07:14:21 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-of0-16.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 14:14:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : RPL Objective Function Zero Author(s) : Pascal Thubert Filename : draft-ietf-roll-of0-16.txt Pages : 13 Date : 2011-08-22 The Routing Protocol for Low Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of networks types by the application of specific Objective Functions. An Objective Function defines how a RPL node selects and optimizes routes within a RPL Instance based on the information objects available. This document specifies a basic Objective Function that relies only on the objects that are defined in RPL and does not use any extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-16.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-of0-16.txt From jpv@cisco.com Mon Aug 22 09:12:47 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A4F21F8B7B for ; Mon, 22 Aug 2011 09:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVAAqNzZCN0B for ; Mon, 22 Aug 2011 09:12:47 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 24BCB21F8B7C for ; Mon, 22 Aug 2011 09:12:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=455; q=dns/txt; s=iport; t=1314029615; x=1315239215; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=m5+SVSt3ZkW5lVGQOIxOgOYL1aYvL0QUs1k83GWJu4Q=; b=PXl0zEh334b4Sq0+CneqsISQbjb2v5HmHGESNLae1+8c72qeEC6NipIL OsWiEPC0nszj/FaIZ9GgelyoPUSf9Cx/BWqtrPXXrJiJ/UmSsFXWX5rXS 8zlvZdIdx886W0ogfXjuIOWTk30Z9MOq+4HmUnpoiEJ/ljtUhF8I9nXcT 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAOt/Uk5Io8UR/2dsb2JhbABBqA53gUABAQEBAgEBAQEPAVsLBQsLRicwBhMih08ElmoBnlCFaV8EkxSFDAmLZA X-IronPort-AV: E=Sophos;i="4.68,263,1312156800"; d="scan'208";a="111911817" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 22 Aug 2011 16:13:18 +0000 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7MGDHjY019795; Mon, 22 Aug 2011 16:13:17 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Aug 2011 00:13:16 +0800 Received: from [10.60.114.229] ([10.60.114.229]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Aug 2011 00:13:16 +0800 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: JP Vasseur In-Reply-To: Date: Mon, 22 Aug 2011 18:13:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7FD3E651-EBFA-4A8B-9DD5-B3EB58AA914F@cisco.com> References: To: Ulrich Herberg X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 22 Aug 2011 16:13:16.0624 (UTC) FILETIME=[668E2D00:01CC60E6] Cc: roll WG Subject: Re: [Roll] Intended status of draft-ietf-roll-applicability-ami-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 16:12:47 -0000 Hi Ulrich, On Jul 29, 2011, at 11:54 PM, Ulrich Herberg wrote: > Hi, >=20 > is the intended status of draft-ietf-roll-applicability-ami-01 really = Standards Track? Or should it be informational? >=20 The idea was to select the Std track using RFC2119 language.=20 Thanks. JP. > Regards > Ulrich > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Mon Aug 22 09:27:48 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E5521F8B5E for ; Mon, 22 Aug 2011 09:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqMNhjHr63gA for ; Mon, 22 Aug 2011 09:27:48 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 153DE21F8B52 for ; Mon, 22 Aug 2011 09:27:48 -0700 (PDT) Received: from dn0a2103ef.sunet ([10.33.3.239]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1QvXMq-0001Jf-6u; Mon, 22 Aug 2011 09:28:52 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <7FD3E651-EBFA-4A8B-9DD5-B3EB58AA914F@cisco.com> Date: Mon, 22 Aug 2011 09:28:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <21638647-BDD7-442C-A271-F9B5ED1660FA@cs.stanford.edu> References: <7FD3E651-EBFA-4A8B-9DD5-B3EB58AA914F@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1084) X-Scan-Signature: 2d1a4fa5d0150c38835749a59b44c419 Cc: roll WG Subject: Re: [Roll] Intended status of draft-ietf-roll-applicability-ami-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 16:27:48 -0000 All of the requirements statements are Informational; why is an = applicability statement (which is for the most part a post-factor = analysis of whether something meets the space's requirements) Standards = Track? Phil On Aug 22, 2011, at 9:13 AM, JP Vasseur wrote: > Hi Ulrich, >=20 > On Jul 29, 2011, at 11:54 PM, Ulrich Herberg wrote: >=20 >> Hi, >>=20 >> is the intended status of draft-ietf-roll-applicability-ami-01 really = Standards Track? Or should it be informational? >>=20 >=20 > The idea was to select the Std track using RFC2119 language.=20 >=20 > Thanks. >=20 > JP. >=20 >> Regards >> Ulrich >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Mon Aug 22 09:34:43 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E50321F8BA9 for ; Mon, 22 Aug 2011 09:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6xlvRSRrTE1 for ; Mon, 22 Aug 2011 09:34:42 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8069421F8BA4 for ; Mon, 22 Aug 2011 09:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=4099; q=dns/txt; s=iport; t=1314030948; x=1315240548; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=n4pmyYZY/pUxJ+sDPkhyIW8DWt0SqatycNKsxEdpnM4=; b=lIFNdfnTDPUCEFTGdZfFubjvgKn5swZ2AiIP/uh94yCwGxUfu3j69pHl 8gHWwionZ1dMZFyALKQ0wxclcRf7y+wcroHVOczLROtOq3eE/M0FnIoQC 7aSeefQ+IQle/fEtexFEDme/5yH4PAune/wp/wwtd/L+hYxImjLMU9taS o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABiFUk6rRDoI/2dsb2JhbABBDqgBd4FAAQEBAQIBAQEBDwEaQQsFCwsECgouJzAGARIih08ElksBnlSFaV8EkxSFDAmLKjo X-IronPort-AV: E=Sophos;i="4.68,263,1312156800"; d="scan'208,217";a="15357758" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-6.cisco.com with ESMTP; 22 Aug 2011 16:35:38 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7MGZcNo014099; Mon, 22 Aug 2011 16:35:38 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Aug 2011 09:35:37 -0700 Received: from [10.60.114.229] ([10.60.114.229]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Aug 2011 09:35:37 -0700 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_11A89A42-917F-474C-B34D-782C2A8C2071" From: JP Vasseur In-Reply-To: <21638647-BDD7-442C-A271-F9B5ED1660FA@cs.stanford.edu> Date: Mon, 22 Aug 2011 18:35:35 +0200 Message-Id: <218E2A73-F8DE-45DB-930B-0F2A60F645F4@cisco.com> References: <7FD3E651-EBFA-4A8B-9DD5-B3EB58AA914F@cisco.com> <21638647-BDD7-442C-A271-F9B5ED1660FA@cs.stanford.edu> To: Philip Levis , Adrian Farrel X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 22 Aug 2011 16:35:37.0572 (UTC) FILETIME=[85D29A40:01CC60E9] Cc: roll WG Subject: Re: [Roll] Intended status of draft-ietf-roll-applicability-ami-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 16:34:43 -0000 --Apple-Mail=_11A89A42-917F-474C-B34D-782C2A8C2071 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 This was discussed by the IESG but I do not have a strong preference = quite frankly and our charter was originally "informational". Adrian, what is your take ? Cheers. JP. On Aug 22, 2011, at 6:28 PM, Philip Levis wrote: > All of the requirements statements are Informational; why is an = applicability statement (which is for the most part a post-factor = analysis of whether something meets the space's requirements) Standards = Track? >=20 > Phil >=20 > On Aug 22, 2011, at 9:13 AM, JP Vasseur wrote: >=20 > > Hi Ulrich, > > > > On Jul 29, 2011, at 11:54 PM, Ulrich Herberg wrote: > > > >> Hi, > >> > >> is the intended status of draft-ietf-roll-applicability-ami-01 = really Standards Track? Or should it be informational? > >> > > > > The idea was to select the Std track using RFC2119 language. > > > > Thanks. > > > > JP. > > > >> Regards > >> Ulrich > >> _______________________________________________ > >> 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 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 --Apple-Mail=_11A89A42-917F-474C-B34D-782C2A8C2071 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 This was discussed by the IESG but I do not have a strong preference quite frankly and our charter was originally "informational".
Adrian, what is your take ?

Cheers.

JP.

On Aug 22, 2011, at 6:28 PM, Philip Levis wrote:

Re: [Roll] Intended status of draft-ietf-roll-applicability-ami-01

All of the requirements statements are Informational; why is an applicability statement (which is for the most part a post-factor analysis of whether something meets the space's requirements) Standards Track?

Phil

On Aug 22, 2011, at 9:13 AM, JP Vasseur wrote:

> Hi Ulrich,
>
> On Jul 29, 2011, at 11:54 PM, Ulrich Herberg wrote:
>
>> Hi,
>>
>> is the intended status of draft-ietf-roll-applicability-ami-01 really Standards Track? Or should it be informational?
>>
>
> The idea was to select the Std track using RFC2119 language.
>
> Thanks.
>
> JP.
>
>> Regards
>> Ulrich
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

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


--Apple-Mail=_11A89A42-917F-474C-B34D-782C2A8C2071-- From mcr@sandelman.ca Tue Aug 23 13:29:19 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7BDA21F8C6D for ; Tue, 23 Aug 2011 13:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.31 X-Spam-Level: X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_40=-0.185, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ikh5EPbnZFSI for ; Tue, 23 Aug 2011 13:29:19 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 162CF21F8C1A for ; Tue, 23 Aug 2011 13:29:17 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id E4E673427E; Tue, 23 Aug 2011 16:29:47 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id ABB5E98B14; Tue, 23 Aug 2011 16:30:47 -0400 (EDT) From: Michael Richardson To: Philip Levis In-Reply-To: <21638647-BDD7-442C-A271-F9B5ED1660FA@cs.stanford.edu> References: <7FD3E651-EBFA-4A8B-9DD5-B3EB58AA914F@cisco.com> <21638647-BDD7-442C-A271-F9B5ED1660FA@cs.stanford.edu> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 23 Aug 2011 16:30:47 -0400 Message-ID: <27593.1314131447@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll WG Subject: Re: [Roll] Intended status of draft-ietf-roll-applicability-ami-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 20:29:20 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Philip" =3D=3D Philip Levis writes: Philip> All of the requirements statements are Informational; why is Philip> an applicability statement (which is for the most part a Philip> post-factor analysis of whether something meets the space's Philip> requirements) Standards Track? As the Applicability Statement lists what parts of the protocol are requires for a particular environment, if it isn't standards track, then *technically*, it won't be pass NAFTA Article 10.06, and so governments won't be able to procure it properly. In practice, the NAFTA tribunal thinks that all RFCs are STDs, but that's not something we should encourage. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATlQN94CLcPvd0N1lAQIJ1AgAvhCUDHBLGorOvW7gQ9PytuV4+oB/gHC2 Rq0XttyU/6jZaunCQzVI229dCEuQBAvPIZzm/hnPIdGtRUaE+c8wmHcFzVBf4T5R ZRwGI6s6/gFmCs9bLpzoUNbkBpAt+irtouyvQoiZm7em/eiJl0e7JlITBL9TKFuO UI2kB//k+tojT3zwxU68PsvwcITYi0OLXNsLiX3hvXAhiWkIu4+iyT001sVmaywU ArTb5xq58HmNFnfC1MxhADbAk4/LUUgyOWXcV6XDOev0zq+Ci/gPIaMDa0fUKTfn WHCoS+5BUT60sdqx3H/4LeMJxLDpRWpOhydKpICZw7Rm62i0XDp5HQ== =VwSW -----END PGP SIGNATURE----- --=-=-=-- From jpv@cisco.com Fri Aug 26 00:19:06 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6028C21F8B1D for ; Fri, 26 Aug 2011 00:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.369 X-Spam-Level: X-Spam-Status: No, score=-108.369 tagged_above=-999 required=5 tests=[AWL=2.230, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaIXHkIRY01p for ; Fri, 26 Aug 2011 00:19:05 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 658E121F8B06 for ; Fri, 26 Aug 2011 00:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=340; q=dns/txt; s=iport; t=1314343221; x=1315552821; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=QkkNnfm4mfXAqAgyOE6SMwGhHUpGnES87y5itmaOQlM=; b=gYlPvnk4nvpMjykQetmMAhgePbn6xAh5KI1xbYrAp5AgzupOrFiCt1Hf etS48cVzw785/fSaL7wOPVACWYoLwlykks5ZTFFQkfZwRk/9KgO6lBBGc 0fAvDTrTTcyOoyscTSP+e6k7LqTTDOlXZzda7JwXxTzWMhqIMKgmdDLpZ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAAtIV05Io8UQ/2dsb2JhbABEqBN3gVkBZoE+NaJ7AZ8OhWxgBJMahQ0Ji2k X-IronPort-AV: E=Sophos;i="4.68,283,1312156800"; d="scan'208";a="52090998" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 26 Aug 2011 07:20:18 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7Q7KFc5028392; Fri, 26 Aug 2011 07:20:17 GMT Received: from xfe-bgl-411.cisco.com ([72.163.129.199]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 26 Aug 2011 12:50:04 +0530 Received: from [10.60.114.229] ([10.60.114.229]) by xfe-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 26 Aug 2011 12:50:03 +0530 From: JP Vasseur Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Aug 2011 09:17:42 +0200 Message-Id: <79860D3D-A86D-474B-BA0B-D4ADDC6977D9@cisco.com> To: roll WG Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 26 Aug 2011 07:20:04.0148 (UTC) FILETIME=[9334BF40:01CC63C0] Subject: [Roll] PLEASE Comment on draft-alexander-roll-mikey-lln-key-mgmt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 07:19:06 -0000 Dear all, Several of you expressed some interest in = draft-alexander-roll-mikey-lln-key-mgmt. That said, could you please comment on this I-D as soon as possible ? We need a key = management protocol and if it turns out that the WG wants to adopt this ID, I'll poll the WG to make it a WG = =85 Please comment. Thanks. JP.= From internet-drafts@ietf.org Fri Aug 26 02:12:23 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA47421F8B29; Fri, 26 Aug 2011 02:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URrBAX6LmqMK; Fri, 26 Aug 2011 02:12:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D509021F8B0C; Fri, 26 Aug 2011 02:12:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.59 Message-ID: <20110826091222.27220.22788.idtracker@ietfa.amsl.com> Date: Fri, 26 Aug 2011 02:12:22 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-of0-17.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 09:12:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : RPL Objective Function Zero Author(s) : Pascal Thubert Filename : draft-ietf-roll-of0-17.txt Pages : 14 Date : 2011-08-26 The Routing Protocol for Low Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of networks types by the application of specific Objective Functions (OFs). An OF states the outcome of the process used by a RPL node to select and optimize routes within a RPL Instance based on the information objects available; an OF is not an algorithm. This document specifies a basic Objective Function that relies only on the objects that are defined in RPL and does not use any protocol extension A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-17.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-of0-17.txt From internet-drafts@ietf.org Fri Aug 26 02:28:28 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3893A21F8B28; Fri, 26 Aug 2011 02:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-xzR5eEQWJg; Fri, 26 Aug 2011 02:28:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA8F21F8B06; Fri, 26 Aug 2011 02:28:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.59 Message-ID: <20110826092827.451.60892.idtracker@ietfa.amsl.com> Date: Fri, 26 Aug 2011 02:28:27 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-of0-18.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 09:28:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : RPL Objective Function Zero Author(s) : Pascal Thubert Filename : draft-ietf-roll-of0-18.txt Pages : 14 Date : 2011-08-26 The Routing Protocol for Low Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of networks types by the application of specific Objective Functions (OFs). An OF states the outcome of the process used by a RPL node to select and optimize routes within a RPL Instance based on the information objects available; an OF is not an algorithm. This document specifies a basic Objective Function that relies only on the objects that are defined in RPL and does not use any protocol extension A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-18.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-of0-18.txt From internet-drafts@ietf.org Fri Aug 26 06:04:05 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D6A21F8B50; Fri, 26 Aug 2011 06:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gabH1AjcsIQh; Fri, 26 Aug 2011 06:04:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E7E21F8ADE; Fri, 26 Aug 2011 06:04:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.59 Message-ID: <20110826130405.31198.30462.idtracker@ietfa.amsl.com> Date: Fri, 26 Aug 2011 06:04:05 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-of0-19.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 13:04:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : RPL Objective Function Zero Author(s) : Pascal Thubert Filename : draft-ietf-roll-of0-19.txt Pages : 14 Date : 2011-08-26 The Routing Protocol for Low Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of networks types by the application of specific Objective Functions (OFs). An OF states the outcome of the process used by a RPL node to select and optimize routes within a RPL Instance based on the information objects available; an OF is not an algorithm. This document specifies a basic Objective Function that relies only on the objects that are defined in RPL and does not use any protocol extension A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-19.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-of0-19.txt From nicolas.dejean.ietf@googlemail.com Tue Aug 30 00:56:25 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63E421F8B82 for ; Tue, 30 Aug 2011 00:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXXhiP3UujUw for ; Tue, 30 Aug 2011 00:56:25 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id A1AD721F8B7B for ; Tue, 30 Aug 2011 00:56:24 -0700 (PDT) Received: by pzk33 with SMTP id 33so21541975pzk.18 for ; Tue, 30 Aug 2011 00:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kdGx7ir1dSQbbVSoxdtfagriStw+Lp7BYUTgmiJUYMc=; b=n8q8gqH+MR62Ar0hLZcupLBSvEPyG+M/HYCR+X3eSHxT+AjPf5ZjLR6RXAw0w+DcaS 6U7ply52lsoM0NSta2FgYbrQ9JtwCEp/ZDk0s7muyJN9En1bfG6W0twAAH3hf10MMeFS 35PwDuznC7D9LsZEv9O4Pw2wT4AfpEJ0fVoIk= MIME-Version: 1.0 Received: by 10.142.150.5 with SMTP id x5mr3198301wfd.260.1314691071334; Tue, 30 Aug 2011 00:57:51 -0700 (PDT) Received: by 10.68.50.164 with HTTP; Tue, 30 Aug 2011 00:57:51 -0700 (PDT) In-Reply-To: <4E32B9D2.3000509@piuha.net> References: <4E32B9D2.3000509@piuha.net> Date: Tue, 30 Aug 2011 09:57:51 +0200 Message-ID: From: Nicolas DEJEAN To: Jari Arkko Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org Subject: Re: [Roll] review of draft-ietf-roll-applicability-ami X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 07:56:25 -0000 Hello Jari, sorry for the late reply but as you know, summer time is not the best period for being reactive. 2011/7/29 Jari Arkko : > I have reviewed this document, and had some comments: > > First off, I was one of the IESG members who have been asking for the ROLL > working group to produce applicability statement(s) about RPL. Thank you for > working on this! However, I think we are still not quite there. What at > least I was asking for was more about experience, measurements, and analysis > about how well RPL works in various types of networks. The current document > is more descriptive (talks about the RPL design goals, for instance) and > contains some profiling. While those parts are very useful as well, I feel > that the core part of the contribution that this applicability statement > should be making is missing. Perhaps the working should make an open call > for the experience/measurements/analysis that is needed. Some may already > exist, I'm sure. > > Some additional more detailed comments: > > The gas and water metering part discusses cases where the meters can or can > not rely on the networks that electricity measurement devices have created. > I think this description is not quite right. My experience is that gas and > water meters tend to exist in places with power easily available. In > Finland, for instance, water/heat pipe meters have been a standard for new > homes dating back at least 2004, and they all run from mains power. So I > think power will be available, and the ability to use another measuring > network is kind of a secondary issue (and reuse of other networks may be > more about administrative borders than about technology anyway). > Thank you very much for this description of the situation in Finland. I had never heard about that case However, from my own experience, even if some deployments allow relying on power for Water and Gas meters, I believe that in many other cases power is not available for those meters. This being said, we can consider two cases: another network is available or not. If another network is available (we assume it runs RPL), it seems a good idea that W/G meters uses it if possible (cf. DSMR in Netherlands or OMS in Germany for instance). If not, it is possible that a dedicated infrastructure is deployed for these fluids (there are some studies today in several European countries for deployments in the next years). This infrastructure might be mains powered or not and it makes sense to study how RPL could apply in this case. In all cases, it would be interesting that all the nodes (even those behaving as leaf nodes) know about RPL for having the ability to choose the best or at least a good enough route. Would you agree? > Both the electricity and gas/water sections appear to take it almost for > granted that multi-hop routing is necessary in these applications. That's > certainly one way of building the networks, and the reason for the existence > of this working group. But I would have expected that an applicability > statement talked about the situations where this works best versus > situations where some other solutions might work better. I see a lot of > one-hop commercial deployment in this space, for instance, the metering > systems in Finland are cellular-based. Is there something that you could say > about when the different approaches are best applicable? Or is that purely a > business issue, i.e., both work well and the only question is > equipment/provider cost? > I agree that different methods allow building metering networks. A lot of AMI networks are already deployed today with both star (one-hop) and mesh (multi-hop) topologies, depending on the capabilities of the underlying technology. However, the use RPL only makes sense in a mesh architecture. What we intend to do as authors (we have discussed this particular point) is to add a short introduction clarifying the scope of the document. It must be stated somewhere that different architecture could fit the requirements of AMI deployments and that the document describes how RPL can be used for this purpose in the case where multi-hop mesh architecture is used only. What do you think? Thank you, Nicolas. >> As a result, all smart metering traffic >> typically goes through the LBRs, with the vast majority of traffic >> flowing from smart meter devices to the head-end servers, i.e., in a >> Multipoint-to-Point (MP2P) fashion. >> > > I'm not so sure about this. Pure metering implementations may have > initiation on either side of the connection, and a request is likely to be a > small packet but so are responses. As you note yourself later, there are > firmware updates and other extraneous traffic cases that may balance the > small response - slightly bigger response equation. In any case, its pretty > useless of for me or you to guess -- but I'm guessing some actual operators > have real data about the traffic mix and directionality. Can that be cited? > > Jari > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From jpv@cisco.com Tue Aug 30 01:17:23 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD67721F8B8C for ; Tue, 30 Aug 2011 01:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVW0hMCaYrHW for ; Tue, 30 Aug 2011 01:17:23 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id ED8A121F8B94 for ; Tue, 30 Aug 2011 01:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=267; q=dns/txt; s=iport; t=1314692330; x=1315901930; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=llwz2np3+hRGSLDgnTQsOjM8bQ8vMXcku3MCrhbLrmk=; b=Ss5hz2cLBSYDqSeXCavzPbrcX+Bma6988kHN0zXAcAtdYpF18iYUggZs EBwZSlHmlLFDHvkCT6JNE7qzAapiz+muJBMycF623X+3r6qufPvUjwShX y+oKVvqmhy7zm8G1RIdh7mn0RkfYV6fbRznxev+9rDAkRcchHCRyzq6HF 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAJWcXE6rRDoI/2dsb2JhbABCqA93gVkBJzSBSTWdXoEjAZ9NhW1gBJMkhReLcA X-IronPort-AV: E=Sophos;i="4.68,301,1312156800"; d="scan'208";a="17706913" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-8.cisco.com with ESMTP; 30 Aug 2011 08:18:49 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7U8In51013891 for ; Tue, 30 Aug 2011 08:18:49 GMT Received: from xfe-sjc-221.amer.cisco.com ([128.107.191.32]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Aug 2011 01:18:49 -0700 Received: from ams-jvasseur-8911.cisco.com ([10.21.113.149]) by xfe-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Aug 2011 01:18:48 -0700 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Aug 2011 10:18:47 +0200 Message-Id: To: roll WG Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 30 Aug 2011 08:18:48.0866 (UTC) FILETIME=[71C10820:01CC66ED] Subject: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 08:17:23 -0000 Dear WG, draft-goyal-roll-rpl-compression was discussed during the last ROLL WG = meeting in Quebec, but as usual we confirm on the mailing list. Are in favor of adopting this = document as a WG document ? Please reply on the mailing list. Thanks. JP.= From nicolas.dejean.ietf@googlemail.com Tue Aug 30 01:24:25 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A8921F8BAD for ; Tue, 30 Aug 2011 01:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T77MtIX4xN3L for ; Tue, 30 Aug 2011 01:24:24 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE5B21F8B92 for ; Tue, 30 Aug 2011 01:24:24 -0700 (PDT) Received: by pzk33 with SMTP id 33so21621035pzk.18 for ; Tue, 30 Aug 2011 01:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Kldzb+J5x3GRmbTrcLYPyWEMI2TyXIlPyGKctVRDVys=; b=K1CSDt8wfylr8HRjEG4ETC9IS+7/jv8sR0kOzNoTghz6J3rFEH9y5jL5qG4FympEVb NYp83N7/vg47l1Z9jCXkl8Ksl22Bojbot2BKCsr5MwLvVyQLe2++DHnZqNpt5Kf1Lq8D oz/XpkIyVJEA8mr2oA4ya45baSogrn4bMgnbE= MIME-Version: 1.0 Received: by 10.142.143.6 with SMTP id q6mr2868617wfd.317.1314692751082; Tue, 30 Aug 2011 01:25:51 -0700 (PDT) Received: by 10.68.50.164 with HTTP; Tue, 30 Aug 2011 01:25:51 -0700 (PDT) In-Reply-To: References: <20110725182837.19651.12235.idtracker@ietfa.amsl.com> Date: Tue, 30 Aug 2011 10:25:51 +0200 Message-ID: From: Nicolas DEJEAN To: "Akyol, Bora A" Content-Type: text/plain; charset=ISO-8859-1 Cc: "roll@ietf.org" Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 08:24:25 -0000 Hello Bora, 2011/7/29 Akyol, Bora A : > I think the statement about AMI networks being used as an almost general > purpose backhaul network for all other devices > is overreaching. I know there are some utilities that are looking into > this, but a lot more that have shied away from > this vision. Secondly, there are a lot more AMI deployments not using > wireless mesh networks, e.g. using cellular modem, > powerline carrier, etc. I agree that all utilities are not looking into it. However this is one possible case that should be considered, isn't it? Could you please precise what you are expecting to be in the draft? > > Is it possible to tone this "marketing" text Section 1.1. down and also > potentially > remove Gas & Water meters from the scope of this document. > On our point of view, Gas and Water metering are part of AMI. Could you please elaborate? According to you, why should Gas and Water be removed from the draft? Thank you in advance, Nicolas. > Regards > > -- > Bora Akyol, Pacific Northwest National Laboratory > +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From ietf@thomasclausen.org Tue Aug 30 02:08:38 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0CA421F8B8B for ; Tue, 30 Aug 2011 02:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jM+YMUUkjZns for ; Tue, 30 Aug 2011 02:08:38 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:16]) by ietfa.amsl.com (Postfix) with ESMTP id 3F23221F8B8A for ; Tue, 30 Aug 2011 02:08:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6DFE94300E4; Tue, 30 Aug 2011 02:10:04 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.0.1.5] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 8A2A4430071; Tue, 30 Aug 2011 02:10:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Thomas Heide Clausen In-Reply-To: Date: Tue, 30 Aug 2011 11:10:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <36101A99-F6FC-4E94-A7D2-DD7EAB6CEBA3@thomasclausen.org> References: To: JP Vasseur X-Mailer: Apple Mail (2.1244.3) Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 09:08:38 -0000 All, Let me reiterate what I said at the Quebec meeting at the microphone: I = find it incomprehensible if - before the ink is dry on the RPL RFC and = before an RFC number has even been assigned to the specification - the = working group finds it necessary to invent a "compression mechanism" for = RPL.=20 After all, RPL was supposed to have been designed for networks with = (among other characteristics) a small MTU. If this document is necessary, then the logical conclusion would have to = be that the initial design of (at least) the packet format of RPL was = insufficient, and that therefore this document should either or both of = "Updates/Obsoletes" RPL? If this document is not intended to either or both of = "Updates/Obsoletes" RPL, then I do not see any justification for the = document being adopted. Respectfully Yours, Thomas On Aug 30, 2011, at 10:18 , JP Vasseur wrote: > Dear WG, >=20 > draft-goyal-roll-rpl-compression was discussed during the last ROLL WG = meeting in Quebec, but > as usual we confirm on the mailing list. Are in favor of adopting this = document as a WG document ? > Please reply on the mailing list. >=20 > Thanks. >=20 > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From emmanuel.baccelli@gmail.com Tue Aug 30 02:32:18 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F330D21F8BDC for ; Tue, 30 Aug 2011 02:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.643 X-Spam-Level: X-Spam-Status: No, score=-3.643 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJ79yMqD-AkM for ; Tue, 30 Aug 2011 02:32:17 -0700 (PDT) Received: from mail-ey0-f174.google.com (mail-ey0-f174.google.com [209.85.215.174]) by ietfa.amsl.com (Postfix) with ESMTP id A917721F88B6 for ; Tue, 30 Aug 2011 02:32:16 -0700 (PDT) Received: by eyx24 with SMTP id 24so4654205eyx.19 for ; Tue, 30 Aug 2011 02:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=CPIVCy8PrWZ90YJ6uqmuaSYSHrcsXHiSjJRwlfCNqEA=; b=Z6tC1/V8cPYMRFOKapWcB2EJ1ULFQzTqF8J7ly9nLnkgEA1L8NbMQtfIjXsdkVSjFx 7XRD9mAqDzaSJurKWZVGCi5YLwU3kdjN/CFV111PtPQsqCDQQgqrFenEnc+4CKhP/Z2I nhwQGMlSKX4r8/FflpJy7C8eMqgZgM4u89QPg= Received: by 10.14.18.198 with SMTP id l46mr794640eel.179.1314696822219; Tue, 30 Aug 2011 02:33:42 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.14.98.200 with HTTP; Tue, 30 Aug 2011 02:33:21 -0700 (PDT) In-Reply-To: <257580988.14571.1314695422865.JavaMail.root@zmbs1.inria.fr> References: <257580988.14571.1314695422865.JavaMail.root@zmbs1.inria.fr> From: Emmanuel Baccelli Date: Tue, 30 Aug 2011 11:33:21 +0200 X-Google-Sender-Auth: whzztd97CkOm-bUHe8CsZiacCF4 Message-ID: To: roll WG Content-Type: multipart/alternative; boundary=0016e64c38b413655404abb5b563 Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 09:32:18 -0000 --0016e64c38b413655404abb5b563 Content-Type: text/plain; charset=ISO-8859-1 Hi Thomas, I don't know about all the L2 technologies and all the applications that are intended to be used in conjunction with RPL. It's not my concern, but I suppose some of them may not need the compression scheme proposed in draft-goyal-roll-rpl-compression? It's not for me to say. All I know is that for the scenarios we target using P2P, we need a compression scheme. draft-goyal-roll-rpl-compression thus proposes a compression scheme tailored for this purpose. If others also need a compression scheme for other purposes, let it be known, and let's try to work on merging our requirements in the working group document to be. cheers, Emmanuel On Tue, Aug 30, 2011 at 11:10 AM, Thomas Heide Clausen < ietf@thomasclausen.org> wrote: > All, > > Let me reiterate what I said at the Quebec meeting at the microphone: I > find it incomprehensible if - before the ink is dry on the RPL RFC and > before an RFC number has even been assigned to the specification - the > working group finds it necessary to invent a "compression mechanism" for > RPL. > > After all, RPL was supposed to have been designed for networks with (among > other characteristics) a small MTU. > > If this document is necessary, then the logical conclusion would have to be > that the initial design of (at least) the packet format of RPL was > insufficient, and that therefore this document should either or both of > "Updates/Obsoletes" RPL? > > If this document is not intended to either or both of "Updates/Obsoletes" > RPL, then I do not see any justification for the document being adopted. > > Respectfully Yours, > > Thomas > > On Aug 30, 2011, at 10:18 , JP Vasseur wrote: > > > Dear WG, > > > > draft-goyal-roll-rpl-compression was discussed during the last ROLL WG > meeting in Quebec, but > > as usual we confirm on the mailing list. Are in favor of adopting this > document as a WG document ? > > Please reply 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 > --0016e64c38b413655404abb5b563 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Thomas,

I don't know about all the L2 technologies and = all the applications that are intended to be used in conjunction with RPL. = It's not my concern, but I suppose some of them may not need the compre= ssion scheme proposed in draft-goyal-roll-rpl-compression? It's not for= me to say.=A0

All I know is that for the scenarios we target using P2= P, we need a compression scheme. draft-goyal-roll-rpl-compression thus prop= oses a compression scheme tailored for this purpose.=A0

If others also need a compression scheme for other purposes, let it be= known, and let's try to work on merging our requirements in the workin= g group document to be.

cheers,

Emmanuel


On Tue, Au= g 30, 2011 at 11:10 AM, Thomas Heide Clausen <ietf@thomasclausen.org> wr= ote:
All,

Let me reiterate what I said at the Quebec meeting at the microphone: I fin= d it incomprehensible if - before the ink is dry on the RPL RFC and before = an RFC number has even been assigned to the specification - the working gro= up finds it necessary to invent a "compression mechanism" for RPL= .

After all, RPL was supposed to have been designed for networks with (among = other characteristics) a small MTU.

If this document is necessary, then the logical conclusion would have to be= that the initial design of (at least) the packet format of RPL was insuffi= cient, and that therefore this document should either or both of "Upda= tes/Obsoletes" RPL?

If this document is not intended to either or both of "Updates/Obsolet= es" RPL, then I do not see any justification for the document being ad= opted.

Respectfully Yours,

Thomas

On Aug 30, 2011, at 10:18 , JP Vasseur wrote:

> Dear WG,
>
> draft-goyal-roll-rpl-compression was discussed during the last ROLL WG= meeting in Quebec, but
> as usual we confirm on the mailing list. Are in favor of adopting this= document as a WG document ?
> Please reply 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
ht= tps://www.ietf.org/mailman/listinfo/roll

--0016e64c38b413655404abb5b563-- From jpv@cisco.com Tue Aug 30 02:47:00 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F153F21F8BAA for ; Tue, 30 Aug 2011 02:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rPUtq0LuD3O for ; Tue, 30 Aug 2011 02:47:00 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 0D41B21F8B9E for ; Tue, 30 Aug 2011 02:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=2022; q=dns/txt; s=iport; t=1314697707; x=1315907307; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=g6qrkeS9rfzUj1Dv5f7zutuwDjpR7MeFGZ9hmSj1y0w=; b=ZCIqTo6R9nLE14o2lmFGb36dXBVO5indxdektZZk3WX6c9bMHjKA+eYY +1XkDZeq5glS5u80ib7wJHPMDGGy+k0IIy5I85ihdlj8Incr39Fukxe5l yO6NbuYdG2kud+RXZIHqqE1u1ezYs7AK/JqhxV6bRGgzbls0CIGIUT+Yj o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKqxXE6rRDoI/2dsb2JhbABCqBN3gUABAQEBAgEBAQEPAVsLBQsLGC4nMAYTIodQBJcHAZ9UhW1gBJMkhReLcA X-IronPort-AV: E=Sophos;i="4.68,301,1312156800"; d="scan'208";a="17728246" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-8.cisco.com with ESMTP; 30 Aug 2011 09:48:26 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7U9mQ6p021482; Tue, 30 Aug 2011 09:48:26 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Aug 2011 02:48:26 -0700 Received: from ams-jvasseur-8911.cisco.com ([10.21.113.149]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Aug 2011 02:48:25 -0700 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: JP Vasseur In-Reply-To: <36101A99-F6FC-4E94-A7D2-DD7EAB6CEBA3@thomasclausen.org> Date: Tue, 30 Aug 2011 11:48:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <36101A99-F6FC-4E94-A7D2-DD7EAB6CEBA3@thomasclausen.org> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 30 Aug 2011 09:48:25.0794 (UTC) FILETIME=[F6A72220:01CC66F9] Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 09:47:01 -0000 Hi Thomas, Co-chair hat on, On Aug 30, 2011, at 11:10 AM, Thomas Heide Clausen wrote: > All, >=20 > Let me reiterate what I said at the Quebec meeting at the microphone: = I find it incomprehensible if - before the ink is dry on the RPL RFC and = before an RFC number has even been assigned to the specification - the = working group finds it necessary to invent a "compression mechanism" for = RPL.=20 >=20 > After all, RPL was supposed to have been designed for networks with = (among other characteristics) a small MTU. >=20 > If this document is necessary, then the logical conclusion would have = to be that the initial design of (at least) the packet format of RPL was = insufficient, and that therefore this document should either or both of = "Updates/Obsoletes" RPL? >=20 > If this document is not intended to either or both of = "Updates/Obsoletes" RPL, then I do not see any justification for the = document being adopted. >=20 Just chiming in since this is a procedural comment as opposed to = technical, the WG will voice his opinion. When a protocol is designed and the RFC has been approved, there is = nothing that prevents WG to make additions to it (isn't it what we are doing with pretty much all = protocols ?). When you invent a new TLV for=20 ISIS, you do not need to obsolete it ! Especially when the extension is = NOT mandatory but optional =85=20 Just clarifying for the rest of the group. Thanks. JP. > Respectfully Yours, >=20 > Thomas >=20 > On Aug 30, 2011, at 10:18 , JP Vasseur wrote: >=20 >> Dear WG, >>=20 >> draft-goyal-roll-rpl-compression was discussed during the last ROLL = WG meeting in Quebec, but >> as usual we confirm on the mailing list. Are in favor of adopting = this document as a WG document ? >> Please reply on the mailing list. >>=20 >> Thanks. >>=20 >> JP. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 From pthubert@cisco.com Tue Aug 30 04:53:03 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B82921F8AF4 for ; Tue, 30 Aug 2011 04:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.277 X-Spam-Level: X-Spam-Status: No, score=-10.277 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPHzhXdgbqFI for ; Tue, 30 Aug 2011 04:53:03 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id BA25421F8AED for ; Tue, 30 Aug 2011 04:53:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=910; q=dns/txt; s=iport; t=1314705270; x=1315914870; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=YI8IKoVhtJNXQWYvyD6EIrGmUcFbYvflDVYqTtgKjvU=; b=kvgBFJ55D6n0TiJmdnVPd/tn3tKZH1rHJDZD/4X7Y1kRddrpFxkAc6oG GDeBmvKsl4S1u5RJ+fuaRxBIYc+TwnbF2yGKYr5WDHayIZd15Udpta5CV CUg/6/b8tKcI1KqH8jyteA43XxOZuDq+dVVBz7qeQ+Zu+OiFY4djtWA2Z g=; X-IronPort-AV: E=Sophos;i="4.68,302,1312156800"; d="scan'208";a="52552228" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 30 Aug 2011 11:54:29 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7UBsTqe005270; Tue, 30 Aug 2011 11:54:29 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Aug 2011 13:54:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Aug 2011 13:54:28 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D055ADE46@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLLWG document Thread-Index: Acxm7Xb4eUpNOMzoRCGrVqannI0uUwAHaBNw References: From: "Pascal Thubert (pthubert)" To: "JP Vasseur" , "roll WG" X-OriginalArrivalTime: 30 Aug 2011 11:54:29.0651 (UTC) FILETIME=[93101E30:01CC670B] Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLLWG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 11:53:03 -0000 Hello This was discussed many times in the ML and the point was always to make = compression a separate spec to be implemented optionally for such types = of LLNs that would require it. It is good that the work has now started and I support it. Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = JP Vasseur Sent: mardi 30 ao=FBt 2011 10:19 To: roll WG Subject: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new = ROLLWG document Dear WG, draft-goyal-roll-rpl-compression was discussed during the last ROLL WG = meeting in Quebec, but as usual we confirm on the mailing list. Are in = favor of adopting this document as a WG document ? Please reply on the mailing list. Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From Daniel.Popa@itron.com Tue Aug 30 05:05:21 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E123521F8C43 for ; Tue, 30 Aug 2011 05:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2YlFKTWorG1 for ; Tue, 30 Aug 2011 05:05:21 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.115]) by ietfa.amsl.com (Postfix) with ESMTP id 1469C21F8C40 for ; Tue, 30 Aug 2011 05:05:20 -0700 (PDT) Received: from ITR-EXMBXVS-1.itron.com ([192.168.9.112]) by spo-exchcn-1.itron.com ([192.168.9.115]) with mapi; Tue, 30 Aug 2011 05:06:48 -0700 From: "Popa, Daniel" To: Emmanuel Baccelli , roll WG Date: Tue, 30 Aug 2011 05:06:41 -0700 Thread-Topic: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document Thread-Index: Acxm+AmlPtyzSk3XTVW+3f9qTqEN+gAFCpkw Message-ID: <83027ECE5ECDC04E9BA5350B756A88E159938E203E@ITR-EXMBXVS-1.itron.com> References: <257580988.14571.1314695422865.JavaMail.root@zmbs1.inria.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_83027ECE5ECDC04E9BA5350B756A88E159938E203EITREXMBXVS1it_" MIME-Version: 1.0 Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 12:05:22 -0000 --_000_83027ECE5ECDC04E9BA5350B756A88E159938E203EITREXMBXVS1it_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Emmanuel, Thomas, One case where we do not necessarily need compression is the use of the new= IEEE 802.15.4 amendments, specifically designed for smart grids. 802.15.4g= is a PHY Layer for Smart Utility Networks and 802.15.4e, a new MAC sub-lay= er that among others functionalities provide support for a 4g PHY layer. F= or information, 4g PHY amendment mandates the support of IPv6 MTU. Regards, Daniel From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Emm= anuel Baccelli Sent: Tuesday, August 30, 2011 11:33 AM To: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new R= OLL WG document Hi Thomas, I don't know about all the L2 technologies and all the applications that ar= e intended to be used in conjunction with RPL. It's not my concern, but I s= uppose some of them may not need the compression scheme proposed in draft-g= oyal-roll-rpl-compression? It's not for me to say. All I know is that for the scenarios we target using P2P, we need a compres= sion scheme. draft-goyal-roll-rpl-compression thus proposes a compression s= cheme tailored for this purpose. If others also need a compression scheme for other purposes, let it be know= n, and let's try to work on merging our requirements in the working group d= ocument to be. cheers, Emmanuel On Tue, Aug 30, 2011 at 11:10 AM, Thomas Heide Clausen > wrote: All, Let me reiterate what I said at the Quebec meeting at the microphone: I fin= d it incomprehensible if - before the ink is dry on the RPL RFC and before = an RFC number has even been assigned to the specification - the working gro= up finds it necessary to invent a "compression mechanism" for RPL. After all, RPL was supposed to have been designed for networks with (among = other characteristics) a small MTU. If this document is necessary, then the logical conclusion would have to be= that the initial design of (at least) the packet format of RPL was insuffi= cient, and that therefore this document should either or both of "Updates/O= bsoletes" RPL? If this document is not intended to either or both of "Updates/Obsoletes" R= PL, then I do not see any justification for the document being adopted. Respectfully Yours, Thomas On Aug 30, 2011, at 10:18 , JP Vasseur wrote: > Dear WG, > > draft-goyal-roll-rpl-compression was discussed during the last ROLL WG me= eting in Quebec, but > as usual we confirm on the mailing list. Are in favor of adopting this do= cument as a WG document ? > Please reply 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 --_000_83027ECE5ECDC04E9BA5350B756A88E159938E203EITREXMBXVS1it_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Emmanu= el, Thomas,

 

One case where we do not necessar= ily need compression is the use of the new IEEE 802.15.4 amendments, specif= ically designed for smart grids. 802.15.4g is a PHY Layer for Smart Utility= Networks and 802.15.4e, a new MAC sub-layer that among others functionalit= ies provide support for a 4g PHY layer.  For information, 4g PHY amend= ment mandates the support of IPv6 MTU.  

 

Regards,

Daniel

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.o= rg] On Behalf Of Emmanuel Baccelli
Sent: Tuesday, August 3= 0, 2011 11:33 AM
To: roll WG
Subject: Re: [Roll] Adopti= on of draft-goyal-roll-rpl-compression as a new ROLL WG document=

 

Hi Thomas,

 =

I don't know about all the L2 technolog= ies and all the applications that are intended to be used in conjunction wi= th RPL. It's not my concern, but I suppose some of them may not need the co= mpression scheme proposed in draft-goyal-roll-rpl-compression? It's not for= me to say. 

 =

All I know is that for the scenar= ios we target using P2P, we need a compression scheme. draft-goyal-roll-rpl= -compression thus proposes a compression scheme tailored for this purpose.&= nbsp;

 

If others also need a compression scheme for = other purposes, let it be known, and let's try to work on merging our requi= rements in the working group document to be.

 

cheers= ,

 

=

Emmanuel

 

On Tue, Aug 30, 2011 at 11:10 AM, Thomas Heide Clausen <ietf@thomasclausen.org> wrote:

All,
Let me reiterate what I said at the Quebec meeting at the microphone:= I find it incomprehensible if - before the ink is dry on the RPL RFC and b= efore an RFC number has even been assigned to the specification - the worki= ng group finds it necessary to invent a "compression mechanism" f= or RPL.

After all, RPL was supposed to have been designed for networ= ks with (among other characteristics) a small MTU.

If this document = is necessary, then the logical conclusion would have to be that the initial= design of (at least) the packet format of RPL was insufficient, and that t= herefore this document should either or both of "Updates/Obsoletes&quo= t; RPL?

If this document is not intended to either or both of "= Updates/Obsoletes" RPL, then I do not see any justification for the do= cument being adopted.

Respectfully Yours,

Thomas

On Au= g 30, 2011, at 10:18 , JP Vasseur wrote:

> Dear WG,
>
> draft-goyal-roll-rpl-compres= sion was discussed during the last ROLL WG meeting in Quebec, but
> a= s usual we confirm on the mailing list. Are in favor of adopting this docum= ent as a WG document ?
> Please reply on the mailing list.
>> Thanks.
>
> JP.
> _________________________________= ______________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

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

 

= --_000_83027ECE5ECDC04E9BA5350B756A88E159938E203EITREXMBXVS1it_-- From prvs=2160146b2=mukul@uwm.edu Tue Aug 30 09:11:23 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DCD21F8C9B for ; Tue, 30 Aug 2011 09:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=1.254, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64cPXpuWT8Vy for ; Tue, 30 Aug 2011 09:11:22 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 76DF621F8C71 for ; Tue, 30 Aug 2011 09:11:22 -0700 (PDT) Received: from localhost (HELO mta04.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 30 Aug 2011 11:11:31 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 08E252B3EDC; Tue, 30 Aug 2011 11:11:52 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EpOaw+ZM665; Tue, 30 Aug 2011 11:11:51 -0500 (CDT) Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 935202B3ED4; Tue, 30 Aug 2011 11:11:51 -0500 (CDT) Date: Tue, 30 Aug 2011 11:12:21 -0500 (CDT) From: Mukul Goyal To: Thomas Heide Clausen Message-ID: <1205642854.136273.1314720741252.JavaMail.root@mail05.pantherlink.uwm.edu> In-Reply-To: <36101A99-F6FC-4E94-A7D2-DD7EAB6CEBA3@thomasclausen.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 16:11:23 -0000 Thomas I am afraid I dont agree with your reasoning. Our draft specifies an optimization over the core spec. In many situations, you need this optimization and in many others you dont. Regards Mukul ----- Original Message ----- From: "Thomas Heide Clausen" To: "JP Vasseur" Cc: "roll WG" Sent: Tuesday, August 30, 2011 4:10:01 AM Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document All, Let me reiterate what I said at the Quebec meeting at the microphone: I find it incomprehensible if - before the ink is dry on the RPL RFC and before an RFC number has even been assigned to the specification - the working group finds it necessary to invent a "compression mechanism" for RPL. After all, RPL was supposed to have been designed for networks with (among other characteristics) a small MTU. If this document is necessary, then the logical conclusion would have to be that the initial design of (at least) the packet format of RPL was insufficient, and that therefore this document should either or both of "Updates/Obsoletes" RPL? If this document is not intended to either or both of "Updates/Obsoletes" RPL, then I do not see any justification for the document being adopted. Respectfully Yours, Thomas On Aug 30, 2011, at 10:18 , JP Vasseur wrote: > Dear WG, > > draft-goyal-roll-rpl-compression was discussed during the last ROLL WG meeting in Quebec, but > as usual we confirm on the mailing list. Are in favor of adopting this document as a WG document ? > Please reply 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 prvs=2163f0992=bora@pnnl.gov Tue Aug 30 10:35:26 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A6121F8C81 for ; Tue, 30 Aug 2011 10:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBatJUteq16Q for ; Tue, 30 Aug 2011 10:35:25 -0700 (PDT) Received: from emailgw03.pnl.gov (emailgw03.pnl.gov [192.101.109.31]) by ietfa.amsl.com (Postfix) with ESMTP id A9B5121F8C7F for ; Tue, 30 Aug 2011 10:35:25 -0700 (PDT) Received: from emailhub02.pnl.gov ([130.20.251.62]) by emailgw03.pnl.gov with ESMTP/TLS/AES128-SHA; 30 Aug 2011 10:36:52 -0700 Received: from Email05.pnl.gov ([130.20.251.70]) by emailhub02.pnl.gov ([130.20.251.62]) with mapi; Tue, 30 Aug 2011 10:36:36 -0700 From: "Akyol, Bora A" To: Nicolas DEJEAN Date: Tue, 30 Aug 2011 10:36:49 -0700 Thread-Topic: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Thread-Index: AcxnO2bSs03nlTlSR3eihbsWOZY+ig== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 17:35:26 -0000 Hi Nicolas Thank you for your response. Please see my comments within --=20 Bora Akyol, Pacific Northwest National Laboratory +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov On 8/30/11 1:25 AM, "Nicolas DEJEAN" wrote: >Hello Bora, > >2011/7/29 Akyol, Bora A : >> I think the statement about AMI networks being used as an almost general >> purpose backhaul network for all other devices >> is overreaching. I know there are some utilities that are looking into >> this, but a lot more that have shied away from >> this vision. Secondly, there are a lot more AMI deployments not using >> wireless mesh networks, e.g. using cellular modem, >> powerline carrier, etc. > >I agree that all utilities are not looking into it. >However this is one possible case that should be considered, isn't it? >Could you please precise what you are expecting to be in the draft? I think the draft should be focusing on the applicability of ROLL from a technical front without siting this one case as the only justification. > >> >> Is it possible to tone this "marketing" text Section 1.1. down and also >> potentially >> remove Gas & Water meters from the scope of this document. >> > >On our point of view, Gas and Water metering are part of AMI. This is not the widely-held view at least within the US electric utility community. The gas and water meters have capabilities which are quite different from electric power meters. For example, while the electric meter has easy access to mains power, the gas/water meters don't. In most instances, the gas/water service may be provided by a completely different entity than the electric power utility. At least within the US NIST SGIP CSWG, the gas/water meters and AMI backhaul were considered out of scope. Would the document lose technical integrity if the gas/water meter were either removed or included as an optional. Regards >Could you please elaborate? >According to you, why should Gas and Water be removed from the draft? > >Thank you in advance, > >Nicolas. > >> Regards >> >> -- >> Bora Akyol, Pacific Northwest National Laboratory >> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> From mcr@sandelman.ca Tue Aug 30 10:43:30 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F73C21F8D69 for ; Tue, 30 Aug 2011 10:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.646 X-Spam-Level: X-Spam-Status: No, score=0.646 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79ixXvRuwvM9 for ; Tue, 30 Aug 2011 10:43:29 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id B1E3621F8D55 for ; Tue, 30 Aug 2011 10:43:29 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [199.119.232.11]) by relay.sandelman.ca (Postfix) with ESMTPS id F4162A0067; Tue, 30 Aug 2011 13:44:15 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id C36E798C68; Tue, 30 Aug 2011 13:45:23 -0400 (EDT) From: Michael Richardson To: JP Vasseur In-Reply-To: References: X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Tue, 30 Aug 2011 13:45:23 -0400 Message-ID: <7118.1314726323@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 17:43:30 -0000 I am in favour of persuing work to accomodate compression, but the work in goyal-roll-rpl-compression is not compression, it's a reduced scope, non-extensible version of RPL. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From prvs=2160146b2=mukul@uwm.edu Tue Aug 30 11:23:32 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F97F21F8D62 for ; Tue, 30 Aug 2011 11:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.763 X-Spam-Level: X-Spam-Status: No, score=-2.763 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIb+QhXHeD+p for ; Tue, 30 Aug 2011 11:23:31 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9851E21F8D60 for ; Tue, 30 Aug 2011 11:23:31 -0700 (PDT) Received: from localhost (HELO mta04.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 30 Aug 2011 13:24:09 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 9D7212B3ED2; Tue, 30 Aug 2011 13:24:29 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8tLfw76Rjfk; Tue, 30 Aug 2011 13:24:28 -0500 (CDT) Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id DD9F12B3EC2; Tue, 30 Aug 2011 13:24:28 -0500 (CDT) Date: Tue, 30 Aug 2011 13:24:58 -0500 (CDT) From: Mukul Goyal To: Emmanuel Baccelli Message-ID: <160905940.138845.1314728698583.JavaMail.root@mail05.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 18:23:32 -0000 I totally agree with Emmanuel. As I mentioned before, the compression mecha= nism is required in some application scenarios (e.g. in P2P routing where D= IOs need to carry the Route Discovery Option additionally). The compression= mechanism may not be required for many L2 technologies (with larger MAC pa= yloads) or for many application scenarios (where DIOs do not carry many opt= ions). Thanks Mukul ----- Original Message ----- From: "Emmanuel Baccelli" To: "roll WG" Sent: Tuesday, August 30, 2011 4:33:21 AM Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new R= OLL WG document Hi Thomas,=20 I don't know about all the L2 technologies and all the applications that ar= e intended to be used in conjunction with RPL. It's not my concern, but I s= uppose some of them may not need the compression scheme proposed in draft-g= oyal-roll-rpl-compression? It's not for me to say.=C2=A0=20 All I know is that for the scenarios we target using P2P, we need a compres= sion scheme. draft-goyal-roll-rpl-compression thus proposes a compression s= cheme tailored for this purpose.=C2=A0=20 If others also need a compression scheme for other purposes, let it be know= n, and let's try to work on merging our requirements in the working group d= ocument to be.=20 cheers,=20 Emmanuel=20 On Tue, Aug 30, 2011 at 11:10 AM, Thomas Heide Clausen < ietf@thomasclausen= .org > wrote:=20 All,=20 Let me reiterate what I said at the Quebec meeting at the microphone: I fin= d it incomprehensible if - before the ink is dry on the RPL RFC and before = an RFC number has even been assigned to the specification - the working gro= up finds it necessary to invent a "compression mechanism" for RPL.=20 After all, RPL was supposed to have been designed for networks with (among = other characteristics) a small MTU.=20 If this document is necessary, then the logical conclusion would have to be= that the initial design of (at least) the packet format of RPL was insuffi= cient, and that therefore this document should either or both of "Updates/O= bsoletes" RPL?=20 If this document is not intended to either or both of "Updates/Obsoletes" R= PL, then I do not see any justification for the document being adopted.=20 Respectfully Yours,=20 Thomas=20 On Aug 30, 2011, at 10:18 , JP Vasseur wrote:=20 > Dear WG,=20 >=20 > draft-goyal-roll-rpl-compression was discussed during the last ROLL WG me= eting in Quebec, but=20 > as usual we confirm on the mailing list. Are in favor of adopting this do= cument as a WG document ?=20 > Please reply on the mailing list.=20 >=20 > Thanks.=20 >=20 > JP.=20 > _______________________________________________=20 > Roll mailing list=20 > Roll@ietf.org=20 > https://www.ietf.org/mailman/listinfo/roll=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=2160146b2=mukul@uwm.edu Tue Aug 30 11:45:55 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85AE21F8DEE for ; Tue, 30 Aug 2011 11:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.972 X-Spam-Level: X-Spam-Status: No, score=-2.972 tagged_above=-999 required=5 tests=[AWL=0.627, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzeGBGY1I5kr for ; Tue, 30 Aug 2011 11:45:55 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 07B1821F8DEB for ; Tue, 30 Aug 2011 11:45:54 -0700 (PDT) Received: from localhost (HELO mta02.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 30 Aug 2011 13:46:32 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 06D2812E3B2; Tue, 30 Aug 2011 13:47:23 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcJJluskTrcc; Tue, 30 Aug 2011 13:47:22 -0500 (CDT) Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id B259B12E3B1; Tue, 30 Aug 2011 13:47:22 -0500 (CDT) Date: Tue, 30 Aug 2011 13:47:22 -0500 (CDT) From: Mukul Goyal To: Michael Richardson Message-ID: <1506713722.139258.1314730042632.JavaMail.root@mail05.pantherlink.uwm.edu> In-Reply-To: <7118.1314726323@marajade.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 18:45:55 -0000 Michael I was wondering if you have the compression scheme described in draft-bormann-6lowpan-ghc in mind. I guess it will be useful to compare the compression achieved using the two schemes for the two examples described in draft-goyal-roll-rpl-compression. I think that compression achieved with draft-bormann scheme would vary with the actual byte stream contained in the packet. There is ofcourse no such dependency in case of our scheme. Thanks Mukul ----- Original Message ----- From: "Michael Richardson" To: "JP Vasseur" Cc: "roll WG" Sent: Tuesday, August 30, 2011 12:45:23 PM Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document I am in favour of persuing work to accomodate compression, but the work in goyal-roll-rpl-compression is not compression, it's a reduced scope, non-extensible version of RPL. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From Jorjeta.Jetcheva@itron.com Tue Aug 30 12:30:51 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34AE21F8D6D for ; Tue, 30 Aug 2011 12:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2HtEgC5U7b4 for ; Tue, 30 Aug 2011 12:30:50 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.115]) by ietfa.amsl.com (Postfix) with ESMTP id D665821F8CA0 for ; Tue, 30 Aug 2011 12:30:50 -0700 (PDT) Received: from ITR-EXMBXVS-2.itron.com ([192.168.9.111]) by spo-exchcn-1.itron.com ([192.168.9.115]) with mapi; Tue, 30 Aug 2011 12:32:16 -0700 From: "Jetcheva, Jorjeta" To: "Akyol, Bora A" , Nicolas DEJEAN Date: Tue, 30 Aug 2011 12:32:12 -0700 Thread-Topic: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Thread-Index: AcxnO2bSs03nlTlSR3eihbsWOZY+igADcdcA Message-ID: <0368F388C03BB34BBBFA73209849D47A4CBF4F90@ITR-EXMBXVS-2.itron.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 19:30:51 -0000 Hello Bora, > At least within the US NIST SGIP CSWG, the gas/water meters and AMI > backhaul were considered out of scope. Actually AMI backhaul for gas and water meters is very much in scope as per= the NIST Wireless Guidelines (PAP2) work and the related SG-Communications= /SG-Net work. CSWG coordinates with the PAPs so they should be aware of th= is. =20 Jorjeta Jorjeta Jetcheva, Ph.D. Principal Engineer, Architecture & Standards CTO Office Itron, Inc. -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Aky= ol, Bora A Sent: Tuesday, August 30, 2011 10:37 AM To: Nicolas DEJEAN Cc: roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Hi Nicolas Thank you for your response. Please see my comments within --=20 Bora Akyol, Pacific Northwest National Laboratory +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov On 8/30/11 1:25 AM, "Nicolas DEJEAN" wrote: >Hello Bora, > >2011/7/29 Akyol, Bora A : >> I think the statement about AMI networks being used as an almost general >> purpose backhaul network for all other devices >> is overreaching. I know there are some utilities that are looking into >> this, but a lot more that have shied away from >> this vision. Secondly, there are a lot more AMI deployments not using >> wireless mesh networks, e.g. using cellular modem, >> powerline carrier, etc. > >I agree that all utilities are not looking into it. >However this is one possible case that should be considered, isn't it? >Could you please precise what you are expecting to be in the draft? I think the draft should be focusing on the applicability of ROLL from a technical front without siting this one case as the only justification. > >> >> Is it possible to tone this "marketing" text Section 1.1. down and also >> potentially >> remove Gas & Water meters from the scope of this document. >> > >On our point of view, Gas and Water metering are part of AMI. This is not the widely-held view at least within the US electric utility community. The gas and water meters have capabilities which are quite different from electric power meters. For example, while the electric meter has easy access to mains power, the gas/water meters don't. In most instances, the gas/water service may be provided by a completely different entity than the electric power utility. At least within the US NIST SGIP CSWG, the gas/water meters and AMI backhaul were considered out of scope. Would the document lose technical integrity if the gas/water meter were either removed or included as an optional. Regards >Could you please elaborate? >According to you, why should Gas and Water be removed from the draft? > >Thank you in advance, > >Nicolas. > >> Regards >> >> -- >> Bora Akyol, Pacific Northwest National Laboratory >> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >> >> _______________________________________________ >> 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 mcr@sandelman.ca Tue Aug 30 12:51:40 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E3521F8ED9 for ; Tue, 30 Aug 2011 12:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.654 X-Spam-Level: X-Spam-Status: No, score=-0.654 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56oS2SwAWEm8 for ; Tue, 30 Aug 2011 12:51:39 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id C4F2321F8ED8 for ; Tue, 30 Aug 2011 12:51:39 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [199.119.232.11]) by relay.sandelman.ca (Postfix) with ESMTPS id C5041A0067; Tue, 30 Aug 2011 15:52:24 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 4C9D298C71; Tue, 30 Aug 2011 15:53:32 -0400 (EDT) From: Michael Richardson To: Mukul Goyal In-Reply-To: <1506713722.139258.1314730042632.JavaMail.root@mail05.pantherlink.uwm.edu> References: <1506713722.139258.1314730042632.JavaMail.root@mail05.pantherlink.uwm.edu> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Tue, 30 Aug 2011 15:53:32 -0400 Message-ID: <28229.1314734012@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 19:51:40 -0000 >>>>> "Mukul" == Mukul Goyal writes: Mukul> I was wondering if you have the compression scheme described Mukul> in draft-bormann-6lowpan-ghc in mind. I guess it will be Mukul> useful to compare the compression achieved using the two Mukul> schemes for the two examples described in Mukul> draft-goyal-roll-rpl-compression. I think that compression Mukul> achieved with draft-bormann scheme would vary with the actual Mukul> byte stream contained in the packet. There is ofcourse no Mukul> such dependency in case of our scheme. yes, but the goyal-roll-rpl-compression (GRRC from now on, okay?) scheme will result in devices that support the compressed format only, essentially creating an entirely new protocol. 6lowpan-ghc applies things as a layered approach, which means that after decompression, you still need a full RPL packet parser, which means that the RPL protocol can in fact evolve. goyal-roll-rpl-compression (GRRC) scheme will have to be revised each time there is an addition to the protocol, and will cause a flag day, as no node can use the new options until every node is upgraded, even if the nodes do not need to make use of the new options. In essence, the goyal-roll-rpl-compression is a fixed proprietary system. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From ulrich@herberg.name Tue Aug 30 12:57:18 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D4521F8E2B for ; Tue, 30 Aug 2011 12:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nSdVgAhzvH6 for ; Tue, 30 Aug 2011 12:57:17 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6A57021F8E08 for ; Tue, 30 Aug 2011 12:56:53 -0700 (PDT) Received: by vws12 with SMTP id 12so3860945vws.31 for ; Tue, 30 Aug 2011 12:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SICofiBSIAHtVQ8BdFQDkA6YH/cQ//4xe8NncK4520s=; b=gD792+5AzljhPKqnTsIhyui6zZDeviIVcpI63ovP38sy1ZWTtxSsYc18dGSYvumLLa dLdqbpDppmqZPlSmFKb83oTb4lCS92fd6uA/f8SeQncplkQZtGTxnoImQkd5lcaKKCrk rVvuRjfM5DbqxWTE7wfnU79fnMveZmBf0v9v0= MIME-Version: 1.0 Received: by 10.220.148.208 with SMTP id q16mr148647vcv.141.1314734301299; Tue, 30 Aug 2011 12:58:21 -0700 (PDT) Received: by 10.220.51.130 with HTTP; Tue, 30 Aug 2011 12:58:21 -0700 (PDT) In-Reply-To: <28229.1314734012@marajade.sandelman.ca> References: <1506713722.139258.1314730042632.JavaMail.root@mail05.pantherlink.uwm.edu> <28229.1314734012@marajade.sandelman.ca> Date: Tue, 30 Aug 2011 12:58:21 -0700 Message-ID: From: Ulrich Herberg To: Michael Richardson Content-Type: multipart/alternative; boundary=f46d0438950f00c59504abbe6f19 Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 19:57:18 -0000 --f46d0438950f00c59504abbe6f19 Content-Type: text/plain; charset=ISO-8859-1 I agree with Michael's concern that using GRRC could lead to non-interoperable implementations, with some nodes "speaking" normal RPL, some using GRRC. That might require some additional negotiation between nodes, or worse, could lead to non-interoperable parts of the network. That worries me. Ulrich On Tue, Aug 30, 2011 at 12:53 PM, Michael Richardson wrote: > > >>>>> "Mukul" == Mukul Goyal writes: > Mukul> I was wondering if you have the compression scheme described > Mukul> in draft-bormann-6lowpan-ghc in mind. I guess it will be > Mukul> useful to compare the compression achieved using the two > Mukul> schemes for the two examples described in > Mukul> draft-goyal-roll-rpl-compression. I think that compression > Mukul> achieved with draft-bormann scheme would vary with the actual > Mukul> byte stream contained in the packet. There is ofcourse no > Mukul> such dependency in case of our scheme. > > yes, but the goyal-roll-rpl-compression (GRRC from now on, okay?) scheme > will result in devices that support the compressed format only, > essentially creating an entirely new protocol. > > 6lowpan-ghc applies things as a layered approach, which means that after > decompression, you still need a full RPL packet parser, which means that > the RPL protocol can in fact evolve. > > goyal-roll-rpl-compression (GRRC) scheme will have to be revised each time > there is an addition to the protocol, and will cause a flag day, as no > node can use the new options until every node is upgraded, even if the > nodes do not need to make use of the new options. > > In essence, the goyal-roll-rpl-compression is a fixed proprietary > system. > > -- > ] He who is tired of Weird Al is tired of life! | > firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device > driver[ > Kyoto Plus: watch the video > then sign the petition. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --f46d0438950f00c59504abbe6f19 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree with Michael's concern that using GRRC could lead to non-intero= perable implementations, with some nodes "speaking" normal RPL, s= ome using GRRC. That might require some additional negotiation between node= s, or worse, could lead to non-interoperable parts of the network. That wor= ries me.

Ulrich

On Tue, Aug 30, 2011 at 12:53 = PM, Michael Richardson <mcr@sandelman.ca> wrote:

>>>>> "Mukul" =3D=3D Mukul Goyal <mukul@uwm.edu> writes:
=A0 =A0Mukul> I was wondering if you have the compression scheme descri= bed
=A0 =A0Mukul> in draft-bormann-6lowpan-ghc in mind. I guess it will be<= br> =A0 =A0Mukul> useful to compare the compression achieved using the two<= br> =A0 =A0Mukul> schemes for the two examples described in
=A0 =A0Mukul> draft-goyal-roll-rpl-compression. I think that compressio= n
=A0 =A0Mukul> achieved with draft-bormann scheme would vary with the ac= tual
=A0 =A0Mukul> byte stream contained in the packet. There is ofcourse no=
=A0 =A0Mukul> such dependency in case of our scheme.

yes, but the goyal-roll-rpl-compression (GRRC from now on, okay?) scheme will result in devices that support the compressed format only,
essentially creating an entirely new protocol.

6lowpan-ghc applies things as a layered approach, which means that after decompression, you still need a full RPL packet parser, which means that the RPL protocol can in fact evolve.

goyal-roll-rpl-compression (GRRC) scheme will have to be revised each time<= br> there is an addition to the protocol, and will cause a flag day, as no
node can use the new options until every node is upgraded, even if the
nodes do not need to make use of the new options.

In essence, the goyal-roll-rpl-compression is a fixed proprietary
system.

--
] =A0 =A0 =A0 He who is tired of Weird Al is tired of life! =A0 =A0 =A0 =A0= =A0 | =A0firewalls =A0[
] =A0 Michael Richardson, Sandelman Software Works, Ottawa, ON =A0 =A0|net = architect[
] mcr@sandelman.ottawa.on.ca<= /a> http:/= /www.sandelman.ottawa.on.ca/ |device driver[
=A0 Kyoto Plus: watch the video <http://www.youtube.com/watch?v=3Dkzx1y= cLXQSE>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 then sign the petition.
_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

--f46d0438950f00c59504abbe6f19-- From prvs=2160146b2=mukul@uwm.edu Tue Aug 30 13:03:47 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E0921F8EFB for ; Tue, 30 Aug 2011 13:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmyIfNqnKiDW for ; Tue, 30 Aug 2011 13:03:46 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDDE21F8EF1 for ; Tue, 30 Aug 2011 13:03:46 -0700 (PDT) Received: from localhost (HELO mta01.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 30 Aug 2011 15:04:13 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 216BAE6A74; Tue, 30 Aug 2011 15:05:03 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRhEhRvSw7Z7; Tue, 30 Aug 2011 15:05:02 -0500 (CDT) Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id E61C1E6A79; Tue, 30 Aug 2011 15:05:02 -0500 (CDT) Date: Tue, 30 Aug 2011 15:05:02 -0500 (CDT) From: Mukul Goyal To: Michael Richardson Message-ID: <521765682.140629.1314734702895.JavaMail.root@mail05.pantherlink.uwm.edu> In-Reply-To: <28229.1314734012@marajade.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 20:03:47 -0000 >yes, but the goyal-roll-rpl-compression (GRRC from now on, okay?) scheme >will result in devices that support the compressed format only, >essentially creating an entirely new protocol. This is not true. Compressed messages will have new code values. I quote the relevant text from the draft: "Code: The Code value of the compressed version of an RPL ICMPv6 message is obtained by setting the 7th bit in the Code value associated with the corresponding uncompressed message. For example, the Code associated with a compressed DODAG Information Object is 0x40." >6lowpan-ghc applies things as a layered approach, which means that after >decompression, you still need a full RPL packet parser, which means that >the RPL protocol can in fact evolve. I am not doubting that. I guess the important question to answer is whether the ghc scheme would provide enough compression. Or the devices with ghc would have to implement additional compression mechanisms (e.g. draft-goyal....) as well? >goyal-roll-rpl-compression (GRRC) scheme will have to be revised each time >there is an addition to the protocol, Again not true. Any new additions to the protocol DO NOT require their compressed formats to be specified as well. One could ofcourse define compressed formats (or define only the compressed formats) if they are deemed useful. But it is not mandatory to do so. > and will cause a flag day, as no >node can use the new options until every node is upgraded, even if the >nodes do not need to make use of the new options. Simply not true. >In essence, the goyal-roll-rpl-compression is a fixed proprietary system. I am sorry but this is totally wrong characterization. Thanks Mukul From prvs=2160146b2=mukul@uwm.edu Tue Aug 30 13:05:29 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE5A21F8F38 for ; Tue, 30 Aug 2011 13:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.181 X-Spam-Level: X-Spam-Status: No, score=-3.181 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrkltmgLdJ0b for ; Tue, 30 Aug 2011 13:05:28 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4991E21F8EFB for ; Tue, 30 Aug 2011 13:05:28 -0700 (PDT) Received: from localhost (HELO mta04.pantherlink.uwm.edu) ([127.0.0.1]) by ip1mta.uwm.edu with ESMTP; 30 Aug 2011 14:48:57 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 7EBD42B3EC3; Tue, 30 Aug 2011 15:06:13 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AtNAlemL6d5; Tue, 30 Aug 2011 15:06:13 -0500 (CDT) Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 3A28A2B3EC2; Tue, 30 Aug 2011 15:06:13 -0500 (CDT) Date: Tue, 30 Aug 2011 15:06:43 -0500 (CDT) From: Mukul Goyal To: Ulrich Herberg Message-ID: <1593431155.140676.1314734802999.JavaMail.root@mail05.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 20:05:29 -0000 By the same logic, you would argue that P2P-RPL would lead to non-interoper= able implementations since some devices would speak P2P-RPL and others wont= . Thanks Mukul ----- Original Message ----- From: "Ulrich Herberg" To: "Michael Richardson" Cc: "Mukul Goyal" , "roll WG" Sent: Tuesday, August 30, 2011 2:58:21 PM Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new R= OLL WG document I agree with Michael's concern that using GRRC could lead to non-interopera= ble implementations, with some nodes "speaking" normal RPL, some using GRRC= . That might require some additional negotiation between nodes, or worse, c= ould lead to non-interoperable parts of the network. That worries me.=20 Ulrich=20 On Tue, Aug 30, 2011 at 12:53 PM, Michael Richardson < mcr@sandelman.ca > w= rote:=20 >>>>> "Mukul" =3D=3D Mukul Goyal < mukul@uwm.edu > writes:=20 =C2=A0 =C2=A0Mukul> I was wondering if you have the compression scheme desc= ribed=20 =C2=A0 =C2=A0Mukul> in draft-bormann-6lowpan-ghc in mind. I guess it will b= e=20 =C2=A0 =C2=A0Mukul> useful to compare the compression achieved using the tw= o=20 =C2=A0 =C2=A0Mukul> schemes for the two examples described in=20 =C2=A0 =C2=A0Mukul> draft-goyal-roll-rpl-compression. I think that compress= ion=20 =C2=A0 =C2=A0Mukul> achieved with draft-bormann scheme would vary with the = actual=20 =C2=A0 =C2=A0Mukul> byte stream contained in the packet. There is ofcourse = no=20 =C2=A0 =C2=A0Mukul> such dependency in case of our scheme.=20 yes, but the goyal-roll-rpl-compression (GRRC from now on, okay?) scheme=20 will result in devices that support the compressed format only,=20 essentially creating an entirely new protocol.=20 6lowpan-ghc applies things as a layered approach, which means that after=20 decompression, you still need a full RPL packet parser, which means that=20 the RPL protocol can in fact evolve.=20 goyal-roll-rpl-compression (GRRC) scheme will have to be revised each time= =20 there is an addition to the protocol, and will cause a flag day, as no=20 node can use the new options until every node is upgraded, even if the=20 nodes do not need to make use of the new options.=20 In essence, the goyal-roll-rpl-compression is a fixed proprietary=20 system.=20 --=20 ] =C2=A0 =C2=A0 =C2=A0 He who is tired of Weird Al is tired of life! =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0firewalls =C2=A0[=20 ] =C2=A0 Michael Richardson, Sandelman Software Works, Ottawa, ON =C2=A0 = =C2=A0|net architect[=20 ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[=20 =C2=A0 Kyoto Plus: watch the video < http://www.youtube.com/watch?v=3Dkzx1y= cLXQSE >=20 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 then sign the petition.=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 From prvs=2160146b2=mukul@uwm.edu Tue Aug 30 13:09:03 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A4721F8EDF for ; Tue, 30 Aug 2011 13:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.241 X-Spam-Level: X-Spam-Status: No, score=-3.241 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJjKVUwBwzZg for ; Tue, 30 Aug 2011 13:09:02 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 628BE21F8ED9 for ; Tue, 30 Aug 2011 13:09:02 -0700 (PDT) Received: from localhost (HELO mta02.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 30 Aug 2011 15:09:05 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 3973912E3B2; Tue, 30 Aug 2011 15:09:56 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhbysSKXOV1N; Tue, 30 Aug 2011 15:09:55 -0500 (CDT) Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id E2E3E12E3C2; Tue, 30 Aug 2011 15:09:55 -0500 (CDT) Date: Tue, 30 Aug 2011 15:09:55 -0500 (CDT) From: Mukul Goyal To: Ulrich Herberg Message-ID: <877272675.140749.1314734995826.JavaMail.root@mail05.pantherlink.uwm.edu> In-Reply-To: <1593431155.140676.1314734802999.JavaMail.root@mail05.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 20:09:03 -0000 Please realize that the compressed objects have different code values than = regular objects. Hence there is no danger of lack of interoperability. Thanks Mukul ----- Original Message ----- From: "Mukul Goyal" To: "Ulrich Herberg" Cc: "roll WG" Sent: Tuesday, August 30, 2011 3:06:43 PM Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new R= OLL WG document By the same logic, you would argue that P2P-RPL would lead to non-interoper= able implementations since some devices would speak P2P-RPL and others wont= . Thanks Mukul ----- Original Message ----- From: "Ulrich Herberg" To: "Michael Richardson" Cc: "Mukul Goyal" , "roll WG" Sent: Tuesday, August 30, 2011 2:58:21 PM Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new R= OLL WG document I agree with Michael's concern that using GRRC could lead to non-interopera= ble implementations, with some nodes "speaking" normal RPL, some using GRRC= . That might require some additional negotiation between nodes, or worse, c= ould lead to non-interoperable parts of the network. That worries me.=20 Ulrich=20 On Tue, Aug 30, 2011 at 12:53 PM, Michael Richardson < mcr@sandelman.ca > w= rote:=20 >>>>> "Mukul" =3D=3D Mukul Goyal < mukul@uwm.edu > writes:=20 =C2=A0 =C2=A0Mukul> I was wondering if you have the compression scheme desc= ribed=20 =C2=A0 =C2=A0Mukul> in draft-bormann-6lowpan-ghc in mind. I guess it will b= e=20 =C2=A0 =C2=A0Mukul> useful to compare the compression achieved using the tw= o=20 =C2=A0 =C2=A0Mukul> schemes for the two examples described in=20 =C2=A0 =C2=A0Mukul> draft-goyal-roll-rpl-compression. I think that compress= ion=20 =C2=A0 =C2=A0Mukul> achieved with draft-bormann scheme would vary with the = actual=20 =C2=A0 =C2=A0Mukul> byte stream contained in the packet. There is ofcourse = no=20 =C2=A0 =C2=A0Mukul> such dependency in case of our scheme.=20 yes, but the goyal-roll-rpl-compression (GRRC from now on, okay?) scheme=20 will result in devices that support the compressed format only,=20 essentially creating an entirely new protocol.=20 6lowpan-ghc applies things as a layered approach, which means that after=20 decompression, you still need a full RPL packet parser, which means that=20 the RPL protocol can in fact evolve.=20 goyal-roll-rpl-compression (GRRC) scheme will have to be revised each time= =20 there is an addition to the protocol, and will cause a flag day, as no=20 node can use the new options until every node is upgraded, even if the=20 nodes do not need to make use of the new options.=20 In essence, the goyal-roll-rpl-compression is a fixed proprietary=20 system.=20 --=20 ] =C2=A0 =C2=A0 =C2=A0 He who is tired of Weird Al is tired of life! =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0firewalls =C2=A0[=20 ] =C2=A0 Michael Richardson, Sandelman Software Works, Ottawa, ON =C2=A0 = =C2=A0|net architect[=20 ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[=20 =C2=A0 Kyoto Plus: watch the video < http://www.youtube.com/watch?v=3Dkzx1y= cLXQSE >=20 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 then sign the petition.=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From ulrich@herberg.name Tue Aug 30 13:10:46 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2640421F8EF9 for ; Tue, 30 Aug 2011 13:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.902 X-Spam-Level: X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKOEp+AmI4Ut for ; Tue, 30 Aug 2011 13:10:45 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DF3A621F8EEB for ; Tue, 30 Aug 2011 13:10:44 -0700 (PDT) Received: by vws12 with SMTP id 12so3684vws.31 for ; Tue, 30 Aug 2011 13:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B0ljEWoNflikjWcfZbVfKpFcayxUD2vvrShNibnjttQ=; b=tPG7YN+B3X3BPl7jwt4PSafy73qrmI8z2zjPnNEvOBCMU24wDJublU2BHvsh64DVcm WsoVC/Ie8XVIVSMmsYFvGB8leaCEonqtRGbVa1qOWx4XG/+/L4IFuQ9jiUhQgrK6tAOd FFt1oVHgAZz+raUBUq59KDwLz/ftebNTiBO60= MIME-Version: 1.0 Received: by 10.52.93.11 with SMTP id cq11mr1828307vdb.80.1314735132758; Tue, 30 Aug 2011 13:12:12 -0700 (PDT) Received: by 10.220.51.130 with HTTP; Tue, 30 Aug 2011 13:12:12 -0700 (PDT) In-Reply-To: <1593431155.140676.1314734802999.JavaMail.root@mail05.pantherlink.uwm.edu> References: <1593431155.140676.1314734802999.JavaMail.root@mail05.pantherlink.uwm.edu> Date: Tue, 30 Aug 2011 13:12:12 -0700 Message-ID: From: Ulrich Herberg To: Mukul Goyal Content-Type: multipart/alternative; boundary=20cf307cffca8fd2dd04abbea035 Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 20:10:46 -0000 --20cf307cffca8fd2dd04abbea035 Content-Type: text/plain; charset=ISO-8859-1 Yes, I indeed do argue the same way. Adding ever more companion documents to RPL makes it more and more difficult to guarantee interoperable implementations. But that's another topic. Ulrich On Tue, Aug 30, 2011 at 1:06 PM, Mukul Goyal wrote: > By the same logic, you would argue that P2P-RPL would lead to > non-interoperable implementations since some devices would speak P2P-RPL and > others wont. > > Thanks > Mukul > > ----- Original Message ----- > From: "Ulrich Herberg" > To: "Michael Richardson" > Cc: "Mukul Goyal" , "roll WG" > Sent: Tuesday, August 30, 2011 2:58:21 PM > Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new > ROLL WG document > > I agree with Michael's concern that using GRRC could lead to > non-interoperable implementations, with some nodes "speaking" normal RPL, > some using GRRC. That might require some additional negotiation between > nodes, or worse, could lead to non-interoperable parts of the network. That > worries me. > > Ulrich > > > On Tue, Aug 30, 2011 at 12:53 PM, Michael Richardson < mcr@sandelman.ca > > wrote: > > > > >>>>> "Mukul" == Mukul Goyal < mukul@uwm.edu > writes: > Mukul> I was wondering if you have the compression scheme described > Mukul> in draft-bormann-6lowpan-ghc in mind. I guess it will be > Mukul> useful to compare the compression achieved using the two > Mukul> schemes for the two examples described in > Mukul> draft-goyal-roll-rpl-compression. I think that compression > Mukul> achieved with draft-bormann scheme would vary with the actual > Mukul> byte stream contained in the packet. There is ofcourse no > Mukul> such dependency in case of our scheme. > > yes, but the goyal-roll-rpl-compression (GRRC from now on, okay?) scheme > will result in devices that support the compressed format only, > essentially creating an entirely new protocol. > > 6lowpan-ghc applies things as a layered approach, which means that after > decompression, you still need a full RPL packet parser, which means that > the RPL protocol can in fact evolve. > > goyal-roll-rpl-compression (GRRC) scheme will have to be revised each time > there is an addition to the protocol, and will cause a flag day, as no > node can use the new options until every node is upgraded, even if the > nodes do not need to make use of the new options. > > In essence, the goyal-roll-rpl-compression is a fixed proprietary > system. > > > > > -- > ] He who is tired of Weird Al is tired of life! | > firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device > driver[ > Kyoto Plus: watch the video < http://www.youtube.com/watch?v=kzx1ycLXQSE> > then sign the petition. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --20cf307cffca8fd2dd04abbea035 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, I indeed do argue the same way. Adding ever more companion documents t= o RPL makes it more and more difficult to guarantee interoperable implement= ations. But that's another topic.

Ulrich

On Tue, Aug 30, 2011 at 1:06 PM, Mukul Goyal <mukul@uwm.edu> wrote:
By the same logic, you would argue that P2P-RPL would lead to non-interoper= able implementations since some devices would speak P2P-RPL and others wont= .

Thanks
Mukul

----- Original Message -----
From: "Ulrich Herberg" <ulrich@herberg.name>
To: "Michael Richardson" <= mcr@sandelman.ca>
Cc: "Mukul Goyal" <mukul@uwm.= edu>, "roll WG" <roll@= ietf.org>
Sent: Tuesday, August 30, 2011 2:58:21 PM
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new R= OLL WG document

I agree with Michael's concern = that using GRRC could lead to non-interoperable implementations, with some = nodes "speaking" normal RPL, some using GRRC. That might require = some additional negotiation between nodes, or worse, could lead to non-inte= roperable parts of the network. That worries me.

Ulrich


On Tue, Aug 30, 2011 at 12:53 PM, Michael Richardson < mcr@sandelman.ca > wrote:



>>>>> "Mukul" =3D=3D Mukul Goyal < mukul@uwm.edu > writes:
=A0 =A0Mukul> I was wondering if you have the compression scheme describ= ed
=A0 =A0Mukul> in draft-bormann-6lowpan-ghc in mind. I guess it will be =A0 =A0Mukul> useful to compare the compression achieved using the two =A0 =A0Mukul> schemes for the two examples described in
=A0 =A0Mukul> draft-goyal-roll-rpl-compression. I think that compression=
=A0 =A0Mukul> achieved with draft-bormann scheme would vary with the act= ual
=A0 =A0Mukul> byte stream contained in the packet. There is ofcourse no<= br> =A0 =A0Mukul> such dependency in case of our scheme.

yes, but the goyal-roll-rpl-compression (GRRC from now on, okay?) scheme will result in devices that support the compressed format only,
essentially creating an entirely new protocol.

6lowpan-ghc applies things as a layered approach, which means that after decompression, you still need a full RPL packet parser, which means that the RPL protocol can in fact evolve.

goyal-roll-rpl-compression (GRRC) scheme will have to be revised each time<= br> there is an addition to the protocol, and will cause a flag day, as no
node can use the new options until every node is upgraded, even if the
nodes do not need to make use of the new options.

In essence, the goyal-roll-rpl-compression is a fixed proprietary
system.




--
] =A0 =A0 =A0 He who is tired of Weird Al is tired of life! =A0 =A0 =A0 =A0= =A0 | =A0firewalls =A0[
] =A0 Michael Richardson, Sandelman Software Works, Ottawa, ON =A0 =A0|net = architect[
] mcr@sandelman.ottawa.on.ca<= /a> http:/= /www.sandelman.ottawa.on.ca/ |device driver[
=A0 Kyoto Plus: watch the video < http://www.youtube.com/watch?v=3Dkzx1y= cLXQSE >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 then sign the petition.
_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll


--20cf307cffca8fd2dd04abbea035-- From prvs=2160146b2=mukul@uwm.edu Tue Aug 30 13:17:41 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6EDC21F8F51 for ; Tue, 30 Aug 2011 13:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.286 X-Spam-Level: X-Spam-Status: No, score=-3.286 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCj1Q2hiVubU for ; Tue, 30 Aug 2011 13:17:41 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0D83221F8F4F for ; Tue, 30 Aug 2011 13:17:40 -0700 (PDT) Received: from localhost (HELO mta01.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 30 Aug 2011 15:15:20 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id EEB29E6A78; Tue, 30 Aug 2011 15:16:10 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phhJFxU2kcFe; Tue, 30 Aug 2011 15:16:10 -0500 (CDT) Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id A560EE6A74; Tue, 30 Aug 2011 15:16:10 -0500 (CDT) Date: Tue, 30 Aug 2011 15:16:10 -0500 (CDT) From: Mukul Goyal To: Ulrich Herberg Message-ID: <44019259.140892.1314735370623.JavaMail.root@mail05.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 20:17:42 -0000 I am sorry but your argument is wrong. Mukul=20 ----- Original Message ----- From: "Ulrich Herberg" To: "Mukul Goyal" Cc: "roll WG" , "Michael Richardson" Sent: Tuesday, August 30, 2011 3:12:12 PM Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new R= OLL WG document Yes, I indeed do argue the same way. Adding ever more companion documents t= o RPL makes it more and more difficult to guarantee interoperable implement= ations. But that's another topic.=20 Ulrich=20 On Tue, Aug 30, 2011 at 1:06 PM, Mukul Goyal < mukul@uwm.edu > wrote:=20 By the same logic, you would argue that P2P-RPL would lead to non-interoper= able implementations since some devices would speak P2P-RPL and others wont= .=20 Thanks=20 Mukul=20 ----- Original Message -----=20 From: "Ulrich Herberg" < ulrich@herberg.name >=20 To: "Michael Richardson" < mcr@sandelman.ca >=20 Cc: "Mukul Goyal" < mukul@uwm.edu >, "roll WG" < roll@ietf.org >=20 Sent: Tuesday, August 30, 2011 2:58:21 PM=20 Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new R= OLL WG document=20 I agree with Michael's concern that using GRRC could lead to non-interopera= ble implementations, with some nodes "speaking" normal RPL, some using GRRC= . That might require some additional negotiation between nodes, or worse, c= ould lead to non-interoperable parts of the network. That worries me.=20 Ulrich=20 On Tue, Aug 30, 2011 at 12:53 PM, Michael Richardson < mcr@sandelman.ca > w= rote:=20 >>>>> "Mukul" =3D=3D Mukul Goyal < mukul@uwm.edu > writes:=20 =C2=A0 =C2=A0Mukul> I was wondering if you have the compression scheme desc= ribed=20 =C2=A0 =C2=A0Mukul> in draft-bormann-6lowpan-ghc in mind. I guess it will b= e=20 =C2=A0 =C2=A0Mukul> useful to compare the compression achieved using the tw= o=20 =C2=A0 =C2=A0Mukul> schemes for the two examples described in=20 =C2=A0 =C2=A0Mukul> draft-goyal-roll-rpl-compression. I think that compress= ion=20 =C2=A0 =C2=A0Mukul> achieved with draft-bormann scheme would vary with the = actual=20 =C2=A0 =C2=A0Mukul> byte stream contained in the packet. There is ofcourse = no=20 =C2=A0 =C2=A0Mukul> such dependency in case of our scheme.=20 yes, but the goyal-roll-rpl-compression (GRRC from now on, okay?) scheme=20 will result in devices that support the compressed format only,=20 essentially creating an entirely new protocol.=20 6lowpan-ghc applies things as a layered approach, which means that after=20 decompression, you still need a full RPL packet parser, which means that=20 the RPL protocol can in fact evolve.=20 goyal-roll-rpl-compression (GRRC) scheme will have to be revised each time= =20 there is an addition to the protocol, and will cause a flag day, as no=20 node can use the new options until every node is upgraded, even if the=20 nodes do not need to make use of the new options.=20 In essence, the goyal-roll-rpl-compression is a fixed proprietary=20 system.=20 --=20 ] =C2=A0 =C2=A0 =C2=A0 He who is tired of Weird Al is tired of life! =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0firewalls =C2=A0[=20 ] =C2=A0 Michael Richardson, Sandelman Software Works, Ottawa, ON =C2=A0 = =C2=A0|net architect[=20 ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[=20 =C2=A0 Kyoto Plus: watch the video < http://www.youtube.com/watch?v=3Dkzx1y= cLXQSE >=20 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 then sign the petition.=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 From mcr@sandelman.ca Tue Aug 30 13:17:59 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622AC21F8F64 for ; Tue, 30 Aug 2011 13:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.304 X-Spam-Level: X-Spam-Status: No, score=-1.304 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9XbBruRjAgY for ; Tue, 30 Aug 2011 13:17:58 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id D6DD021F8F4F for ; Tue, 30 Aug 2011 13:17:58 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [199.119.232.11]) by relay.sandelman.ca (Postfix) with ESMTPS id AB0F8A0067; Tue, 30 Aug 2011 16:18:47 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 4842D98C76; Tue, 30 Aug 2011 16:19:55 -0400 (EDT) From: Michael Richardson To: Mukul Goyal In-Reply-To: <521765682.140629.1314734702895.JavaMail.root@mail05.pantherlink.uwm.edu> References: <521765682.140629.1314734702895.JavaMail.root@mail05.pantherlink.uwm.edu> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 30 Aug 2011 16:19:55 -0400 Message-ID: <32348.1314735595@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 20:17:59 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Mukul" =3D=3D Mukul Goyal writes: >> 6lowpan-ghc applies things as a layered approach, which means that a= fter >> decompression, you still need a full RPL packet parser, which means = that >> the RPL protocol can in fact evolve. Mukul> I am not doubting that. I guess the important question to Mukul> answer is whether the ghc scheme would provide enough Mukul> compression. Or the devices with ghc would have to implement Mukul> additional compression mechanisms (e.g. draft-goyal....) as Mukul> well?=20 So, I have not yet done the research to determine how much compression we can get with ghc. >> goyal-roll-rpl-compression (GRRC) scheme will have to be revised eac= h time >> there is an addition to the protocol, Mukul> Again not true. Any new additions to the protocol DO NOT Mukul> require their compressed formats to be specified as well. One Mukul> could ofcourse define compressed formats (or define only the Mukul> compressed formats) if they are deemed useful. But it is not Mukul> mandatory to do so.=20 yes, but: 1) will nodes know how to process the new extensions? 2) will including the new extensions, uncompressed, blow the MTU, and so nobody will ever turn them on? >> and will cause a flag day, as no >> node can use the new options until every node is upgraded, even if t= he >> nodes do not need to make use of the new options. Mukul> Simply not true. >> In essence, the goyal-roll-rpl-compression is a fixed proprietary sy= stem. Mukul> I am sorry but this is totally wrong characterization. okay. I will re-read the document. I admit that I read it quickly as you presented in July, and your presentation worried me. > The > other RPL options, for which a compression format is not specified in > this document, MUST follow the format in which they are defined when > carried inside an RPL control message compressed as described in this > document. 1) So, how does a sending node know that all of recipients know about the compression of the current options? 2) How does a sending know that all of the recipients know about any new compressed option fields? =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATl1F6oCLcPvd0N1lAQLlJAf/aO2B3k73VeYsMBWD8AK8OUi1WO8xLEqD MfzRog/23HQn6CBsOmTyzh1Cg+wzX3ejo6VNLGbG7lDfhTBfSyP1INrbpS3lTf1Q V6IyYpVP1cVILSixv1CSKWKyus9B17Pi4L1x4WSmxvO2E1Kgzv5n34lMfmQaQ2nE 7QvjAnrRB29G4Uok60g2hAZZmqqZk793RmJNsqqTlzbmTN0iJDzCRigeBPWcC2zI d/KMhgMjPxgfRxsuduHeo7/95m6MjtRLzRmznBExb6Kh0ZZPXr/Cz4H0NsSSLoz8 CNvFP0RzIZWcdb8FpOaZtXfi6HXkj8NvWukadRSUYuY1N5MDIGF9Ag== =xG8Y -----END PGP SIGNATURE----- --=-=-=-- From ulrich@herberg.name Tue Aug 30 13:19:04 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62D421F8F4C for ; Tue, 30 Aug 2011 13:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.907 X-Spam-Level: X-Spam-Status: No, score=-2.907 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dhUBRwisuLb for ; Tue, 30 Aug 2011 13:19:04 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0E821F8F73 for ; Tue, 30 Aug 2011 13:18:55 -0700 (PDT) Received: by qwc23 with SMTP id 23so18625qwc.31 for ; Tue, 30 Aug 2011 13:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nfSccIBR6QrZuS6Lwui2zWUx1yr2oSjBHGtPoIQ9rqo=; b=GpwmntHT+R+LJzysS2MGnte5agNPA8atObL3BcM8sWOj4/GWs6QevIPaZoD/ZtLFZO 1ELFvOGBdi5a2Z/0riQRQM85fdOCgvdpK6sD+AWj40PsWx3obUyArGWxUKV+CgOL02hj JrHZn5Au9nQ6KRD8IO90MuvVlbQscmSs4VYYM= MIME-Version: 1.0 Received: by 10.52.27.34 with SMTP id q2mr1750256vdg.214.1314735622049; Tue, 30 Aug 2011 13:20:22 -0700 (PDT) Received: by 10.220.51.130 with HTTP; Tue, 30 Aug 2011 13:20:21 -0700 (PDT) In-Reply-To: <877272675.140749.1314734995826.JavaMail.root@mail05.pantherlink.uwm.edu> References: <1593431155.140676.1314734802999.JavaMail.root@mail05.pantherlink.uwm.edu> <877272675.140749.1314734995826.JavaMail.root@mail05.pantherlink.uwm.edu> Date: Tue, 30 Aug 2011 13:20:21 -0700 Message-ID: From: Ulrich Herberg To: Mukul Goyal Content-Type: multipart/alternative; boundary=bcaec5014df3b9cf4804abbebd01 Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 20:19:05 -0000 --bcaec5014df3b9cf4804abbebd01 Content-Type: text/plain; charset=ISO-8859-1 Let me give an example: a node, "speaking" only uncompressed RPL messages, joins the network. It needs to get the DODAG Configuration Option. Now the other nodes (inclusive the root node) use the compressed RPL messages. How can the new node get the required information then? Similarly, what happens if that "classic" RPL node receives a compressed DIO message? Yes, the message has a different code, and thus would not be parsed by the node. Therefore, this node is excluded from network operation. I would also like to repeat my question I raised during the ROLL meeting: If we know now how to compress messages much better, why don't we update the RPL specification, instead of adding new message / option types in additional drafts? Ulrich On Tue, Aug 30, 2011 at 1:09 PM, Mukul Goyal wrote: > Please realize that the compressed objects have different code values than > regular objects. Hence there is no danger of lack of interoperability. > > Thanks > Mukul > > ----- Original Message ----- > From: "Mukul Goyal" > To: "Ulrich Herberg" > Cc: "roll WG" > Sent: Tuesday, August 30, 2011 3:06:43 PM > Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new > ROLL WG document > > By the same logic, you would argue that P2P-RPL would lead to > non-interoperable implementations since some devices would speak P2P-RPL and > others wont. > > Thanks > Mukul > > ----- Original Message ----- > From: "Ulrich Herberg" > To: "Michael Richardson" > Cc: "Mukul Goyal" , "roll WG" > Sent: Tuesday, August 30, 2011 2:58:21 PM > Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new > ROLL WG document > > I agree with Michael's concern that using GRRC could lead to > non-interoperable implementations, with some nodes "speaking" normal RPL, > some using GRRC. That might require some additional negotiation between > nodes, or worse, could lead to non-interoperable parts of the network. That > worries me. > > Ulrich > > > On Tue, Aug 30, 2011 at 12:53 PM, Michael Richardson < mcr@sandelman.ca > > wrote: > > > > >>>>> "Mukul" == Mukul Goyal < mukul@uwm.edu > writes: > Mukul> I was wondering if you have the compression scheme described > Mukul> in draft-bormann-6lowpan-ghc in mind. I guess it will be > Mukul> useful to compare the compression achieved using the two > Mukul> schemes for the two examples described in > Mukul> draft-goyal-roll-rpl-compression. I think that compression > Mukul> achieved with draft-bormann scheme would vary with the actual > Mukul> byte stream contained in the packet. There is ofcourse no > Mukul> such dependency in case of our scheme. > > yes, but the goyal-roll-rpl-compression (GRRC from now on, okay?) scheme > will result in devices that support the compressed format only, > essentially creating an entirely new protocol. > > 6lowpan-ghc applies things as a layered approach, which means that after > decompression, you still need a full RPL packet parser, which means that > the RPL protocol can in fact evolve. > > goyal-roll-rpl-compression (GRRC) scheme will have to be revised each time > there is an addition to the protocol, and will cause a flag day, as no > node can use the new options until every node is upgraded, even if the > nodes do not need to make use of the new options. > > In essence, the goyal-roll-rpl-compression is a fixed proprietary > system. > > > > > -- > ] He who is tired of Weird Al is tired of life! | > firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device > driver[ > Kyoto Plus: watch the video < http://www.youtube.com/watch?v=kzx1ycLXQSE> > then sign the petition. > _______________________________________________ > 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 > --bcaec5014df3b9cf4804abbebd01 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Let me give an example: a node, "speaking" only uncompressed RPL = messages, joins the network. It needs to get the DODAG Configuration Option= . Now the other nodes (inclusive the root node) use the compressed RPL mess= ages. How can the new node get the required information then?

Similarly, what happens if that "classic" RPL node receives a= compressed DIO message? Yes, the message has a different code, and thus wo= uld not be parsed by the node. Therefore, this node is excluded from networ= k operation.

I would also like to repeat my question I raised during the ROLL meetin= g: If we know now how to compress messages much better, why don't we up= date the RPL specification, instead of adding new message / option types in= additional drafts?

Ulrich

On Tue, Aug 30, 2011 at 1:09 P= M, Mukul Goyal <mukul= @uwm.edu> wrote:
Please realize that the compressed objects have different code values than = regular objects. Hence there is no danger of lack of interoperability.

Thanks
Mukul

----- Original Message -----
From: "Mukul Goyal" <mukul@uw= m.edu>
To: "Ulrich Herberg" <u= lrich@herberg.name>
Cc: "roll WG" <roll@ietf.org<= /a>>
Sent: Tuesday, August 30, 2011 3:06:43 PM
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new R= OLL WG document

By the same logic, you would argue that P2P-RPL would lead to non-interoper= able implementations since some devices would speak P2P-RPL and others wont= .

Thanks
Mukul

----- Original Message -----
From: "Ulrich Herberg" <ulrich@herberg.name>
To: "Michael Richardson" <= mcr@sandelman.ca>
Cc: "Mukul Goyal" <mukul@uwm.= edu>, "roll WG" <roll@= ietf.org>
Sent: Tuesday, August 30, 2011 2:58:21 PM
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new R= OLL WG document

I agree with Michael's concern that using GRRC could lead to non-intero= perable implementations, with some nodes "speaking" normal RPL, s= ome using GRRC. That might require some additional negotiation between node= s, or worse, could lead to non-interoperable parts of the network. That wor= ries me.

Ulrich


On Tue, Aug 30, 2011 at 12:53 PM, Michael Richardson < mcr@sandelman.ca > wrote:



>>>>> "Mukul" =3D=3D Mukul Goyal < mukul@uwm.edu > writes:
=A0 =A0Mukul> I was wondering if you have the compression scheme describ= ed
=A0 =A0Mukul> in draft-bormann-6lowpan-ghc in mind. I guess it will be =A0 =A0Mukul> useful to compare the compression achieved using the two =A0 =A0Mukul> schemes for the two examples described in
=A0 =A0Mukul> draft-goyal-roll-rpl-compression. I think that compression=
=A0 =A0Mukul> achieved with draft-bormann scheme would vary with the act= ual
=A0 =A0Mukul> byte stream contained in the packet. There is ofcourse no<= br> =A0 =A0Mukul> such dependency in case of our scheme.

yes, but the goyal-roll-rpl-compression (GRRC from now on, okay?) scheme will result in devices that support the compressed format only,
essentially creating an entirely new protocol.

6lowpan-ghc applies things as a layered approach, which means that after decompression, you still need a full RPL packet parser, which means that the RPL protocol can in fact evolve.

goyal-roll-rpl-compression (GRRC) scheme will have to be revised each time<= br> there is an addition to the protocol, and will cause a flag day, as no
node can use the new options until every node is upgraded, even if the
nodes do not need to make use of the new options.

In essence, the goyal-roll-rpl-compression is a fixed proprietary
system.




--
] =A0 =A0 =A0 He who is tired of Weird Al is tired of life! =A0 =A0 =A0 =A0= =A0 | =A0firewalls =A0[
] =A0 Michael Richardson, Sandelman Software Works, Ottawa, ON =A0 =A0|net = architect[
] mcr@sandelman.ottawa.on.ca<= /a> http:/= /www.sandelman.ottawa.on.ca/ |device driver[
=A0 Kyoto Plus: watch the video < http://www.youtube.com/watch?v=3Dkzx1y= cLXQSE >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 then sign the petition.
_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

_______________________________________________

--bcaec5014df3b9cf4804abbebd01-- From ulrich@herberg.name Tue Aug 30 13:20:03 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E25C21F8F4F for ; Tue, 30 Aug 2011 13:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hH-I4liJ1YV3 for ; Tue, 30 Aug 2011 13:20:02 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id F3AA421F8CC2 for ; Tue, 30 Aug 2011 13:19:55 -0700 (PDT) Received: by vws12 with SMTP id 12so12527vws.31 for ; Tue, 30 Aug 2011 13:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+BqCYnlHBEZufYAGkHM7gmHfNVs+ef3natFgzArqu5g=; b=EX3SuedIxRNjbbI4yxkl/bQqig695dBQVbThE87ykCoHGnUuk9yBvDudeT1Vrsygt3 xsmQntq/co9MH2E7UoCO0+1KHPckA11LEyGDvC5dkC6dUuP/8fQ971rrIDwFy2y4oMky vDTKsbO07u6JfTSqkJzmSNxspyXkkhsJVnnnA= MIME-Version: 1.0 Received: by 10.220.172.7 with SMTP id j7mr2243413vcz.246.1314735683830; Tue, 30 Aug 2011 13:21:23 -0700 (PDT) Received: by 10.220.51.130 with HTTP; Tue, 30 Aug 2011 13:21:23 -0700 (PDT) In-Reply-To: <44019259.140892.1314735370623.JavaMail.root@mail05.pantherlink.uwm.edu> References: <44019259.140892.1314735370623.JavaMail.root@mail05.pantherlink.uwm.edu> Date: Tue, 30 Aug 2011 13:21:23 -0700 Message-ID: From: Ulrich Herberg To: Mukul Goyal Content-Type: multipart/alternative; boundary=0016e65da51668851c04abbec19e Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 20:20:03 -0000 --0016e65da51668851c04abbec19e Content-Type: text/plain; charset=ISO-8859-1 That's a non-constructive statement, which does not help our discussion nor for the progress of the WG. Ulrich On Tue, Aug 30, 2011 at 1:16 PM, Mukul Goyal wrote: > I am sorry but your argument is wrong. > > Mukul > > ----- Original Message ----- > From: "Ulrich Herberg" > To: "Mukul Goyal" > Cc: "roll WG" , "Michael Richardson" > Sent: Tuesday, August 30, 2011 3:12:12 PM > Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new > ROLL WG document > > Yes, I indeed do argue the same way. Adding ever more companion documents > to RPL makes it more and more difficult to guarantee interoperable > implementations. But that's another topic. > > Ulrich > > > On Tue, Aug 30, 2011 at 1:06 PM, Mukul Goyal < mukul@uwm.edu > wrote: > > > By the same logic, you would argue that P2P-RPL would lead to > non-interoperable implementations since some devices would speak P2P-RPL and > others wont. > > Thanks > Mukul > > > ----- Original Message ----- > From: "Ulrich Herberg" < ulrich@herberg.name > > To: "Michael Richardson" < mcr@sandelman.ca > > Cc: "Mukul Goyal" < mukul@uwm.edu >, "roll WG" < roll@ietf.org > > Sent: Tuesday, August 30, 2011 2:58:21 PM > Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new > ROLL WG document > > > > > I agree with Michael's concern that using GRRC could lead to > non-interoperable implementations, with some nodes "speaking" normal RPL, > some using GRRC. That might require some additional negotiation between > nodes, or worse, could lead to non-interoperable parts of the network. That > worries me. > > Ulrich > > > On Tue, Aug 30, 2011 at 12:53 PM, Michael Richardson < mcr@sandelman.ca > > wrote: > > > > >>>>> "Mukul" == Mukul Goyal < mukul@uwm.edu > writes: > Mukul> I was wondering if you have the compression scheme described > Mukul> in draft-bormann-6lowpan-ghc in mind. I guess it will be > Mukul> useful to compare the compression achieved using the two > Mukul> schemes for the two examples described in > Mukul> draft-goyal-roll-rpl-compression. I think that compression > Mukul> achieved with draft-bormann scheme would vary with the actual > Mukul> byte stream contained in the packet. There is ofcourse no > Mukul> such dependency in case of our scheme. > > yes, but the goyal-roll-rpl-compression (GRRC from now on, okay?) scheme > will result in devices that support the compressed format only, > essentially creating an entirely new protocol. > > 6lowpan-ghc applies things as a layered approach, which means that after > decompression, you still need a full RPL packet parser, which means that > the RPL protocol can in fact evolve. > > goyal-roll-rpl-compression (GRRC) scheme will have to be revised each time > there is an addition to the protocol, and will cause a flag day, as no > node can use the new options until every node is upgraded, even if the > nodes do not need to make use of the new options. > > In essence, the goyal-roll-rpl-compression is a fixed proprietary > system. > > > > > -- > ] He who is tired of Weird Al is tired of life! | > firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device > driver[ > Kyoto Plus: watch the video < http://www.youtube.com/watch?v=kzx1ycLXQSE> > then sign the petition. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > --0016e65da51668851c04abbec19e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That's a non-constructive statement, which does not help our discussion= nor for the progress of the WG.

Ulrich

On Tue, Aug 30, 2011 at 1:16 PM, Mukul Goyal <mukul@uwm.edu> wrote:
I am sorry but your argument is wrong.

Mukul

----- Original Message -----
From: "Ulrich Herberg" <ulrich@herberg.name>
To: "Mukul Goyal" <mukul@uwm.edu>
Cc: "roll WG" <roll@ietf.org<= /a>>, "Michael Richardson" <mcr@sandelman.ca>
Sent: Tuesday, August 30, 2011 3:12:12 PM
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new R= OLL WG document

Yes, I indeed do argue the same way. Adding ever more companion documents t= o RPL makes it more and more difficult to guarantee interoperable implement= ations. But that's another topic.

Ulrich


On Tue, Aug 30, 2011 at 1:06 PM, Mukul Goyal < mukul@uwm.edu > wrote:


By the same logic, you would argue that P2P-RPL would lead to non-interoper= able implementations since some devices would speak P2P-RPL and others wont= .

Thanks
Mukul


----- Original Message -----
From: "Ulrich Herberg" < ulrich@herberg.name >
To: "Michael Richardson" < mcr@sandelman.ca >
Cc: "Mukul Goyal" < mukul@uwm= .edu >, "roll WG" < ro= ll@ietf.org >
Sent: Tuesday, August 30, 2011 2:58:21 PM
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new R= OLL WG document




I agree with Michael's concern that using GRRC could lead to non-intero= perable implementations, with some nodes "speaking" normal RPL, s= ome using GRRC. That might require some additional negotiation between node= s, or worse, could lead to non-interoperable parts of the network. That wor= ries me.

Ulrich


On Tue, Aug 30, 2011 at 12:53 PM, Michael Richardson < mcr@sandelman.ca > wrote:



>>>>> "Mukul" =3D=3D Mukul Goyal < mukul@uwm.edu > writes:
=A0 =A0Mukul> I was wondering if you have the compression scheme describ= ed
=A0 =A0Mukul> in draft-bormann-6lowpan-ghc in mind. I guess it will be =A0 =A0Mukul> useful to compare the compression achieved using the two =A0 =A0Mukul> schemes for the two examples described in
=A0 =A0Mukul> draft-goyal-roll-rpl-compression. I think that compression=
=A0 =A0Mukul> achieved with draft-bormann scheme would vary with the act= ual
=A0 =A0Mukul> byte stream contained in the packet. There is ofcourse no<= br> =A0 =A0Mukul> such dependency in case of our scheme.

yes, but the goyal-roll-rpl-compression (GRRC from now on, okay?) scheme will result in devices that support the compressed format only,
essentially creating an entirely new protocol.

6lowpan-ghc applies things as a layered approach, which means that after decompression, you still need a full RPL packet parser, which means that the RPL protocol can in fact evolve.

goyal-roll-rpl-compression (GRRC) scheme will have to be revised each time<= br> there is an addition to the protocol, and will cause a flag day, as no
node can use the new options until every node is upgraded, even if the
nodes do not need to make use of the new options.

In essence, the goyal-roll-rpl-compression is a fixed proprietary
system.




--
] =A0 =A0 =A0 He who is tired of Weird Al is tired of life! =A0 =A0 =A0 =A0= =A0 | =A0firewalls =A0[
] =A0 Michael Richardson, Sandelman Software Works, Ottawa, ON =A0 =A0|net = architect[
] mcr@sandelman.ottawa.on.ca<= /a> http:/= /www.sandelman.ottawa.on.ca/ |device driver[
=A0 Kyoto Plus: watch the video < http://www.youtube.com/watch?v=3Dkzx1y= cLXQSE >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 then sign the petition.
_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll



--0016e65da51668851c04abbec19e-- From prvs=2160146b2=mukul@uwm.edu Tue Aug 30 14:01:19 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0044221F8C8C for ; Tue, 30 Aug 2011 14:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.32 X-Spam-Level: X-Spam-Status: No, score=-3.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJunp+6HtN1g for ; Tue, 30 Aug 2011 14:01:18 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5F14B21F8C7F for ; Tue, 30 Aug 2011 14:01:18 -0700 (PDT) Received: from localhost (HELO mta01.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 30 Aug 2011 16:01:56 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 94124E6A70; Tue, 30 Aug 2011 16:02:46 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VsS5Ml+2sfC; Tue, 30 Aug 2011 16:02:46 -0500 (CDT) Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 63695E6A74; Tue, 30 Aug 2011 16:02:46 -0500 (CDT) Date: Tue, 30 Aug 2011 16:02:46 -0500 (CDT) From: Mukul Goyal To: Michael Richardson Message-ID: <1440152250.141642.1314738166303.JavaMail.root@mail05.pantherlink.uwm.edu> In-Reply-To: <32348.1314735595@marajade.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 21:01:19 -0000 >> goyal-roll-rpl-compression (GRRC) scheme will have to be revised each time >> there is an addition to the protocol, Mukul> Again not true. Any new additions to the protocol DO NOT Mukul> require their compressed formats to be specified as well. One Mukul> could ofcourse define compressed formats (or define only the Mukul> compressed formats) if they are deemed useful. But it is not Mukul> mandatory to do so. >yes, but: > 1) will nodes know how to process the new extensions? I understand that you are arguing in favor of the ghc scheme. But the key question is whether we can depend on the ghc scheme alone to give us enough compression. > 2) will including the new extensions, uncompressed, blow the MTU, and so nobody will ever turn them on? Not sure how such concerns constitute an argument against draft-goyal or in favor of your contention that every new extension would require their compressed formats to be defined. Compressed formats would be defined where they are deemed useful. >> The >> other RPL options, for which a compression format is not specified in >> this document, MUST follow the format in which they are defined when >> carried inside an RPL control message compressed as described in this >> document. >1) So, how does a sending node know that all of recipients know about the > compression of the current options? A compressed option has a different option type than its regular version. By looking at the option type, a node would know whether it is compressed or not. >2) How does a sending know that all of the recipients know about any new > compressed option fields? The sending node does not know. The recipient would ignore the options it does not know about (or discard the whole message itself as specified in the core spec). I am not sure why the fact that nodes need to know about the compressed objects/options in order to process them is being used as an argument against this draft. RPL nodes would still be able to talk core RPL among themselves irrespective of whether they implement this draft or not. Their existing functionality is not affected. Thanks Mukul From prvs=2160146b2=mukul@uwm.edu Tue Aug 30 15:16:53 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B88B21F8ED9 for ; Tue, 30 Aug 2011 15:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVNe3WWXXNvs for ; Tue, 30 Aug 2011 15:16:52 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 413EB21F8B3E for ; Tue, 30 Aug 2011 15:16:52 -0700 (PDT) Received: from localhost (HELO mta04.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 30 Aug 2011 17:17:30 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id B05F62B3EC3; Tue, 30 Aug 2011 17:17:50 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-8ijbbcI1ci; Tue, 30 Aug 2011 17:17:49 -0500 (CDT) Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 81AE22B3EC2; Tue, 30 Aug 2011 17:17:49 -0500 (CDT) Date: Tue, 30 Aug 2011 17:18:19 -0500 (CDT) From: Mukul Goyal To: Ulrich Herberg Message-ID: <111422722.142689.1314742699308.JavaMail.root@mail05.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 22:16:53 -0000 Ulrich 1. Why would a node transmit only compressed DIOs when it expects its liste= ners to include those that do not understand compression?=20 Your example seems similar to these: a) A non-storing node not being able to join a storing mode DAG b) A node that does not understand RPL security can't join a DAG using secu= re messages. 2. Assuming that the scenario you described is plausible, a simple DIS flag= /option can be defined to solve the problem trivially. But ofcourse you wou= ld then complain about additional complexity. Thanks Mukul ----- Original Message ----- From: "Ulrich Herberg" To: "Mukul Goyal" Cc: "roll WG" Sent: Tuesday, August 30, 2011 3:20:21 PM Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new R= OLL WG document Let me give an example: a node, "speaking" only uncompressed RPL messages, = joins the network. It needs to get the DODAG Configuration Option. Now the = other nodes (inclusive the root node) use the compressed RPL messages. How = can the new node get the required information then?=20 Similarly, what happens if that "classic" RPL node receives a compressed DI= O message? Yes, the message has a different code, and thus would not be par= sed by the node. Therefore, this node is excluded from network operation.= =20 I would also like to repeat my question I raised during the ROLL meeting: I= f we know now how to compress messages much better, why don't we update the= RPL specification, instead of adding new message / option types in additio= nal drafts?=20 Ulrich=20 On Tue, Aug 30, 2011 at 1:09 PM, Mukul Goyal < mukul@uwm.edu > wrote:=20 Please realize that the compressed objects have different code values than = regular objects. Hence there is no danger of lack of interoperability.=20 Thanks=20 Mukul=20 ----- Original Message -----=20 From: "Mukul Goyal" < mukul@uwm.edu >=20 To: "Ulrich Herberg" < ulrich@herberg.name >=20 Cc: "roll WG" < roll@ietf.org >=20 Sent: Tuesday, August 30, 2011 3:06:43 PM=20 Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new R= OLL WG document=20 By the same logic, you would argue that P2P-RPL would lead to non-interoper= able implementations since some devices would speak P2P-RPL and others wont= .=20 Thanks=20 Mukul=20 ----- Original Message -----=20 From: "Ulrich Herberg" < ulrich@herberg.name >=20 To: "Michael Richardson" < mcr@sandelman.ca >=20 Cc: "Mukul Goyal" < mukul@uwm.edu >, "roll WG" < roll@ietf.org >=20 Sent: Tuesday, August 30, 2011 2:58:21 PM=20 Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new R= OLL WG document=20 I agree with Michael's concern that using GRRC could lead to non-interopera= ble implementations, with some nodes "speaking" normal RPL, some using GRRC= . That might require some additional negotiation between nodes, or worse, c= ould lead to non-interoperable parts of the network. That worries me.=20 Ulrich=20 On Tue, Aug 30, 2011 at 12:53 PM, Michael Richardson < mcr@sandelman.ca > w= rote:=20 >>>>> "Mukul" =3D=3D Mukul Goyal < mukul@uwm.edu > writes:=20 =C2=A0 =C2=A0Mukul> I was wondering if you have the compression scheme desc= ribed=20 =C2=A0 =C2=A0Mukul> in draft-bormann-6lowpan-ghc in mind. I guess it will b= e=20 =C2=A0 =C2=A0Mukul> useful to compare the compression achieved using the tw= o=20 =C2=A0 =C2=A0Mukul> schemes for the two examples described in=20 =C2=A0 =C2=A0Mukul> draft-goyal-roll-rpl-compression. I think that compress= ion=20 =C2=A0 =C2=A0Mukul> achieved with draft-bormann scheme would vary with the = actual=20 =C2=A0 =C2=A0Mukul> byte stream contained in the packet. There is ofcourse = no=20 =C2=A0 =C2=A0Mukul> such dependency in case of our scheme.=20 yes, but the goyal-roll-rpl-compression (GRRC from now on, okay?) scheme=20 will result in devices that support the compressed format only,=20 essentially creating an entirely new protocol.=20 6lowpan-ghc applies things as a layered approach, which means that after=20 decompression, you still need a full RPL packet parser, which means that=20 the RPL protocol can in fact evolve.=20 goyal-roll-rpl-compression (GRRC) scheme will have to be revised each time= =20 there is an addition to the protocol, and will cause a flag day, as no=20 node can use the new options until every node is upgraded, even if the=20 nodes do not need to make use of the new options.=20 In essence, the goyal-roll-rpl-compression is a fixed proprietary=20 system.=20 --=20 ] =C2=A0 =C2=A0 =C2=A0 He who is tired of Weird Al is tired of life! =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0firewalls =C2=A0[=20 ] =C2=A0 Michael Richardson, Sandelman Software Works, Ottawa, ON =C2=A0 = =C2=A0|net architect[=20 ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[=20 =C2=A0 Kyoto Plus: watch the video < http://www.youtube.com/watch?v=3Dkzx1y= cLXQSE >=20 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 then sign the petition.=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 From ulrich@herberg.name Tue Aug 30 15:37:44 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32E221F8A7A for ; Tue, 30 Aug 2011 15:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.914 X-Spam-Level: X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJKGPqxr7BqJ for ; Tue, 30 Aug 2011 15:37:43 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 17DCA21F8A55 for ; Tue, 30 Aug 2011 15:37:42 -0700 (PDT) Received: by vxi29 with SMTP id 29so4758vxi.31 for ; Tue, 30 Aug 2011 15:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F96bcNC0+3B6FDRZ6I97ltTXqJjnNIs4XDhz12WXFvc=; b=yAqASFU0NTtiKtIJk+rTrTkTobtaZPQtdhJfMQpZX2uNxBi/wo18Q8Ufcm6RYBd5i9 lEEA80V4hLl1L47uFPUC0ir7Cb3avhcZDhjDhEB/7OzS8eigJT3ZO3w3GBIl0kUKxMJ+ JucCPUdA04ui0axHW1rb+9xf2Qnuh0UNz2FKs= MIME-Version: 1.0 Received: by 10.220.172.7 with SMTP id j7mr2267557vcz.246.1314743948911; Tue, 30 Aug 2011 15:39:08 -0700 (PDT) Received: by 10.220.51.130 with HTTP; Tue, 30 Aug 2011 15:39:08 -0700 (PDT) In-Reply-To: <111422722.142689.1314742699308.JavaMail.root@mail05.pantherlink.uwm.edu> References: <111422722.142689.1314742699308.JavaMail.root@mail05.pantherlink.uwm.edu> Date: Tue, 30 Aug 2011 15:39:08 -0700 Message-ID: From: Ulrich Herberg To: Mukul Goyal Content-Type: multipart/alternative; boundary=0016e65da5160ba51504abc0aedd Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 22:37:44 -0000 --0016e65da5160ba51504abc0aedd Content-Type: text/plain; charset=ISO-8859-1 Mukul, On Tue, Aug 30, 2011 at 3:18 PM, Mukul Goyal wrote: > Ulrich > > 1. Why would a node transmit only compressed DIOs when it expects its > listeners to include those that do not understand compression? > How would it know what its listeners expect? If there is a chance that any of the nodes in the network does not understand compression (which none of the other nodes would know), the nodes in the network either all use uncompressed messages or deprive that node from communicating. > > Your example seems similar to these: > a) A non-storing node not being able to join a storing mode DAG > b) A node that does not understand RPL security can't join a DAG using > secure messages. > > 2. Assuming that the scenario you described is plausible, a simple DIS > flag/option can be defined to solve the problem trivially. But ofcourse you > would then complain about additional complexity. > Not only that I don't like that additional DIS flag for the reason you mentioned (and which has to be specified somewhere), but I also think there is a difference to the two examples you gave: If an implementation of RPL does not support one Mode of Operation, this is a design choice; the implementer knows that his/her implementation does not fully support the RPL spec, so it is not expected to be fully interoperable. With the compression, I can have a compliant (i.e. complete) RPL implementation, and it *still* does not interoperate with all nodes (and I, as implementer, might not even know about the compression format, since there is no reference to it in the RPL spec). Regards Ulrich > > Thanks > Mukul > > ----- Original Message ----- > From: "Ulrich Herberg" > To: "Mukul Goyal" > Cc: "roll WG" > Sent: Tuesday, August 30, 2011 3:20:21 PM > Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new > ROLL WG document > > Let me give an example: a node, "speaking" only uncompressed RPL messages, > joins the network. It needs to get the DODAG Configuration Option. Now the > other nodes (inclusive the root node) use the compressed RPL messages. How > can the new node get the required information then? > > Similarly, what happens if that "classic" RPL node receives a compressed > DIO message? Yes, the message has a different code, and thus would not be > parsed by the node. Therefore, this node is excluded from network operation. > > I would also like to repeat my question I raised during the ROLL meeting: > If we know now how to compress messages much better, why don't we update the > RPL specification, instead of adding new message / option types in > additional drafts? > > Ulrich > > > On Tue, Aug 30, 2011 at 1:09 PM, Mukul Goyal < mukul@uwm.edu > wrote: > > > Please realize that the compressed objects have different code values than > regular objects. Hence there is no danger of lack of interoperability. > > Thanks > Mukul > > > > > ----- Original Message ----- > From: "Mukul Goyal" < mukul@uwm.edu > > To: "Ulrich Herberg" < ulrich@herberg.name > > Cc: "roll WG" < roll@ietf.org > > Sent: Tuesday, August 30, 2011 3:06:43 PM > Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new > ROLL WG document > > By the same logic, you would argue that P2P-RPL would lead to > non-interoperable implementations since some devices would speak P2P-RPL and > others wont. > > Thanks > Mukul > > ----- Original Message ----- > From: "Ulrich Herberg" < ulrich@herberg.name > > To: "Michael Richardson" < mcr@sandelman.ca > > Cc: "Mukul Goyal" < mukul@uwm.edu >, "roll WG" < roll@ietf.org > > Sent: Tuesday, August 30, 2011 2:58:21 PM > Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new > ROLL WG document > > I agree with Michael's concern that using GRRC could lead to > non-interoperable implementations, with some nodes "speaking" normal RPL, > some using GRRC. That might require some additional negotiation between > nodes, or worse, could lead to non-interoperable parts of the network. That > worries me. > > Ulrich > > > On Tue, Aug 30, 2011 at 12:53 PM, Michael Richardson < mcr@sandelman.ca > > wrote: > > > > >>>>> "Mukul" == Mukul Goyal < mukul@uwm.edu > writes: > Mukul> I was wondering if you have the compression scheme described > Mukul> in draft-bormann-6lowpan-ghc in mind. I guess it will be > Mukul> useful to compare the compression achieved using the two > Mukul> schemes for the two examples described in > Mukul> draft-goyal-roll-rpl-compression. I think that compression > Mukul> achieved with draft-bormann scheme would vary with the actual > Mukul> byte stream contained in the packet. There is ofcourse no > Mukul> such dependency in case of our scheme. > > yes, but the goyal-roll-rpl-compression (GRRC from now on, okay?) scheme > will result in devices that support the compressed format only, > essentially creating an entirely new protocol. > > 6lowpan-ghc applies things as a layered approach, which means that after > decompression, you still need a full RPL packet parser, which means that > the RPL protocol can in fact evolve. > > goyal-roll-rpl-compression (GRRC) scheme will have to be revised each time > there is an addition to the protocol, and will cause a flag day, as no > node can use the new options until every node is upgraded, even if the > nodes do not need to make use of the new options. > > In essence, the goyal-roll-rpl-compression is a fixed proprietary > system. > > > > > -- > ] He who is tired of Weird Al is tired of life! | > firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device > driver[ > Kyoto Plus: watch the video < http://www.youtube.com/watch?v=kzx1ycLXQSE> > then sign the petition. > _______________________________________________ > 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 > > --0016e65da5160ba51504abc0aedd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mukul,

On Tue, Aug 30, 2011 at 3:18 PM, M= ukul Goyal <mukul@uwm= .edu> wrote:
Ulrich

1. Why would a node transmit only compressed DIOs when it expects its liste= ners to include those that do not understand compression?
<= div>

How would it know what its listeners expect? If there is a chan= ce that any of the nodes in the network does not understand compression (wh= ich none of the other nodes would know), the nodes in the network either al= l use uncompressed messages or deprive that node from communicating.
=A0

Your example seems similar to these:
a) A non-storing node not being able to join a storing mode DAG
b) A node that does not understand RPL security can't join a DAG using = secure messages.

2. Assuming that the scenario you described is plausible, a simple DIS flag= /option can be defined to solve the problem trivially. But ofcourse you wou= ld then complain about additional complexity.


Not only that I don't like that additional DIS flag for the reason = you mentioned (and which has to be specified somewhere), but I also think t= here is a difference to the two examples you gave: If an implementation of = RPL does not support one Mode of Operation, this is a design choice; the im= plementer knows that his/her implementation does not fully support the RPL = spec, so it is not expected to be fully interoperable. With the compression= , I can have a compliant (i.e. complete) RPL implementation, and it *still*= does not interoperate with all nodes (and I, as implementer, might not eve= n know about the compression format, since there is no reference to it in t= he RPL spec).

Regards
Ulrich

=A0

Thanks
Mukul

----- Original Message -----
From: "Ulrich Herberg" <ulrich@herberg.name>
To: "Mukul Goyal" <mukul@uwm.edu>
Cc: "roll WG" <roll@ietf.org<= /a>>
Sent: Tuesday, August 30, 2011 3:20= :21 PM
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new R= OLL WG document

Let me give an example: a node, "speaking" only uncompressed RPL = messages, joins the network. It needs to get the DODAG Configuration Option= . Now the other nodes (inclusive the root node) use the compressed RPL mess= ages. How can the new node get the required information then?

Similarly, what happens if that "classic" RPL node receives a com= pressed DIO message? Yes, the message has a different code, and thus would = not be parsed by the node. Therefore, this node is excluded from network op= eration.

I would also like to repeat my question I raised during the ROLL meeting: I= f we know now how to compress messages much better, why don't we update= the RPL specification, instead of adding new message / option types in add= itional drafts?

Ulrich


On Tue, Aug 30, 2011 at 1:09 PM, Mukul Goyal < mukul@uwm.edu > wrote:


Please realize that the compressed objects have different code values than = regular objects. Hence there is no danger of lack of interoperability.

Thanks
Mukul




----- Original Message -----
From: "Mukul Goyal" < mukul@u= wm.edu >
To: "Ulrich Herberg" < = ulrich@herberg.name >
Cc: "roll WG" < roll@ietf.org= >
Sent: Tuesday, August 30, 2011 3:06:43 PM
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new R= OLL WG document

By the same logic, you would argue that P2P-RPL would lead to non-interoper= able implementations since some devices would speak P2P-RPL and others wont= .

Thanks
Mukul

----- Original Message -----
From: "Ulrich Herberg" < ulrich@herberg.name >
To: "Michael Richardson" < mcr@sandelman.ca >
Cc: "Mukul Goyal" < mukul@uwm= .edu >, "roll WG" < ro= ll@ietf.org >
Sent: Tuesday, August 30, 2011 2:58:21 PM
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new R= OLL WG document

I agree with Michael's concern that using GRRC could lead to non-intero= perable implementations, with some nodes "speaking" normal RPL, s= ome using GRRC. That might require some additional negotiation between node= s, or worse, could lead to non-interoperable parts of the network. That wor= ries me.

Ulrich


On Tue, Aug 30, 2011 at 12:53 PM, Michael Richardson < mcr@sandelman.ca > wrote:



>>>>> "Mukul" =3D=3D Mukul Goyal < mukul@uwm.edu > writes:
=A0 =A0Mukul> I was wondering if you have the compression scheme describ= ed
=A0 =A0Mukul> in draft-bormann-6lowpan-ghc in mind. I guess it will be =A0 =A0Mukul> useful to compare the compression achieved using the two =A0 =A0Mukul> schemes for the two examples described in
=A0 =A0Mukul> draft-goyal-roll-rpl-compression. I think that compression=
=A0 =A0Mukul> achieved with draft-bormann scheme would vary with the act= ual
=A0 =A0Mukul> byte stream contained in the packet. There is ofcourse no<= br> =A0 =A0Mukul> such dependency in case of our scheme.

yes, but the goyal-roll-rpl-compression (GRRC from now on, okay?) scheme will result in devices that support the compressed format only,
essentially creating an entirely new protocol.

6lowpan-ghc applies things as a layered approach, which means that after decompression, you still need a full RPL packet parser, which means that the RPL protocol can in fact evolve.

goyal-roll-rpl-compression (GRRC) scheme will have to be revised each time<= br> there is an addition to the protocol, and will cause a flag day, as no
node can use the new options until every node is upgraded, even if the
nodes do not need to make use of the new options.

In essence, the goyal-roll-rpl-compression is a fixed proprietary
system.




--
] =A0 =A0 =A0 He who is tired of Weird Al is tired of life! =A0 =A0 =A0 =A0= =A0 | =A0firewalls =A0[
] =A0 Michael Richardson, Sandelman Software Works, Ottawa, ON =A0 =A0|net = architect[
] mcr@sandelman.ottawa.on.ca<= /a> http:/= /www.sandelman.ottawa.on.ca/ |device driver[
=A0 Kyoto Plus: watch the video < http://www.youtube.com/watch?v=3Dkzx1y= cLXQSE >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 then sign the petition.
_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

_______________________________________________



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


--0016e65da5160ba51504abc0aedd-- From mcr@sandelman.ca Tue Aug 30 18:09:55 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1113C21F8E4D for ; Tue, 30 Aug 2011 18:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.753 X-Spam-Level: X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7K6TRui2Qpl4 for ; Tue, 30 Aug 2011 18:09:53 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7DF21F8E2A for ; Tue, 30 Aug 2011 18:09:51 -0700 (PDT) Received: from marajade.sandelman.ca (wlan204.sandelman.ca [209.87.252.204]) by relay.sandelman.ca (Postfix) with ESMTPS id 857793404F for ; Tue, 30 Aug 2011 21:10:37 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 8084E98C6E for ; Tue, 30 Aug 2011 21:11:45 -0400 (EDT) From: Michael Richardson To: roll WG In-Reply-To: <1440152250.141642.1314738166303.JavaMail.root@mail05.pantherlink.uwm.edu> References: <1440152250.141642.1314738166303.JavaMail.root@mail05.pantherlink.uwm.edu> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 30 Aug 2011 21:11:44 -0400 Message-ID: <18355.1314753104@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 01:09:55 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Mukul" =3D=3D Mukul Goyal writes: Mukul> Not sure how such concerns constitute an argument against Mukul> draft-goyal or in favor of your contention that every new Mukul> extension would require their compressed formats to be Mukul> defined. Compressed formats would be defined where they are Mukul> deemed useful.=20 And, then what? Upgrade all the nodes in the building?=20=20 >> 1) So, how does a sending node know that all of recipients know abou= t the >> compression of the current options? Mukul> A compressed option has a different option type than its Mukul> regular version. By looking at the option type, a node would Mukul> know whether it is compressed or not.=20 Great, so to be sure that everyone understands, I should send both? :-) Mukul> The sending node does not know. The recipient would ignore Mukul> the options it does not know about (or discard the whole Mukul> message itself as specified in the core spec).=20=20 Mukul> I am not sure why the fact that nodes need to know about the Mukul> compressed objects/options in order to process them is being Mukul> used as an argument against this draft. RPL nodes would still Mukul> be able to talk core RPL among themselves irrespective of Mukul> whether they implement this draft or not. Their existing Mukul> functionality is not affected.=20=20 We are concerned about flag days and incremental deployment of new features. These features *INCLUDE* deploying new compressed options. I agree with Ulrich: if we now know much better about what options are essential and which ones are not, then let's just revise the spec, and remove the uncompressed version. I don't want to write and test the code twice.=20 =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATl2KUICLcPvd0N1lAQJvwAgAuLqjQnrXlJAw/Up1yjQNfeq63wBOBXM+ qMbRLbwLvT46UJW3EFacQAmGwHNRLUnIjbQTtV25GpRiPT9AtHRf5Bgi3w3K/5Dr skSoXv1gbY/PlteY9w6n77LwReusVXLjSJnD9xjvf4o8gzdD7iYo1hgaIzOYSNl2 h7eKBh3sDfxoMM5SYEfOfcGcRvgnsu0H57qYWUNwzDvxVf2ryhd/VNnrNrQOjpV+ 6ClFWC25O09wH7lwYdl+s/BvFYVcJLKLVR9NbD+dVxwldt+Dv80Fxnsxd6v6YryM NsqJhSSs6dsagY8SjMDjAhs8EBwO2ILJaNGkmb9cX44lobi1c4RqLw== =345B -----END PGP SIGNATURE----- --=-=-=-- From prvs=217dc3b4d=mukul@uwm.edu Tue Aug 30 19:06:29 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7DB21F8C12 for ; Tue, 30 Aug 2011 19:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.371 X-Spam-Level: X-Spam-Status: No, score=-3.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1D-AsZwBoYi for ; Tue, 30 Aug 2011 19:06:28 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0137521F8C08 for ; Tue, 30 Aug 2011 19:06:27 -0700 (PDT) Received: from localhost (HELO mta04.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 30 Aug 2011 21:07:06 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id C8B562B3EC2; Tue, 30 Aug 2011 21:07:26 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIsXOORpxFiJ; Tue, 30 Aug 2011 21:07:25 -0500 (CDT) Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 8A9822B3EC3; Tue, 30 Aug 2011 21:07:25 -0500 (CDT) Date: Tue, 30 Aug 2011 21:07:55 -0500 (CDT) From: Mukul Goyal To: Ulrich Herberg Message-ID: <1341212383.144347.1314756475351.JavaMail.root@mail05.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 02:06:29 -0000 >1. Why would a node transmit only compressed DIOs when it expects its list= eners to include those that do not understand >compression?=20 >How would it know what its listeners expect? If there is a chance that any= of the nodes in the network does not understand >compression (which none o= f the other nodes would know), the nodes in the network either all use unco= mpressed messages or deprive >that node from communicating.=20 The nodes would know because some body would configure that information in = them. Suppose that LLN consists of some devices that understand compression= and others that dont. Suppose a global DAG is required. In such situation,= the simplest option would be to create two DAGs - one using compressed mes= sages and the other using uncompressed ones. Another option would be to hav= e some nodes transmit compressed DIOs and others transmitting uncompressed = ones. Another option would be for a node to transmit uncompressed DIOs some= times and compressed ones at other times. So, there are many ways to avoid= the fate you are suggesting.=C2=A0=20 >>Your example seems similar to these:=20 >>a) A non-storing node not being able to join a storing mode DAG=20 >>b) A node that does not understand RPL security can't join a DAG using se= cure messages.=20 >>2. Assuming that the scenario you described is plausible, a simple DIS fl= ag/option can be defined to solve the problem >>trivially. But ofcourse you= would then complain about additional complexity.=20 >Not only that I don't like that additional DIS flag for the reason you men= tioned (and which has to be specified somewhere), > but I also think there is a difference to the two examples you gave: If a= n implementation of RPL does not support one Mode of >Operation, this is a = design choice; the implementer knows that his/her implementation does not f= ully support the RPL spec, so it >is not expected to be fully interoperable= . With the compression, I can have a compliant (i.e. complete) RPL implemen= tation, and >it *still* does not interoperate with all nodes (and I, as imp= lementer, might not even know about the compression format, since >there is= no reference to it in the RPL spec).=20 I dont quite understand. I no longer wish to use any negative adjective for= your argument. I suppose you do not want to see any extension to RPL becau= se any such extension would cause a "compliant/complete" implementation to = be not interoperable with others (that include the extension). At the very = least, you want to limit RPL extensions to those that have been explicitly = mentioned/referenced in the core spec.=20 Regards=20 Mukul=20 ----- Original Message -----=20 From: "Ulrich Herberg" < ulrich@herberg.name >=20 To: "Mukul Goyal" < mukul@uwm.edu >=20 Cc: "roll WG" < roll@ietf.org >=20 Sent: Tuesday, August 30, 2011 3:20:21 PM=20 Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new R= OLL WG document=20 Let me give an example: a node, "speaking" only uncompressed RPL messages, = joins the network. It needs to get the DODAG Configuration Option. Now the = other nodes (inclusive the root node) use the compressed RPL messages. How = can the new node get the required information then?=20 Similarly, what happens if that "classic" RPL node receives a compressed DI= O message? Yes, the message has a different code, and thus would not be par= sed by the node. Therefore, this node is excluded from network operation.= =20 I would also like to repeat my question I raised during the ROLL meeting: I= f we know now how to compress messages much better, why don't we update the= RPL specification, instead of adding new message / option types in additio= nal drafts?=20 Ulrich=20 On Tue, Aug 30, 2011 at 1:09 PM, Mukul Goyal < mukul@uwm.edu > wrote:=20 Please realize that the compressed objects have different code values than = regular objects. Hence there is no danger of lack of interoperability.=20 Thanks=20 Mukul=20 ----- Original Message -----=20 From: "Mukul Goyal" < mukul@uwm.edu >=20 To: "Ulrich Herberg" < ulrich@herberg.name >=20 Cc: "roll WG" < roll@ietf.org >=20 Sent: Tuesday, August 30, 2011 3:06:43 PM=20 Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new R= OLL WG document=20 By the same logic, you would argue that P2P-RPL would lead to non-interoper= able implementations since some devices would speak P2P-RPL and others wont= .=20 Thanks=20 Mukul=20 ----- Original Message -----=20 From: "Ulrich Herberg" < ulrich@herberg.name >=20 To: "Michael Richardson" < mcr@sandelman.ca >=20 Cc: "Mukul Goyal" < mukul@uwm.edu >, "roll WG" < roll@ietf.org >=20 Sent: Tuesday, August 30, 2011 2:58:21 PM=20 Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new R= OLL WG document=20 I agree with Michael's concern that using GRRC could lead to non-interopera= ble implementations, with some nodes "speaking" normal RPL, some using GRRC= . That might require some additional negotiation between nodes, or worse, c= ould lead to non-interoperable parts of the network. That worries me.=20 Ulrich=20 On Tue, Aug 30, 2011 at 12:53 PM, Michael Richardson < mcr@sandelman.ca > w= rote:=20 >>>>> "Mukul" =3D=3D Mukul Goyal < mukul@uwm.edu > writes:=20 =C2=A0 =C2=A0Mukul> I was wondering if you have the compression scheme desc= ribed=20 =C2=A0 =C2=A0Mukul> in draft-bormann-6lowpan-ghc in mind. I guess it will b= e=20 =C2=A0 =C2=A0Mukul> useful to compare the compression achieved using the tw= o=20 =C2=A0 =C2=A0Mukul> schemes for the two examples described in=20 =C2=A0 =C2=A0Mukul> draft-goyal-roll-rpl-compression. I think that compress= ion=20 =C2=A0 =C2=A0Mukul> achieved with draft-bormann scheme would vary with the = actual=20 =C2=A0 =C2=A0Mukul> byte stream contained in the packet. There is ofcourse = no=20 =C2=A0 =C2=A0Mukul> such dependency in case of our scheme.=20 yes, but the goyal-roll-rpl-compression (GRRC from now on, okay?) scheme=20 will result in devices that support the compressed format only,=20 essentially creating an entirely new protocol.=20 6lowpan-ghc applies things as a layered approach, which means that after=20 decompression, you still need a full RPL packet parser, which means that=20 the RPL protocol can in fact evolve.=20 goyal-roll-rpl-compression (GRRC) scheme will have to be revised each time= =20 there is an addition to the protocol, and will cause a flag day, as no=20 node can use the new options until every node is upgraded, even if the=20 nodes do not need to make use of the new options.=20 In essence, the goyal-roll-rpl-compression is a fixed proprietary=20 system.=20 --=20 ] =C2=A0 =C2=A0 =C2=A0 He who is tired of Weird Al is tired of life! =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0firewalls =C2=A0[=20 ] =C2=A0 Michael Richardson, Sandelman Software Works, Ottawa, ON =C2=A0 = =C2=A0|net architect[=20 ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[=20 =C2=A0 Kyoto Plus: watch the video < http://www.youtube.com/watch?v=3Dkzx1y= cLXQSE >=20 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 then sign the petition.=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 From prvs=217dc3b4d=mukul@uwm.edu Tue Aug 30 21:07:15 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE36621F8BBC for ; Tue, 30 Aug 2011 21:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.39 X-Spam-Level: X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLdIm8BWzIqZ for ; Tue, 30 Aug 2011 21:07:15 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id E7F5021F8BB1 for ; Tue, 30 Aug 2011 21:07:14 -0700 (PDT) Received: from localhost (HELO mta03.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 30 Aug 2011 23:07:53 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id F13051FD00F; Tue, 30 Aug 2011 23:08:43 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu 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 lwHs+vStJXOM; Tue, 30 Aug 2011 23:08:42 -0500 (CDT) Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id C6DCD1FD00E; Tue, 30 Aug 2011 23:08:42 -0500 (CDT) Date: Tue, 30 Aug 2011 23:08:42 -0500 (CDT) From: Mukul Goyal To: Michael Richardson Message-ID: <1483809161.144962.1314763722334.JavaMail.root@mail05.pantherlink.uwm.edu> In-Reply-To: <18355.1314753104@marajade.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 04:07:15 -0000 Michael I understand your preference for GHC scheme. As for our scheme, it seems to me that you would like our scheme much better if there is a way for a node to solicit compressed/uncompressed DIOs. Is my understanding correct? This could be done by a simple DIS flag. Thanks Mukul ----- Original Message ----- From: "Michael Richardson" To: "roll WG" Sent: Tuesday, August 30, 2011 8:11:44 PM Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document >>>>> "Mukul" == Mukul Goyal writes: Mukul> Not sure how such concerns constitute an argument against Mukul> draft-goyal or in favor of your contention that every new Mukul> extension would require their compressed formats to be Mukul> defined. Compressed formats would be defined where they are Mukul> deemed useful. And, then what? Upgrade all the nodes in the building? >> 1) So, how does a sending node know that all of recipients know about the >> compression of the current options? Mukul> A compressed option has a different option type than its Mukul> regular version. By looking at the option type, a node would Mukul> know whether it is compressed or not. Great, so to be sure that everyone understands, I should send both? :-) Mukul> The sending node does not know. The recipient would ignore Mukul> the options it does not know about (or discard the whole Mukul> message itself as specified in the core spec). Mukul> I am not sure why the fact that nodes need to know about the Mukul> compressed objects/options in order to process them is being Mukul> used as an argument against this draft. RPL nodes would still Mukul> be able to talk core RPL among themselves irrespective of Mukul> whether they implement this draft or not. Their existing Mukul> functionality is not affected. We are concerned about flag days and incremental deployment of new features. These features *INCLUDE* deploying new compressed options. I agree with Ulrich: if we now know much better about what options are essential and which ones are not, then let's just revise the spec, and remove the uncompressed version. I don't want to write and test the code twice. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From angelo.castellani@gmail.com Wed Aug 31 01:49:48 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9DD21F8B37 for ; Wed, 31 Aug 2011 01:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGz27DdAoMi9 for ; Wed, 31 Aug 2011 01:49:47 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1905621F8B23 for ; Wed, 31 Aug 2011 01:49:46 -0700 (PDT) Received: by wyg8 with SMTP id 8so366227wyg.31 for ; Wed, 31 Aug 2011 01:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=sCT5arTIjsqe07oHtXfx6aPaSh1uYe8OCtXNak1AzqI=; b=ewU5U2f7xXEiULBeCMFuSB1ILgw46ckKiFaEr9nCIczBGR7z5AqD0JiAodxssE5tPV GWBKnomd++P0tVxChYBi2ol6uPFWRpqMty8YN8vdMfaTInnjyJBDKvDaEFDOkcak/aNY XAoin/8KZs6hxZidN/7cr1rhHUHuRXXvBz2o4= Received: by 10.216.210.231 with SMTP id u81mr178869weo.6.1314780676108; Wed, 31 Aug 2011 01:51:16 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.11.211 with HTTP; Wed, 31 Aug 2011 01:50:56 -0700 (PDT) In-Reply-To: <1341212383.144347.1314756475351.JavaMail.root@mail05.pantherlink.uwm.edu> References: <1341212383.144347.1314756475351.JavaMail.root@mail05.pantherlink.uwm.edu> From: "Angelo P. Castellani" Date: Wed, 31 Aug 2011 10:50:56 +0200 X-Google-Sender-Auth: pyPQs8tdgbHOJd7wfMukKpicfkc Message-ID: To: Mukul Goyal Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 08:49:48 -0000 On Wed, Aug 31, 2011 at 04:07, Mukul Goyal wrote: > The nodes would know because some body would configure that information i= n them. Suppose that LLN consists of some devices that understand compressi= on and others that dont. Suppose a global DAG is required. In such situatio= n, the simplest option would be to create two DAGs - one using compressed m= essages and the other using uncompressed ones. What is compression useful for in that scenario? Probably, at the end, you will save more energy using uncompressed RPL. > Another option would be to have some nodes transmit compressed DIOs and o= thers transmitting uncompressed ones. In this case also, either the dissemination will be less efficient for nodes understanding a single format, or you will transmit more packets and for this reason there is no convenience in having the compression at all. > Another option would be for a node to transmit uncompressed DIOs some tim= es and compressed ones at other times. And you will be either less efficient, or introduce redundancy (why compressing then?). > So, there are many ways to avoid the fate you are suggesting. Yes, but at the end of the day either you don't interoperate, or you are less efficient, or you produce more traffic using compression (!!). Energy-efficiency is probably obtained only if the whole network is compressing, and in this context I share the thought about pursuing it as a requirement given the fact that RPL targets LLNs. Best, Angelo From nicolas.dejean.ietf@googlemail.com Wed Aug 31 04:22:06 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B1F21F8AD9 for ; Wed, 31 Aug 2011 04:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHZY3tIyq9My for ; Wed, 31 Aug 2011 04:22:04 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id A7E4621F8ABC for ; Wed, 31 Aug 2011 04:22:04 -0700 (PDT) Received: by pzk33 with SMTP id 33so1973661pzk.18 for ; Wed, 31 Aug 2011 04:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Qp2EvbP+mCutthi8yFbg+0s1RQIB2cSEjK7tiN+V84s=; b=O6MKwv3Avd9naViCNvf9ioIXuV+KaX9P1K2I5RuTKQGpdQzAtyaL85/ZeO2/8Jwmbn 7oALcJ8dPnpdWLdTZVBGl8rhzCzyfu7X4srfo94pj69jyWDIWkZHUwyat51DP0ijkLN/ lCnzgH1OD9ph8LMLfGZds0KXEGQS8MlXOSCec= MIME-Version: 1.0 Received: by 10.68.122.163 with SMTP id lt3mr418024pbb.68.1314789811986; Wed, 31 Aug 2011 04:23:31 -0700 (PDT) Received: by 10.68.44.103 with HTTP; Wed, 31 Aug 2011 04:23:31 -0700 (PDT) In-Reply-To: <0368F388C03BB34BBBFA73209849D47A4CBF4F90@ITR-EXMBXVS-2.itron.com> References: <0368F388C03BB34BBBFA73209849D47A4CBF4F90@ITR-EXMBXVS-2.itron.com> Date: Wed, 31 Aug 2011 13:23:31 +0200 Message-ID: From: Nicolas DEJEAN To: "Akyol, Bora A" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "roll@ietf.org" Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 11:22:06 -0000 Hello Bora, Did Jorjeta answered your concerns about an AMI network considered as a backhaul for Gas and Water? Thank you in advance, Nicolas. 2011/8/30 Jetcheva, Jorjeta : > Hello Bora, > >> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >> backhaul were considered out of scope. > > Actually AMI backhaul for gas and water meters is very much in scope as p= er the NIST Wireless Guidelines (PAP2) work and the related SG-Communicatio= ns/SG-Net work. =A0CSWG coordinates with the PAPs so they should be aware o= f this. > > Jorjeta > > Jorjeta Jetcheva, Ph.D. > Principal Engineer, Architecture & Standards > CTO Office > Itron, Inc. > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of A= kyol, Bora A > Sent: Tuesday, August 30, 2011 10:37 AM > To: Nicolas DEJEAN > Cc: roll@ietf.org > Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt > > Hi Nicolas > > Thank you for your response. > > Please see my comments within > -- > Bora Akyol, Pacific Northwest National Laboratory > +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov > > > > > On 8/30/11 1:25 AM, "Nicolas DEJEAN" > wrote: > >>Hello Bora, >> >>2011/7/29 Akyol, Bora A : >>> I think the statement about AMI networks being used as an almost genera= l >>> purpose backhaul network for all other devices >>> is overreaching. I know there are some utilities that are looking into >>> this, but a lot more that have shied away from >>> this vision. Secondly, there are a lot more AMI deployments not using >>> wireless mesh networks, e.g. using cellular modem, >>> powerline carrier, etc. >> >>I agree that all utilities are not looking into it. >>However this is one possible case that should be considered, isn't it? >>Could you please precise what you are expecting to be in the draft? > > I think the draft should be focusing on the applicability of ROLL from a > technical front > without siting this one case as the only justification. > >> >>> >>> Is it possible to tone this "marketing" text Section 1.1. down and also >>> potentially >>> remove Gas & Water meters from the scope of this document. >>> >> >>On our point of view, Gas and Water metering are part of AMI. > > This is not the widely-held view at least within the US electric utility > community. > The gas and water meters have capabilities which are quite different from > electric power meters. > For example, while the electric meter has easy access to mains power, the > gas/water meters don't. > In most instances, the gas/water service may be provided by a completely > different entity than the electric > power utility. > > At least within the US NIST SGIP CSWG, the gas/water meters and AMI > backhaul were considered out of scope. > > Would the document lose technical integrity if the gas/water meter were > either removed or included as an optional. > > Regards > > > >>Could you please elaborate? >>According to you, why should Gas and Water be removed from the draft? >> >>Thank you in advance, >> >>Nicolas. >> >>> Regards >>> >>> -- >>> Bora Akyol, Pacific Northwest National Laboratory >>> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>> >>> _______________________________________________ >>> 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 trakadasp@yahoo.gr Wed Aug 31 05:24:36 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9304521F8B14 for ; Wed, 31 Aug 2011 05:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.368 X-Spam-Level: X-Spam-Status: No, score=-0.368 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9or6NNmMs6fK for ; Wed, 31 Aug 2011 05:24:35 -0700 (PDT) Received: from nm7.bullet.mail.ird.yahoo.com (nm7.bullet.mail.ird.yahoo.com [77.238.189.21]) by ietfa.amsl.com (Postfix) with SMTP id 7A1CE21F8AFF for ; Wed, 31 Aug 2011 05:24:35 -0700 (PDT) Received: from [77.238.189.55] by nm7.bullet.mail.ird.yahoo.com with NNFMP; 31 Aug 2011 12:26:04 -0000 Received: from [212.82.108.118] by tm8.bullet.mail.ird.yahoo.com with NNFMP; 31 Aug 2011 12:26:04 -0000 Received: from [127.0.0.1] by omp1027.mail.ird.yahoo.com with NNFMP; 31 Aug 2011 12:26:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 463376.95747.bm@omp1027.mail.ird.yahoo.com Received: (qmail 2593 invoked by uid 60001); 31 Aug 2011 12:26:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.gr; s=s1024; t=1314793564; bh=5Gx3/Es8j5IBe330eMFjzaaFkdGsmA/Wpipad2dkCtk=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=g5MMOdOKkWJmdByOnpe/6DBW3JHImHZi6le6OtmifXO3tBjZuslDwrR5nadyfNdKYPLZ9AHGz3kBN7Bggp1p7uIMDGJOZWO2lsGcFPBaHG5WZpC8NQBUA4EfwKIcJSop4uRvamZZnwG87TBhkA6bmmV7mpQ4+heAE970NoRDThU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.gr; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=Uej0eZSFgB+Rv8QR+G2IoFUe9bZ38Hdl6AcOzGQiCWB8KGCh4IQzDcqpl95NZ3B7eXiuIz/d/ESj6dyN+H9pIfqmu5+ZZ7YLZzP0ieBnGSEueYKbP88X5pddDvPt12nimunJbMIPbUN3rMkwoNlY8l0ByyQULSQ9LcCc9P2r4sY=; X-YMail-OSG: mQBSPqUVM1lTNTg7T_grEicyxJ1G.4IPZ7boF8Z19AlQwEI vgH_fbY2RCDJcRrNjjalh1AcWmoKRiJA7a0SyByhE2.qpQdn0c8RVLW3Gsue 9CWtWe4WZvxJ9kd_4s39E7RWgCC_hajrITUB7zj6sJqIVtw4sWHtbr4XWg5R JZ8w8szqR1Axz21q63TYq7M3Ps.oRv2BGBrc1DCzx.dUlyyXpr1JTsHNdftv b3LzfikIfJhpzmsz3PpIEuj7gleaXINlJsfHI4vviu0X_KyN9m0IWdcEQQUA N9zo5dy6wLeyOYNjxmRabu3fnrD84xOITvYqLRWKSr5D6PwcrpFpRdiOTg6Z yieEUPY.l6wdhs6x.coMtUkn9vONx3o1EJh7W4VEmMhuTyQ-- Received: from [83.235.46.66] by web29614.mail.ird.yahoo.com via HTTP; Wed, 31 Aug 2011 13:26:03 BST X-Mailer: YahooMailClassic/14.0.5 YahooMailWebService/0.8.113.315625 Message-ID: <1314793563.2265.YahooMailClassic@web29614.mail.ird.yahoo.com> Date: Wed, 31 Aug 2011 13:26:03 +0100 (BST) From: Panos Trakadas To: roll@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-39434045-1314793563=:2265" Subject: [Roll] New version of draft-zahariadis-ietf-roll-metrics-composition X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 12:24:36 -0000 --0-39434045-1314793563=:2265 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear all, Taking into consideration the comments from ROLL WG, Theodore Zahariadis an= d myself updated the document titled "Design Guidelines for Routing Metrics= Composition in LLN". More specifically: 1. We added a number of explanatory (and interesting) examples, =0Aas Pasca= l and Cedric asked. 2. Editorial changes (sections reordering, typos, etc) in order to improve = readability of the document, 3. Figure 1 has been modified, according to =0ACedric comments. We would appreciate your comments, Best Regards, Panos Trakadas. --0-39434045-1314793563=:2265 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Dear all,

Taking into consideration th= e comments from ROLL WG, Theodore Zahariadis and myself updated the documen= t titled "Design Guidelines for Routing Metrics Composition in LLN".
Mor= e specifically:
1. We added a number of explanatory (and interesting) ex= amples, =0Aas Pascal and Cedric asked.
2. Editorial changes (sections re= ordering, typos, etc) in order to improve readability of the document,
3= . Figure 1 has been modified, according to =0ACedric comments.

We wo= uld appreciate your comments,
Best Regards,
Panos Trakadas.

--0-39434045-1314793563=:2265-- From jpv@cisco.com Wed Aug 31 05:53:54 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A07221F8B30 for ; Wed, 31 Aug 2011 05:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.926 X-Spam-Level: X-Spam-Status: No, score=-108.926 tagged_above=-999 required=5 tests=[AWL=1.672, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id borDGTe70j0O for ; Wed, 31 Aug 2011 05:53:53 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id D885121F8B28 for ; Wed, 31 Aug 2011 05:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=3435; q=dns/txt; s=iport; t=1314795323; x=1316004923; h=from:mime-version:subject:date:references:cc:to: message-id; bh=4DDKBvP8JmkczSLPgBS+KOsFcVWchuyq28Z+QQ3w4kg=; b=OIbPkrVNQJhTi2mEHAJqdMu483s8RMF4bUIZaLgaD6vWUV/PgpDaSvMC IWiu/nZjWKVXE3sr3FveaSptm29NtleGLwAV/Ee/06PqlpDUp/+UMmS/5 yT9DKJWZQMQfS04NvTT1qVqIsxvQPRNwCUR3kFbNheninBS9vqQAzYmz8 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACIuXk5Io8UQ/2dsb2JhbABDqEh3gUABAQEBAgEBAQEPAVsLBQsPDQMBAi8nJgIIBhMih1AEmX4Bn0KFdWAEkyWFDgmLcg X-IronPort-AV: E=Sophos;i="4.68,307,1312156800"; d="scan'208,217";a="52706799" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 31 Aug 2011 12:55:21 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7VCtLJN017970; Wed, 31 Aug 2011 12:55:21 GMT Received: from xfe-bgl-411.cisco.com ([72.163.129.199]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 31 Aug 2011 18:25:21 +0530 Received: from [10.60.114.226] ([10.60.114.226]) by xfe-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 31 Aug 2011 18:25:20 +0530 From: JP Vasseur Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_CFFF25FC-E94A-403F-8375-F141E84829F0" Date: Wed, 31 Aug 2011 14:55:18 +0200 References: <79860D3D-A86D-474B-BA0B-D4ADDC6977D9@cisco.com> To: roll WG Message-Id: <683511D7-32EE-49F1-AA67-C8599C8775BA@cisco.com> X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 31 Aug 2011 12:55:20.0838 (UTC) FILETIME=[3DC0CA60:01CC67DD] Subject: [Roll] Fwd: PLEASE Comment on draft-alexander-roll-mikey-lln-key-mgmt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 12:53:54 -0000 --Apple-Mail=_CFFF25FC-E94A-403F-8375-F141E84829F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Any comment ? Thanks. JP. Begin forwarded message: > From: JP Vasseur > Subject: [Roll] PLEASE Comment on = draft-alexander-roll-mikey-lln-key-mgmt > Date: August 26, 2011 9:17:42 AM GMT+02:00 > To: roll WG >=20 > Dear all, >=20 > Several of you expressed some interest in = draft-alexander-roll-mikey-lln-key-mgmt. That said, could you > please comment on this I-D as soon as possible ? We need a key = management protocol and if it turns > out that the WG wants to adopt this ID, I'll poll the WG to make it a = WG =85 Please comment. >=20 > Thanks. >=20 > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail=_CFFF25FC-E94A-403F-8375-F141E84829F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Any = comment = ?

Thanks.

JP.

Begin forwarded message:

From: JP Vasseur <jpv@cisco.com>
Subject: = [Roll] PLEASE Comment on = draft-alexander-roll-mikey-lln-key-mgmt
Date: August 26, 2011 = 9:17:42 AM GMT+02:00
To: roll WG <roll@ietf.org>

Dear all,

Several of you expressed some interest in = draft-alexander-roll-mikey-lln-key-mgmt. That said, could you
please = comment on this I-D as soon as possible ? We need a key management = protocol and if it turns
out that the WG wants to adopt this ID, I'll = poll the WG to make it a WG =85 Please = comment.

Thanks.

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

= --Apple-Mail=_CFFF25FC-E94A-403F-8375-F141E84829F0-- From mcr@sandelman.ca Wed Aug 31 06:33:59 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A2C21F8B28 for ; Wed, 31 Aug 2011 06:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRGO9sRoB4Z6 for ; Wed, 31 Aug 2011 06:33:59 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFCD21F8A4B for ; Wed, 31 Aug 2011 06:33:59 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 605C2342C4 for ; Wed, 31 Aug 2011 09:34:40 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id B63A798C6E for ; Wed, 31 Aug 2011 09:35:49 -0400 (EDT) From: Michael Richardson To: roll WG In-Reply-To: <1341212383.144347.1314756475351.JavaMail.root@mail05.pantherlink.uwm.edu> References: <1341212383.144347.1314756475351.JavaMail.root@mail05.pantherlink.uwm.edu> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 31 Aug 2011 09:35:49 -0400 Message-ID: <4503.1314797749@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 13:33:59 -0000 --=-=-= >>>>> "Mukulu" == Mukul Goyal writes: >> 1. Why would a node transmit only compressed DIOs when it expects >> its listeners to include those that do not understand >> >compression? >> How would it know what its listeners expect? If there is a chance >> that any of the nodes in the network does not understand >> >compression (which none of the other nodes would know), the >> nodes in the network either all use uncompressed messages or >> deprive >that node from communicating. Mukulu> The nodes would know because some body would configure that Mukulu> information in them. Suppose that LLN consists of some Manual configuration is being invoked too often in ROLL. How does this deal with upgrades? Mukulu> devices that understand compression and others that Mukulu> dont. Suppose a global DAG is required. In such situation, Mukulu> the simplest option would be to create two DAGs - one using Let's go back. What's the purpose of compression? It's so that one can transmit only a single frame, rather than two, which halves the power consumption, and massively reduces impact of lost frames. (If ether frame of a fragment is lost, the entire packet is lost). So, creating two DAGs defeats all of this: you have to transmit a minimum of three frames now. One might as well have left out the compressed DAG. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATl44tYCLcPvd0N1lAQIi9Af+MU0efokU43JFPpcdb2UqxC3zCndKXEP8 7YOkWxqWv0/NI+1X7lEudo/9cjY+tu0XmtLW+wqH/FK6QiqqDi4Qo3DVbpWO6+br ev2zYVKxfYt4MpnsKo/brxlABPil+oqIq7y4AXGZgSJ20F8SBj0VZyzVw0eLtCp9 xUVgE3Jxa8Taq6ncRA0D+oHGlVEwVq9tMcYy5rXWZ4YOWP2cPZ9qXeTLIaNthygw MmqWqYWVUc1sDtyTqTQjZMeqS+KGxYPX3xA3kDw6LVyhugZYvY6QA8M1/Eq1xtDc tCgUWnGiAPy1XezW3p/bj5yENubAdMtwTSM2NKVAJKpttIWfrSRr2w== =7eDC -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Wed Aug 31 06:36:32 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2C221F8562 for ; Wed, 31 Aug 2011 06:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.571 X-Spam-Level: X-Spam-Status: No, score=-1.571 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYpzSx1v7f05 for ; Wed, 31 Aug 2011 06:36:31 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6D721F84E7 for ; Wed, 31 Aug 2011 06:36:31 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 64FFDA0067; Wed, 31 Aug 2011 09:37:22 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 7D78198C6E; Wed, 31 Aug 2011 09:38:32 -0400 (EDT) From: Michael Richardson To: Mukul Goyal In-Reply-To: <1483809161.144962.1314763722334.JavaMail.root@mail05.pantherlink.uwm.edu> References: <1483809161.144962.1314763722334.JavaMail.root@mail05.pantherlink.uwm.edu> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 31 Aug 2011 09:38:32 -0400 Message-ID: <4884.1314797912@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 13:36:32 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Mukul" =3D=3D Mukul Goyal writes: Mukul> I understand your preference for GHC scheme. As for our Mukul> scheme, it seems to me that you would like our scheme much Mukul> better if there is a way for a node to solicit Mukul> compressed/uncompressed DIOs. Is my understanding correct?=20 Mukul> This could be done by a simple DIS flag. No, I wouldn't like that. I'd like not to have to write and test two parsers for options, and I'd like the scheme not to fall apart when we introduce another option type. I will evaluate GHC method, and write a draft this long weekend with my results. If anyone has sample RPL messages they want me to consider,=20 I would appreciate a PCAP file, otherwise, I'll evaluate only my own. In particular, I need more examples of metric options. --=-=-= Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Description: Signature =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-=-- --==-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATl45WICLcPvd0N1lAQIRlAf/YP37oqMAmXElKLvlLGfs8vIoUE1WT1JL YegUcf3W19vWeiCqXTt627ydfI6Nn5Pmk4Tl48+XDdiAqwORNLnp7BW+OZIoVMOQ LhNZ79Sr6FWqbYRr3D/8OobVy2K9xSAnIMDW1pK8lXHislC7JCkPQLaK8FNcYLPA aSN57fZED0fV3Jb+KqI5Fv6HAp3ETUbc2DUY3w+T7ukag3xFoPfCtKZgk6DZbQZF 4lUXTtzmMUk/2ppOXoxiqcc0Xb5nLBNq3c1s6c9IwtglOegoir7+sTu2CcekMT3H DmMoCFfCBKgGIKLEDg5Pmi/4o2j4X4PVIt54iEyPjic95EoOWCLiNQ== =CX0T -----END PGP SIGNATURE----- --==-=-=-- From prvs=217dc3b4d=mukul@uwm.edu Wed Aug 31 06:50:06 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2E821F8B8F for ; Wed, 31 Aug 2011 06:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.406 X-Spam-Level: X-Spam-Status: No, score=-3.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plJJ37PLMova for ; Wed, 31 Aug 2011 06:50:06 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCA521F8B8E for ; Wed, 31 Aug 2011 06:50:06 -0700 (PDT) Received: from localhost (HELO mta01.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 31 Aug 2011 08:50:44 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 04BD7E6A76; Wed, 31 Aug 2011 08:51:36 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7ri6ghOFGZD; Wed, 31 Aug 2011 08:51:35 -0500 (CDT) Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 93A95E6A7B; Wed, 31 Aug 2011 08:51:35 -0500 (CDT) Date: Wed, 31 Aug 2011 08:51:35 -0500 (CDT) From: Mukul Goyal To: Michael Richardson Message-ID: <334091358.146823.1314798695502.JavaMail.root@mail05.pantherlink.uwm.edu> In-Reply-To: <4884.1314797912@marajade.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 13:50:07 -0000 >I'd like the scheme not to fall apart when we introduce another option type. This is the part that I dont understand. Why does our scheme fall apart when a new option is introduced? Mukul ----- Original Message ----- From: "Michael Richardson" To: "Mukul Goyal" Cc: "roll WG" Sent: Wednesday, August 31, 2011 8:38:32 AM Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document >>>>> "Mukul" == Mukul Goyal writes: Mukul> I understand your preference for GHC scheme. As for our Mukul> scheme, it seems to me that you would like our scheme much Mukul> better if there is a way for a node to solicit Mukul> compressed/uncompressed DIOs. Is my understanding correct? Mukul> This could be done by a simple DIS flag. No, I wouldn't like that. I'd like not to have to write and test two parsers for options, and I'd like the scheme not to fall apart when we introduce another option type. I will evaluate GHC method, and write a draft this long weekend with my results. If anyone has sample RPL messages they want me to consider, I would appreciate a PCAP file, otherwise, I'll evaluate only my own. In particular, I need more examples of metric options. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From prvs=21736f1ad=bora@pnnl.gov Wed Aug 31 08:07:44 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927ED21F8C3E for ; Wed, 31 Aug 2011 08:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53aEhy+GscUe for ; Wed, 31 Aug 2011 08:07:43 -0700 (PDT) Received: from emailgw03.pnl.gov (emailgw03.pnl.gov [192.101.109.31]) by ietfa.amsl.com (Postfix) with ESMTP id 8571721F8C3D for ; Wed, 31 Aug 2011 08:07:43 -0700 (PDT) Received: from emailhub02.pnl.gov ([130.20.251.62]) by emailgw03.pnl.gov with ESMTP/TLS/AES128-SHA; 31 Aug 2011 08:09:12 -0700 Received: from Email05.pnl.gov ([130.20.251.70]) by emailhub02.pnl.gov ([130.20.251.62]) with mapi; Wed, 31 Aug 2011 08:08:52 -0700 From: "Akyol, Bora A" To: Nicolas DEJEAN Date: Wed, 31 Aug 2011 08:09:10 -0700 Thread-Topic: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Thread-Index: Acxn7/CjOvoA2I0MSE2h62drRPq3nA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 15:07:44 -0000 Hi Nicolas Yes, we had a private email exchange off-list. I would like to suggest alternate wording for this paragraph as follows: ORIGINAL: Electric meters are often interconnected into multi-hop mesh networks, each of which is connected to a backhaul network leading to the utility network through a network aggregation point (NAP). These kinds of networks increase coverage and reduce installation cost, time and complexity, as well as operational costs, as compared to single-hop wireless networks, relying on a wireline or cellular backhaul. Each electric meter mesh typically has on the order of several thousand wireless endpoints, with densities varying based on the area and the terrain. Apartment buildings in urban centers may have hundreds of meters in close proximity, whereas rural areas may have sparse node distributions and include nodes that only have one or two network neighbors. Paths in the mesh between a network device and the nearest aggregation point may be composed of several hops or even tens of hops. ALTERNATE WORDING: In one type of AMI network, electric meters are interconnected into multi-hop mesh networks, each of which is connected to a backhaul network leading to the utility network through a network aggregation point (NAP). In a multi-hop mesh network, each electric meter mesh may have up to several thousand wireless endpoints, with densities varying based on the area and the terrain. Apartment buildings in urban centers may have hundreds of meters in close proximity, whereas rural areas may have sparse node distributions and include nodes that only have one or two network neighbors.=20 Paths in the mesh between a network device and the nearest aggregation point may be composed of several hops or even tens of hops. What do you think? Thanks --=20 Bora Akyol, Pacific Northwest National Laboratory +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov On 8/31/11 4:23 AM, "Nicolas DEJEAN" wrote: >Hello Bora, > >Did Jorjeta answered your concerns about an AMI network considered as >a backhaul for Gas and Water? > >Thank you in advance, > >Nicolas. > >2011/8/30 Jetcheva, Jorjeta : >> Hello Bora, >> >>> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >>> backhaul were considered out of scope. >> >> Actually AMI backhaul for gas and water meters is very much in scope as >>per the NIST Wireless Guidelines (PAP2) work and the related >>SG-Communications/SG-Net work. CSWG coordinates with the PAPs so they >>should be aware of this. >> >> Jorjeta >> >> Jorjeta Jetcheva, Ph.D. >> Principal Engineer, Architecture & Standards >> CTO Office >> Itron, Inc. >> >> >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >>Akyol, Bora A >> Sent: Tuesday, August 30, 2011 10:37 AM >> To: Nicolas DEJEAN >> Cc: roll@ietf.org >> Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt >> >> Hi Nicolas >> >> Thank you for your response. >> >> Please see my comments within >> -- >> Bora Akyol, Pacific Northwest National Laboratory >> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >> >> >> >> >> On 8/30/11 1:25 AM, "Nicolas DEJEAN" >> >> wrote: >> >>>Hello Bora, >>> >>>2011/7/29 Akyol, Bora A : >>>> I think the statement about AMI networks being used as an almost >>>>general >>>> purpose backhaul network for all other devices >>>> is overreaching. I know there are some utilities that are looking into >>>> this, but a lot more that have shied away from >>>> this vision. Secondly, there are a lot more AMI deployments not using >>>> wireless mesh networks, e.g. using cellular modem, >>>> powerline carrier, etc. >>> >>>I agree that all utilities are not looking into it. >>>However this is one possible case that should be considered, isn't it? >>>Could you please precise what you are expecting to be in the draft? >> >> I think the draft should be focusing on the applicability of ROLL from a >> technical front >> without siting this one case as the only justification. >> >>> >>>> >>>> Is it possible to tone this "marketing" text Section 1.1. down and >>>>also >>>> potentially >>>> remove Gas & Water meters from the scope of this document. >>>> >>> >>>On our point of view, Gas and Water metering are part of AMI. >> >> This is not the widely-held view at least within the US electric utility >> community. >> The gas and water meters have capabilities which are quite different >>from >> electric power meters. >> For example, while the electric meter has easy access to mains power, >>the >> gas/water meters don't. >> In most instances, the gas/water service may be provided by a completely >> different entity than the electric >> power utility. >> >> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >> backhaul were considered out of scope. >> >> Would the document lose technical integrity if the gas/water meter were >> either removed or included as an optional. >> >> Regards >> >> >> >>>Could you please elaborate? >>>According to you, why should Gas and Water be removed from the draft? >>> >>>Thank you in advance, >>> >>>Nicolas. >>> >>>> Regards >>>> >>>> -- >>>> Bora Akyol, Pacific Northwest National Laboratory >>>> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>>> >>>> _______________________________________________ >>>> 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 Jorjeta.Jetcheva@itron.com Wed Aug 31 08:33:21 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B511A21F8BAA for ; Wed, 31 Aug 2011 08:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cz-ATgKNVc5t for ; Wed, 31 Aug 2011 08:33:20 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.115]) by ietfa.amsl.com (Postfix) with ESMTP id AAE5121F8B4C for ; Wed, 31 Aug 2011 08:33:20 -0700 (PDT) Received: from ITR-EXMBXVS-2.itron.com ([192.168.9.111]) by spo-exchcn-1.itron.com ([192.168.9.115]) with mapi; Wed, 31 Aug 2011 08:34:46 -0700 From: "Jetcheva, Jorjeta" To: "Akyol, Bora A" Date: Wed, 31 Aug 2011 08:34:43 -0700 Thread-Topic: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Thread-Index: Acxn7/CjOvoA2I0MSE2h62drRPq3nAAAn1vw Message-ID: <0368F388C03BB34BBBFA73209849D47A4CC59F57@ITR-EXMBXVS-2.itron.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: D?jean Nicolas , "roll@ietf.org" Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 15:33:21 -0000 Hello Bora, The paragraph you cited does not reference anything related to water or gas= meters which was the topic of your earlier comment and the discussion that= followed. Is this perhaps not the right paragraph or is this the beginnin= g of a new discussion? As far as the benefits of multi-hop networks over wireline or cellular back= haul, I think that lower cost and deployment complexity are pretty commonly= cited. Do you disagree with this statement? Thanks, Jorjeta Jorjeta Jetcheva, Ph.D. Principal Engineer, Architecture & Standards CTO Office Itron, Inc. -----Original Message----- From: Akyol, Bora A [mailto:bora@pnnl.gov]=20 Sent: Wednesday, August 31, 2011 8:09 AM To: Nicolas DEJEAN Cc: Jetcheva, Jorjeta; roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Hi Nicolas Yes, we had a private email exchange off-list. I would like to suggest alternate wording for this paragraph as follows: ORIGINAL: Electric meters are often interconnected into multi-hop mesh networks, each of which is connected to a backhaul network leading to the utility network through a network aggregation point (NAP). These kinds of networks increase coverage and reduce installation cost, time and complexity, as well as operational costs, as compared to single-hop wireless networks, relying on a wireline or cellular backhaul. Each electric meter mesh typically has on the order of several thousand wireless endpoints, with densities varying based on the area and the terrain. Apartment buildings in urban centers may have hundreds of meters in close proximity, whereas rural areas may have sparse node distributions and include nodes that only have one or two network neighbors. Paths in the mesh between a network device and the nearest aggregation point may be composed of several hops or even tens of hops. ALTERNATE WORDING: In one type of AMI network, electric meters are interconnected into multi-hop mesh networks, each of which is connected to a backhaul network leading to the utility network through a network aggregation point (NAP). In a multi-hop mesh network, each electric meter mesh may have up to several thousand wireless endpoints, with densities varying based on the area and the terrain. Apartment buildings in urban centers may have hundreds of meters in close proximity, whereas rural areas may have sparse node distributions and include nodes that only have one or two network neighbors.=20 Paths in the mesh between a network device and the nearest aggregation point may be composed of several hops or even tens of hops. What do you think? Thanks --=20 Bora Akyol, Pacific Northwest National Laboratory +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov On 8/31/11 4:23 AM, "Nicolas DEJEAN" wrote: >Hello Bora, > >Did Jorjeta answered your concerns about an AMI network considered as >a backhaul for Gas and Water? > >Thank you in advance, > >Nicolas. > >2011/8/30 Jetcheva, Jorjeta : >> Hello Bora, >> >>> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >>> backhaul were considered out of scope. >> >> Actually AMI backhaul for gas and water meters is very much in scope as >>per the NIST Wireless Guidelines (PAP2) work and the related >>SG-Communications/SG-Net work. CSWG coordinates with the PAPs so they >>should be aware of this. >> >> Jorjeta >> >> Jorjeta Jetcheva, Ph.D. >> Principal Engineer, Architecture & Standards >> CTO Office >> Itron, Inc. >> >> >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >>Akyol, Bora A >> Sent: Tuesday, August 30, 2011 10:37 AM >> To: Nicolas DEJEAN >> Cc: roll@ietf.org >> Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt >> >> Hi Nicolas >> >> Thank you for your response. >> >> Please see my comments within >> -- >> Bora Akyol, Pacific Northwest National Laboratory >> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >> >> >> >> >> On 8/30/11 1:25 AM, "Nicolas DEJEAN" >> >> wrote: >> >>>Hello Bora, >>> >>>2011/7/29 Akyol, Bora A : >>>> I think the statement about AMI networks being used as an almost >>>>general >>>> purpose backhaul network for all other devices >>>> is overreaching. I know there are some utilities that are looking into >>>> this, but a lot more that have shied away from >>>> this vision. Secondly, there are a lot more AMI deployments not using >>>> wireless mesh networks, e.g. using cellular modem, >>>> powerline carrier, etc. >>> >>>I agree that all utilities are not looking into it. >>>However this is one possible case that should be considered, isn't it? >>>Could you please precise what you are expecting to be in the draft? >> >> I think the draft should be focusing on the applicability of ROLL from a >> technical front >> without siting this one case as the only justification. >> >>> >>>> >>>> Is it possible to tone this "marketing" text Section 1.1. down and >>>>also >>>> potentially >>>> remove Gas & Water meters from the scope of this document. >>>> >>> >>>On our point of view, Gas and Water metering are part of AMI. >> >> This is not the widely-held view at least within the US electric utility >> community. >> The gas and water meters have capabilities which are quite different >>from >> electric power meters. >> For example, while the electric meter has easy access to mains power, >>the >> gas/water meters don't. >> In most instances, the gas/water service may be provided by a completely >> different entity than the electric >> power utility. >> >> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >> backhaul were considered out of scope. >> >> Would the document lose technical integrity if the gas/water meter were >> either removed or included as an optional. >> >> Regards >> >> >> >>>Could you please elaborate? >>>According to you, why should Gas and Water be removed from the draft? >>> >>>Thank you in advance, >>> >>>Nicolas. >>> >>>> Regards >>>> >>>> -- >>>> Bora Akyol, Pacific Northwest National Laboratory >>>> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>>> >>>> _______________________________________________ >>>> 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 prvs=21736f1ad=bora@pnnl.gov Wed Aug 31 08:38:35 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982CD21F8BA9 for ; Wed, 31 Aug 2011 08:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiNzWJ1IEzJk for ; Wed, 31 Aug 2011 08:38:34 -0700 (PDT) Received: from emailgw04.pnl.gov (emailgw04.pnl.gov [192.101.109.35]) by ietfa.amsl.com (Postfix) with ESMTP id 96F3521F8B70 for ; Wed, 31 Aug 2011 08:38:34 -0700 (PDT) Received: from emailhub02.pnl.gov ([130.20.251.62]) by emailgw04.pnl.gov with ESMTP/TLS/AES128-SHA; 31 Aug 2011 08:40:03 -0700 Received: from Email05.pnl.gov ([130.20.251.70]) by emailhub02.pnl.gov ([130.20.251.62]) with mapi; Wed, 31 Aug 2011 08:39:43 -0700 From: "Akyol, Bora A" To: "'Jetcheva, Jorjeta'" Date: Wed, 31 Aug 2011 08:40:03 -0700 Thread-Topic: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Thread-Index: Acxn7/CjOvoA2I0MSE2h62drRPq3nAAAn1vwAABLMsA= Message-ID: References: <0368F388C03BB34BBBFA73209849D47A4CC59F57@ITR-EXMBXVS-2.itron.com> In-Reply-To: <0368F388C03BB34BBBFA73209849D47A4CC59F57@ITR-EXMBXVS-2.itron.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: D?jean Nicolas , "roll@ietf.org" Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 15:38:35 -0000 Hi Jorjeta Sorry, I had two comments in my original email. One was regarding gas/power= meters and the second regarding the non-technical slant in the introductio= n. The modified paragraph that I proposed is related to the second point. To answer your question, I disagree with the unbsubstantiated statement tha= t multi-hop wireless mesh networks have substantial cost benefits compared to either powerline or single-hop (e.g. cellular modems) networks.= =20 I am not saying this is completely wrong, I am saying that this statement d= oes not belong in an IETF document since it has no relevance to ROLL or the applicability of ROLL to AMI networks. I think the paragraph I propo= sed is clear-cut and technically accurate without having a bias towards the= use of wireless mesh networks. Regards Bora -----Original Message----- From: Jetcheva, Jorjeta [mailto:Jorjeta.Jetcheva@itron.com]=20 Sent: Wednesday, August 31, 2011 8:35 AM To: Akyol, Bora A Cc: D?jean Nicolas; roll@ietf.org Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Hello Bora, The paragraph you cited does not reference anything related to water or gas= meters which was the topic of your earlier comment and the discussion that= followed. Is this perhaps not the right paragraph or is this the beginnin= g of a new discussion? As far as the benefits of multi-hop networks over wireline or cellular back= haul, I think that lower cost and deployment complexity are pretty commonly= cited. Do you disagree with this statement? Thanks, Jorjeta Jorjeta Jetcheva, Ph.D. Principal Engineer, Architecture & Standards CTO Office Itron, Inc. -----Original Message----- From: Akyol, Bora A [mailto:bora@pnnl.gov] Sent: Wednesday, August 31, 2011 8:09 AM To: Nicolas DEJEAN Cc: Jetcheva, Jorjeta; roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Hi Nicolas Yes, we had a private email exchange off-list. I would like to suggest alternate wording for this paragraph as follows: ORIGINAL: Electric meters are often interconnected into multi-hop mesh networks, each of which is connected to a backhaul network leading to the utility network through a network aggregation point (NAP). These kinds of networks increase coverage and reduce installation cost, time and complexity, as well as operational costs, as compared to single-hop wireless networks, relying on a wireline or cellular backhaul. Each electric meter mesh typically has on the order of several thousand wireless endpoints, with densities varying based on the area and the terrain. Apartment buildings in urban centers may have hundreds of meters in close proximity, whereas rural areas may have sparse node distributions and include nodes that only have one or two network neighbors. Paths in the mesh between a network device and the nearest aggregation point may be composed of several hops or even tens of hops. ALTERNATE WORDING: In one type of AMI network, electric meters are interconnected into multi-hop mesh networks, each of which is connected to a backhaul network leading to the utility network through a network aggregation point (NAP). In a multi-hop mesh network, each electric meter mesh may have up to several thousand wireless endpoints, with densities varying based on the area and the terrain. Apartment buildings in urban centers may have hundreds of meters in close proximity, whereas rural areas may have sparse node distributions and include nodes that only have one or two network neighbors.=20 Paths in the mesh between a network device and the nearest aggregation point may be composed of several hops or even tens of hops. What do you think? Thanks --=20 Bora Akyol, Pacific Northwest National Laboratory +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov On 8/31/11 4:23 AM, "Nicolas DEJEAN" wrote: >Hello Bora, > >Did Jorjeta answered your concerns about an AMI network considered as >a backhaul for Gas and Water? > >Thank you in advance, > >Nicolas. > >2011/8/30 Jetcheva, Jorjeta : >> Hello Bora, >> >>> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >>> backhaul were considered out of scope. >> >> Actually AMI backhaul for gas and water meters is very much in scope as >>per the NIST Wireless Guidelines (PAP2) work and the related >>SG-Communications/SG-Net work. CSWG coordinates with the PAPs so they >>should be aware of this. >> >> Jorjeta >> >> Jorjeta Jetcheva, Ph.D. >> Principal Engineer, Architecture & Standards >> CTO Office >> Itron, Inc. >> >> >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >>Akyol, Bora A >> Sent: Tuesday, August 30, 2011 10:37 AM >> To: Nicolas DEJEAN >> Cc: roll@ietf.org >> Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt >> >> Hi Nicolas >> >> Thank you for your response. >> >> Please see my comments within >> -- >> Bora Akyol, Pacific Northwest National Laboratory >> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >> >> >> >> >> On 8/30/11 1:25 AM, "Nicolas DEJEAN" >> >> wrote: >> >>>Hello Bora, >>> >>>2011/7/29 Akyol, Bora A : >>>> I think the statement about AMI networks being used as an almost >>>>general >>>> purpose backhaul network for all other devices >>>> is overreaching. I know there are some utilities that are looking into >>>> this, but a lot more that have shied away from >>>> this vision. Secondly, there are a lot more AMI deployments not using >>>> wireless mesh networks, e.g. using cellular modem, >>>> powerline carrier, etc. >>> >>>I agree that all utilities are not looking into it. >>>However this is one possible case that should be considered, isn't it? >>>Could you please precise what you are expecting to be in the draft? >> >> I think the draft should be focusing on the applicability of ROLL from a >> technical front >> without siting this one case as the only justification. >> >>> >>>> >>>> Is it possible to tone this "marketing" text Section 1.1. down and >>>>also >>>> potentially >>>> remove Gas & Water meters from the scope of this document. >>>> >>> >>>On our point of view, Gas and Water metering are part of AMI. >> >> This is not the widely-held view at least within the US electric utility >> community. >> The gas and water meters have capabilities which are quite different >>from >> electric power meters. >> For example, while the electric meter has easy access to mains power, >>the >> gas/water meters don't. >> In most instances, the gas/water service may be provided by a completely >> different entity than the electric >> power utility. >> >> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >> backhaul were considered out of scope. >> >> Would the document lose technical integrity if the gas/water meter were >> either removed or included as an optional. >> >> Regards >> >> >> >>>Could you please elaborate? >>>According to you, why should Gas and Water be removed from the draft? >>> >>>Thank you in advance, >>> >>>Nicolas. >>> >>>> Regards >>>> >>>> -- >>>> Bora Akyol, Pacific Northwest National Laboratory >>>> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>>> >>>> _______________________________________________ >>>> 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 ietf@thomasclausen.org Wed Aug 31 08:52:58 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8AA21F8BCB for ; Wed, 31 Aug 2011 08:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muyz48ZkttSF for ; Wed, 31 Aug 2011 08:52:57 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id D578021F8CAD for ; Wed, 31 Aug 2011 08:52:56 -0700 (PDT) Received: from sphinx.lix.polytechnique.fr ([129.104.11.1] helo=[10.0.1.5]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Qyn7S-000P5G-GJ; Wed, 31 Aug 2011 15:54:26 +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: U2FsdGVkX18FfIC7infJUqQB8s6wbDvm Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Thomas Heide Clausen In-Reply-To: <111422722.142689.1314742699308.JavaMail.root@mail05.pantherlink.uwm.edu> Date: Wed, 31 Aug 2011 17:54:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5421FBA4-6617-4957-AEDC-A2AAF2143813@thomasclausen.org> References: <111422722.142689.1314742699308.JavaMail.root@mail05.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1244.3) Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 15:52:58 -0000 Dear Mukul, On Aug 31, 2011, at 00:18 , Mukul Goyal wrote: > Ulrich >=20 > 1. Why would a node transmit only compressed DIOs when it expects its = listeners to include those that do not understand compression?=20 >=20 > Your example seems similar to these: > a) A non-storing node not being able to join a storing mode DAG This was a thorny point during some discussions with the IESG. = Personally, I do not agree with the outcome of those discussions, as = documented in this specification, so I actually take the similarity to = storing/non-storing mode as a red flag as to why this should be avoided. We have "two RPL protocols" already, mutually non-interoperable: o Storing mode RPL o Non-storing mode RPL Adding a different message format will give us "four RPL protocols", = also mutually non-interoperable: o Storing mode stock-RPL o Non-storing mode stock-RPL o Storing mode alternative-message-format-RPL o Non-storing mode alternative-message-format-RPL Add a P2P/non-P2P axis, and we're up to "eight RPL protocols", also = mutually non-interoperable. If all devices in a network come from the same vendor with the same = firmware, and the network is never changed/reconfigured/extended, then = it might work OK. Then again, my big big worry here is the real world, in which a = deployment will end up with heterogenous equipment from different = vendors. This sounds like a royal configuration nightmare to get right. Avoiding this should really be the _main_ design requirement that the WG = should have been working towards. Respectfully yours, Thomas > b) A node that does not understand RPL security can't join a DAG using = secure messages. >=20 > 2. Assuming that the scenario you described is plausible, a simple DIS = flag/option can be defined to solve the problem trivially. But ofcourse = you would then complain about additional complexity. >=20 > Thanks > Mukul >=20 > ----- Original Message ----- > From: "Ulrich Herberg" > To: "Mukul Goyal" > Cc: "roll WG" > Sent: Tuesday, August 30, 2011 3:20:21 PM > Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a = new ROLL WG document >=20 > Let me give an example: a node, "speaking" only uncompressed RPL = messages, joins the network. It needs to get the DODAG Configuration = Option. Now the other nodes (inclusive the root node) use the compressed = RPL messages. How can the new node get the required information then?=20 >=20 > Similarly, what happens if that "classic" RPL node receives a = compressed DIO message? Yes, the message has a different code, and thus = would not be parsed by the node. Therefore, this node is excluded from = network operation.=20 >=20 > I would also like to repeat my question I raised during the ROLL = meeting: If we know now how to compress messages much better, why don't = we update the RPL specification, instead of adding new message / option = types in additional drafts?=20 >=20 > Ulrich=20 >=20 >=20 > On Tue, Aug 30, 2011 at 1:09 PM, Mukul Goyal < mukul@uwm.edu > wrote:=20= >=20 >=20 > Please realize that the compressed objects have different code values = than regular objects. Hence there is no danger of lack of = interoperability.=20 >=20 > Thanks=20 > Mukul=20 >=20 >=20 >=20 >=20 > ----- Original Message -----=20 > From: "Mukul Goyal" < mukul@uwm.edu >=20 > To: "Ulrich Herberg" < ulrich@herberg.name >=20 > Cc: "roll WG" < roll@ietf.org >=20 > Sent: Tuesday, August 30, 2011 3:06:43 PM=20 > Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a = new ROLL WG document=20 >=20 > By the same logic, you would argue that P2P-RPL would lead to = non-interoperable implementations since some devices would speak P2P-RPL = and others wont.=20 >=20 > Thanks=20 > Mukul=20 >=20 > ----- Original Message -----=20 > From: "Ulrich Herberg" < ulrich@herberg.name >=20 > To: "Michael Richardson" < mcr@sandelman.ca >=20 > Cc: "Mukul Goyal" < mukul@uwm.edu >, "roll WG" < roll@ietf.org >=20 > Sent: Tuesday, August 30, 2011 2:58:21 PM=20 > Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a = new ROLL WG document=20 >=20 > I agree with Michael's concern that using GRRC could lead to = non-interoperable implementations, with some nodes "speaking" normal = RPL, some using GRRC. That might require some additional negotiation = between nodes, or worse, could lead to non-interoperable parts of the = network. That worries me.=20 >=20 > Ulrich=20 >=20 >=20 > On Tue, Aug 30, 2011 at 12:53 PM, Michael Richardson < = mcr@sandelman.ca > wrote:=20 >=20 >=20 >=20 >>>>>> "Mukul" =3D=3D Mukul Goyal < mukul@uwm.edu > writes:=20 > Mukul> I was wondering if you have the compression scheme described=20= > Mukul> in draft-bormann-6lowpan-ghc in mind. I guess it will be=20 > Mukul> useful to compare the compression achieved using the two=20 > Mukul> schemes for the two examples described in=20 > Mukul> draft-goyal-roll-rpl-compression. I think that compression=20= > Mukul> achieved with draft-bormann scheme would vary with the = actual=20 > Mukul> byte stream contained in the packet. There is ofcourse no=20 > Mukul> such dependency in case of our scheme.=20 >=20 > yes, but the goyal-roll-rpl-compression (GRRC from now on, okay?) = scheme=20 > will result in devices that support the compressed format only,=20 > essentially creating an entirely new protocol.=20 >=20 > 6lowpan-ghc applies things as a layered approach, which means that = after=20 > decompression, you still need a full RPL packet parser, which means = that=20 > the RPL protocol can in fact evolve.=20 >=20 > goyal-roll-rpl-compression (GRRC) scheme will have to be revised each = time=20 > there is an addition to the protocol, and will cause a flag day, as no=20= > node can use the new options until every node is upgraded, even if the=20= > nodes do not need to make use of the new options.=20 >=20 > In essence, the goyal-roll-rpl-compression is a fixed proprietary=20 > system.=20 >=20 >=20 >=20 >=20 > --=20 > ] He who is tired of Weird Al is tired of life! | = firewalls [=20 > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net = architect[=20 > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ = |device driver[=20 > Kyoto Plus: watch the video < = http://www.youtube.com/watch?v=3Dkzx1ycLXQSE >=20 > then sign the petition.=20 > _______________________________________________=20 > Roll mailing list=20 > Roll@ietf.org=20 > https://www.ietf.org/mailman/listinfo/roll=20 >=20 > _______________________________________________=20 >=20 >=20 >=20 > Roll mailing list=20 > Roll@ietf.org=20 > https://www.ietf.org/mailman/listinfo/roll=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From ietf@thomasclausen.org Wed Aug 31 08:53:03 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6DAA21F8CB5 for ; Wed, 31 Aug 2011 08:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsRPXzv+X5b7 for ; Wed, 31 Aug 2011 08:53:03 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9560C21F8CB4 for ; Wed, 31 Aug 2011 08:53:00 -0700 (PDT) Received: from sphinx.lix.polytechnique.fr ([129.104.11.1] helo=[10.0.1.5]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Qyn7W-000P5G-HC; Wed, 31 Aug 2011 15:54:30 +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: U2FsdGVkX19hsjG/PXT7s76jMPlXEREV Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Thomas Heide Clausen In-Reply-To: <877272675.140749.1314734995826.JavaMail.root@mail05.pantherlink.uwm.edu> Date: Wed, 31 Aug 2011 17:54:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <877272675.140749.1314734995826.JavaMail.root@mail05.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1244.3) Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 15:53:04 -0000 On Aug 30, 2011, at 22:09 , Mukul Goyal wrote: > Please realize that the compressed objects have different code values = than regular objects. Hence there is no danger of lack of = interoperability. Well, you effectively define an alternative protocol exchange format, = and enforce partitioning of the network in two: those supporting GRRC = and those that do not. Or, MUST a router supporting GRRC also always = support stock-RPL? Both in transmission and sending? If I implement a thcRPL accepting/sending only stock-RPL messages, and = Ulrich implements uhRPL using only the alternative GRRC-RPL message = format, we can't interoperate.=20 Must uhRPL support both stock-RPL and GRRC-RPL messages (i.e. have two = parsers, =85)? If so, how does uhRPL know of which format it should send = messages? Or, must it always send both? I do fear that this becomes either a deployment/configuration or = signaling nightmare, especially in environments with heterogeneous = suppliers of equipment (such as is the case in most of the networks that = I am interested in). Respectfully yours, Thomas > Thanks > Mukul >=20 > ----- Original Message ----- > From: "Mukul Goyal" > To: "Ulrich Herberg" > Cc: "roll WG" > Sent: Tuesday, August 30, 2011 3:06:43 PM > Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a = new ROLL WG document >=20 > By the same logic, you would argue that P2P-RPL would lead to = non-interoperable implementations since some devices would speak P2P-RPL = and others wont. >=20 > Thanks > Mukul >=20 > ----- Original Message ----- > From: "Ulrich Herberg" > To: "Michael Richardson" > Cc: "Mukul Goyal" , "roll WG" > Sent: Tuesday, August 30, 2011 2:58:21 PM > Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a = new ROLL WG document >=20 > I agree with Michael's concern that using GRRC could lead to = non-interoperable implementations, with some nodes "speaking" normal = RPL, some using GRRC. That might require some additional negotiation = between nodes, or worse, could lead to non-interoperable parts of the = network. That worries me.=20 >=20 > Ulrich=20 >=20 >=20 > On Tue, Aug 30, 2011 at 12:53 PM, Michael Richardson < = mcr@sandelman.ca > wrote:=20 >=20 >=20 >=20 >>>>>> "Mukul" =3D=3D Mukul Goyal < mukul@uwm.edu > writes:=20 > Mukul> I was wondering if you have the compression scheme described=20= > Mukul> in draft-bormann-6lowpan-ghc in mind. I guess it will be=20 > Mukul> useful to compare the compression achieved using the two=20 > Mukul> schemes for the two examples described in=20 > Mukul> draft-goyal-roll-rpl-compression. I think that compression=20= > Mukul> achieved with draft-bormann scheme would vary with the = actual=20 > Mukul> byte stream contained in the packet. There is ofcourse no=20 > Mukul> such dependency in case of our scheme.=20 >=20 > yes, but the goyal-roll-rpl-compression (GRRC from now on, okay?) = scheme=20 > will result in devices that support the compressed format only,=20 > essentially creating an entirely new protocol.=20 >=20 > 6lowpan-ghc applies things as a layered approach, which means that = after=20 > decompression, you still need a full RPL packet parser, which means = that=20 > the RPL protocol can in fact evolve.=20 >=20 > goyal-roll-rpl-compression (GRRC) scheme will have to be revised each = time=20 > there is an addition to the protocol, and will cause a flag day, as no=20= > node can use the new options until every node is upgraded, even if the=20= > nodes do not need to make use of the new options.=20 >=20 > In essence, the goyal-roll-rpl-compression is a fixed proprietary=20 > system.=20 >=20 >=20 >=20 >=20 > --=20 > ] He who is tired of Weird Al is tired of life! | = firewalls [=20 > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net = architect[=20 > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ = |device driver[=20 > Kyoto Plus: watch the video < = http://www.youtube.com/watch?v=3Dkzx1ycLXQSE >=20 > then sign the petition.=20 > _______________________________________________=20 > Roll mailing list=20 > Roll@ietf.org=20 > https://www.ietf.org/mailman/listinfo/roll=20 >=20 > _______________________________________________ > 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 Jorjeta.Jetcheva@itron.com Wed Aug 31 09:03:34 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A5121F8D00 for ; Wed, 31 Aug 2011 09:03:34 -0700 (PDT) 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_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UowctAyNZIbP for ; Wed, 31 Aug 2011 09:03:33 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.115]) by ietfa.amsl.com (Postfix) with ESMTP id 0F95921F8CFE for ; Wed, 31 Aug 2011 09:03:33 -0700 (PDT) Received: from ITR-EXMBXVS-2.itron.com ([192.168.9.111]) by spo-exchcn-1.itron.com ([192.168.9.115]) with mapi; Wed, 31 Aug 2011 09:05:03 -0700 From: "Jetcheva, Jorjeta" To: "Akyol, Bora A" Date: Wed, 31 Aug 2011 09:05:00 -0700 Thread-Topic: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Thread-Index: Acxn7/CjOvoA2I0MSE2h62drRPq3nAAAn1vwAABLMsAAAEDWUA== Message-ID: <0368F388C03BB34BBBFA73209849D47A4CC5A0AD@ITR-EXMBXVS-2.itron.com> References: <0368F388C03BB34BBBFA73209849D47A4CC59F57@ITR-EXMBXVS-2.itron.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: =?iso-8859-1?Q?D=E9jean_Nicolas?= , "roll@ietf.org" Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 16:03:34 -0000 Hello Bora, The text in this paragraph doesn't actually use the word "substantial", and= I think you meant "wireline", not "powerline". =20 What would you consider to be a "substantiated" statement of the applicabil= ity/benefits of mesh networks relative to other deployment paradigms? Thanks, Jorjeta Jorjeta Jetcheva, Ph.D. Principal Engineer, Architecture & Standards CTO Office Itron, Inc. -----Original Message----- From: Akyol, Bora A [mailto:bora@pnnl.gov]=20 Sent: Wednesday, August 31, 2011 8:40 AM To: Jetcheva, Jorjeta Cc: D?jean Nicolas; roll@ietf.org Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Hi Jorjeta Sorry, I had two comments in my original email. One was regarding gas/power= meters and the second regarding the non-technical slant in the introductio= n. The modified paragraph that I proposed is related to the second point. To answer your question, I disagree with the unbsubstantiated statement tha= t multi-hop wireless mesh networks have substantial cost benefits compared to either powerline or single-hop (e.g. cellular modems) networks.= =20 I am not saying this is completely wrong, I am saying that this statement d= oes not belong in an IETF document since it has no relevance to ROLL or the applicability of ROLL to AMI networks. I think the paragraph I propo= sed is clear-cut and technically accurate without having a bias towards the= use of wireless mesh networks. Regards Bora -----Original Message----- From: Jetcheva, Jorjeta [mailto:Jorjeta.Jetcheva@itron.com]=20 Sent: Wednesday, August 31, 2011 8:35 AM To: Akyol, Bora A Cc: D?jean Nicolas; roll@ietf.org Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Hello Bora, The paragraph you cited does not reference anything related to water or gas= meters which was the topic of your earlier comment and the discussion that= followed. Is this perhaps not the right paragraph or is this the beginnin= g of a new discussion? As far as the benefits of multi-hop networks over wireline or cellular back= haul, I think that lower cost and deployment complexity are pretty commonly= cited. Do you disagree with this statement? Thanks, Jorjeta Jorjeta Jetcheva, Ph.D. Principal Engineer, Architecture & Standards CTO Office Itron, Inc. -----Original Message----- From: Akyol, Bora A [mailto:bora@pnnl.gov] Sent: Wednesday, August 31, 2011 8:09 AM To: Nicolas DEJEAN Cc: Jetcheva, Jorjeta; roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Hi Nicolas Yes, we had a private email exchange off-list. I would like to suggest alternate wording for this paragraph as follows: ORIGINAL: Electric meters are often interconnected into multi-hop mesh networks, each of which is connected to a backhaul network leading to the utility network through a network aggregation point (NAP). These kinds of networks increase coverage and reduce installation cost, time and complexity, as well as operational costs, as compared to single-hop wireless networks, relying on a wireline or cellular backhaul. Each electric meter mesh typically has on the order of several thousand wireless endpoints, with densities varying based on the area and the terrain. Apartment buildings in urban centers may have hundreds of meters in close proximity, whereas rural areas may have sparse node distributions and include nodes that only have one or two network neighbors. Paths in the mesh between a network device and the nearest aggregation point may be composed of several hops or even tens of hops. ALTERNATE WORDING: In one type of AMI network, electric meters are interconnected into multi-hop mesh networks, each of which is connected to a backhaul network leading to the utility network through a network aggregation point (NAP). In a multi-hop mesh network, each electric meter mesh may have up to several thousand wireless endpoints, with densities varying based on the area and the terrain. Apartment buildings in urban centers may have hundreds of meters in close proximity, whereas rural areas may have sparse node distributions and include nodes that only have one or two network neighbors.=20 Paths in the mesh between a network device and the nearest aggregation point may be composed of several hops or even tens of hops. What do you think? Thanks --=20 Bora Akyol, Pacific Northwest National Laboratory +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov On 8/31/11 4:23 AM, "Nicolas DEJEAN" wrote: >Hello Bora, > >Did Jorjeta answered your concerns about an AMI network considered as >a backhaul for Gas and Water? > >Thank you in advance, > >Nicolas. > >2011/8/30 Jetcheva, Jorjeta : >> Hello Bora, >> >>> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >>> backhaul were considered out of scope. >> >> Actually AMI backhaul for gas and water meters is very much in scope as >>per the NIST Wireless Guidelines (PAP2) work and the related >>SG-Communications/SG-Net work. CSWG coordinates with the PAPs so they >>should be aware of this. >> >> Jorjeta >> >> Jorjeta Jetcheva, Ph.D. >> Principal Engineer, Architecture & Standards >> CTO Office >> Itron, Inc. >> >> >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >>Akyol, Bora A >> Sent: Tuesday, August 30, 2011 10:37 AM >> To: Nicolas DEJEAN >> Cc: roll@ietf.org >> Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt >> >> Hi Nicolas >> >> Thank you for your response. >> >> Please see my comments within >> -- >> Bora Akyol, Pacific Northwest National Laboratory >> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >> >> >> >> >> On 8/30/11 1:25 AM, "Nicolas DEJEAN" >> >> wrote: >> >>>Hello Bora, >>> >>>2011/7/29 Akyol, Bora A : >>>> I think the statement about AMI networks being used as an almost >>>>general >>>> purpose backhaul network for all other devices >>>> is overreaching. I know there are some utilities that are looking into >>>> this, but a lot more that have shied away from >>>> this vision. Secondly, there are a lot more AMI deployments not using >>>> wireless mesh networks, e.g. using cellular modem, >>>> powerline carrier, etc. >>> >>>I agree that all utilities are not looking into it. >>>However this is one possible case that should be considered, isn't it? >>>Could you please precise what you are expecting to be in the draft? >> >> I think the draft should be focusing on the applicability of ROLL from a >> technical front >> without siting this one case as the only justification. >> >>> >>>> >>>> Is it possible to tone this "marketing" text Section 1.1. down and >>>>also >>>> potentially >>>> remove Gas & Water meters from the scope of this document. >>>> >>> >>>On our point of view, Gas and Water metering are part of AMI. >> >> This is not the widely-held view at least within the US electric utility >> community. >> The gas and water meters have capabilities which are quite different >>from >> electric power meters. >> For example, while the electric meter has easy access to mains power, >>the >> gas/water meters don't. >> In most instances, the gas/water service may be provided by a completely >> different entity than the electric >> power utility. >> >> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >> backhaul were considered out of scope. >> >> Would the document lose technical integrity if the gas/water meter were >> either removed or included as an optional. >> >> Regards >> >> >> >>>Could you please elaborate? >>>According to you, why should Gas and Water be removed from the draft? >>> >>>Thank you in advance, >>> >>>Nicolas. >>> >>>> Regards >>>> >>>> -- >>>> Bora Akyol, Pacific Northwest National Laboratory >>>> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>>> >>>> _______________________________________________ >>>> 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 pthubert@cisco.com Wed Aug 31 09:06:07 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A6F21F893C for ; Wed, 31 Aug 2011 09:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.054 X-Spam-Level: X-Spam-Status: No, score=-10.054 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lR9OBUSyXj3e for ; Wed, 31 Aug 2011 09:06:05 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id D178F21F8862 for ; Wed, 31 Aug 2011 09:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2334; q=dns/txt; s=iport; t=1314806854; x=1316016454; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=nuDI8DzOQn+g8vXFnMsSDUviKDVWaCNpizodbCH/Y2I=; b=heeMpS012h9rbffc2hZY6q61RPGjwYdjYyO0q/b7T6HCBMu44rAgsWQ+ izvy2+9fKXT8nceTbD1KXodU70q3unKocvJ3GAs9iSQrCUc///rtD9I1V sWVqmUw9GdL+4P4uU3aGdsaXsfm+i5h/MXvkxctveiNStVtCig73ZmEJa 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAI9bXk6Q/khL/2dsb2JhbABDDqg8d4E5BwEBAQEDEgEdSQwEAgEIDgMEAQELBhcBBgFFCQgBAQQBEggaomkBn0OFdWAEhziRBIs4Og X-IronPort-AV: E=Sophos;i="4.68,308,1312156800"; d="scan'208";a="113401846" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 31 Aug 2011 16:07:33 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7VG7Xdd024212; Wed, 31 Aug 2011 16:07:33 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 31 Aug 2011 18:07:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Aug 2011 18:07:32 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D055AE27C@XMB-AMS-107.cisco.com> In-Reply-To: <4884.1314797912@marajade.sandelman.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Adoption of draft-goyal-roll-rpl-compression as a newROLL WG document Thread-Index: Acxn4z3Vd3yzwy/JRhaXmET7a9lVvgADXQUg References: <1483809161.144962.1314763722334.JavaMail.root@mail05.pantherlink.uwm.edu> <4884.1314797912@marajade.sandelman.ca> From: "Pascal Thubert (pthubert)" To: "Michael Richardson" , "Mukul Goyal" X-OriginalArrivalTime: 31 Aug 2011 16:07:33.0728 (UTC) FILETIME=[17E42600:01CC67F8] Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a newROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 16:06:07 -0000 Hi Michael: My take on this work is exactly the same as 6LoWPAN Header Compression. = You will enable compression if all the devices support it. So you buy = and deploy devices that support RFC blah and they interoperate. If = someone comes in with a different compression - or different MAC frames = for that matter, then that node cannot participate to that specific = network. So in my mind there is no partial upgrade or mixed scenario. = And if there was, GHC would not make a difference. Also, I think that if we change RPL to RPLv2, I will not mind changing = the compression to compression v2 at the same time, because probably the = 2 RPL versions would not interoperate well.=20 Anyway, I have no religion on the compression method. Probably the = overall saving is a more important goal than implementation simplicity. = >From the GHC draft, it seems that we can expect from 1.2 to 1.9 ratio = for RPL control packets. OTOH, 6LoWPAN HC+GHC could probably be applied = to all data packets, and we could probably add some dictionary to = overcompress 6LowPAN and the RPL headers. If there's a lot more data = than control, that certainly counts.=20 Cheers, Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Michael Richardson Sent: mercredi 31 ao=FBt 2011 15:39 To: Mukul Goyal Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a = newROLL WG document >>>>> "Mukul" =3D=3D Mukul Goyal writes: Mukul> I understand your preference for GHC scheme. As for our Mukul> scheme, it seems to me that you would like our scheme much Mukul> better if there is a way for a node to solicit Mukul> compressed/uncompressed DIOs. Is my understanding correct?=20 Mukul> This could be done by a simple DIS flag. No, I wouldn't like that. I'd like not to have to write and test two parsers for options, and I'd like the scheme not to fall apart when we = introduce another option type. I will evaluate GHC method, and write a draft this long weekend with my results. If anyone has sample RPL messages they want me to consider,=20 I would appreciate a PCAP file, otherwise, I'll evaluate only my own. In particular, I need more examples of metric options. From prvs=21736f1ad=bora@pnnl.gov Wed Aug 31 09:11:39 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E457621F8C15 for ; Wed, 31 Aug 2011 09:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.213 X-Spam-Level: X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id op9ebWRJB+Ps for ; Wed, 31 Aug 2011 09:11:37 -0700 (PDT) Received: from emailgw03.pnl.gov (emailgw03.pnl.gov [192.101.109.31]) by ietfa.amsl.com (Postfix) with ESMTP id 90B6421F8B8F for ; Wed, 31 Aug 2011 09:11:37 -0700 (PDT) Received: from emailhub02.pnl.gov ([130.20.251.62]) by emailgw03.pnl.gov with ESMTP/TLS/AES128-SHA; 31 Aug 2011 09:13:08 -0700 Received: from Email05.pnl.gov ([130.20.251.70]) by emailhub02.pnl.gov ([130.20.251.62]) with mapi; Wed, 31 Aug 2011 09:12:48 -0700 From: "Akyol, Bora A" To: "Jetcheva, Jorjeta" Date: Wed, 31 Aug 2011 09:13:04 -0700 Thread-Topic: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Thread-Index: Acxn+N7nNlDzn16jT/a4Vz4B6K8W6w== Message-ID: In-Reply-To: <0368F388C03BB34BBBFA73209849D47A4CC5A0AD@ITR-EXMBXVS-2.itron.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: D?jean Nicolas , "roll@ietf.org" Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 16:11:39 -0000 Hi again, My point is that this statement adds no value to the document and in my opinion subtracts value. The alternate wording I suggested is technical and avoids "markitecture" type statements. I meant powerline (as in Aclara TWACS or the newer technologies) which is essentially a single hop technology. I believe the cost effectiveness of a particular technology highly depends on the OPEX as well as the CAPEX, and customer density. I don't think we should take that on in an IETF document. Regards --=20 Bora Akyol, Pacific Northwest National Laboratory +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov On 8/31/11 9:05 AM, "Jetcheva, Jorjeta" wrote: >Hello Bora, > >The text in this paragraph doesn't actually use the word "substantial", >and I think you meant "wireline", not "powerline". > >What would you consider to be a "substantiated" statement of the >applicability/benefits of mesh networks relative to other deployment >paradigms? > >Thanks, Jorjeta > >Jorjeta Jetcheva, Ph.D. >Principal Engineer, Architecture & Standards >CTO Office >Itron, Inc. > > >-----Original Message----- >From: Akyol, Bora A [mailto:bora@pnnl.gov] >Sent: Wednesday, August 31, 2011 8:40 AM >To: Jetcheva, Jorjeta >Cc: D?jean Nicolas; roll@ietf.org >Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt > > >Hi Jorjeta > >Sorry, I had two comments in my original email. One was regarding >gas/power meters and the second regarding the non-technical slant in the >introduction. >The modified paragraph that I proposed is related to the second point. > >To answer your question, I disagree with the unbsubstantiated statement >that multi-hop wireless mesh networks have substantial cost benefits >compared to either powerline or single-hop (e.g. cellular modems) >networks.=20 >I am not saying this is completely wrong, I am saying that this statement >does not belong in an IETF document since it has no relevance to ROLL >or the applicability of ROLL to AMI networks. I think the paragraph I >proposed is clear-cut and technically accurate without having a bias >towards the use of wireless mesh networks. > >Regards > >Bora > >-----Original Message----- >From: Jetcheva, Jorjeta [mailto:Jorjeta.Jetcheva@itron.com] >Sent: Wednesday, August 31, 2011 8:35 AM >To: Akyol, Bora A >Cc: D?jean Nicolas; roll@ietf.org >Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt > >Hello Bora, > >The paragraph you cited does not reference anything related to water or >gas meters which was the topic of your earlier comment and the discussion >that followed. Is this perhaps not the right paragraph or is this the >beginning of a new discussion? > >As far as the benefits of multi-hop networks over wireline or cellular >backhaul, I think that lower cost and deployment complexity are pretty >commonly cited. Do you disagree with this statement? > >Thanks, Jorjeta > >Jorjeta Jetcheva, Ph.D. >Principal Engineer, Architecture & Standards CTO Office Itron, Inc. > > >-----Original Message----- >From: Akyol, Bora A [mailto:bora@pnnl.gov] >Sent: Wednesday, August 31, 2011 8:09 AM >To: Nicolas DEJEAN >Cc: Jetcheva, Jorjeta; roll@ietf.org >Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt > > >Hi Nicolas > >Yes, we had a private email exchange off-list. > >I would like to suggest alternate wording for this paragraph as follows: > >ORIGINAL: > > Electric meters are often interconnected into multi-hop mesh > networks, each of which is connected to a backhaul network leading to > the utility network through a network aggregation point (NAP). These > kinds of networks increase coverage and reduce installation cost, > time and complexity, as well as operational costs, as compared to > single-hop wireless networks, relying on a wireline or cellular > backhaul. Each electric meter mesh typically has on the order of > several thousand wireless endpoints, with densities varying based on > the area and the terrain. Apartment buildings in urban centers may > have hundreds of meters in close proximity, whereas rural areas may >have sparse node distributions and include nodes that only have one or >two network neighbors. Paths in the mesh between a network device > and the nearest aggregation point may be composed of several hops or > even tens of hops. > > >ALTERNATE WORDING: > > >In one type of AMI network, electric meters are interconnected into >multi-hop mesh >networks, each of which is connected to a backhaul network leading to >the utility network through a network aggregation point (NAP). > >mesh> > >In a multi-hop mesh network, each electric meter mesh may have up to >several thousand wireless endpoints, with densities varying based on >the area and the terrain. Apartment buildings in urban centers may >have hundreds of meters in close proximity, whereas rural areas may >have sparse node distributions and include nodes that only have one or two >network neighbors. >Paths in the mesh between a network device >and the nearest aggregation point may be composed of several hops or >even tens of hops. > > > >What do you think? > >Thanks > > >--=20 >Bora Akyol, Pacific Northwest National Laboratory >+1 509 371 6682, bora@pnnl.gov, www.pnnl.gov > > > > >On 8/31/11 4:23 AM, "Nicolas DEJEAN" >wrote: > >>Hello Bora, >> >>Did Jorjeta answered your concerns about an AMI network considered as >>a backhaul for Gas and Water? >> >>Thank you in advance, >> >>Nicolas. >> >>2011/8/30 Jetcheva, Jorjeta : >>> Hello Bora, >>> >>>> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >>>> backhaul were considered out of scope. >>> >>> Actually AMI backhaul for gas and water meters is very much in scope as >>>per the NIST Wireless Guidelines (PAP2) work and the related >>>SG-Communications/SG-Net work. CSWG coordinates with the PAPs so they >>>should be aware of this. >>> >>> Jorjeta >>> >>> Jorjeta Jetcheva, Ph.D. >>> Principal Engineer, Architecture & Standards >>> CTO Office >>> Itron, Inc. >>> >>> >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >>>Akyol, Bora A >>> Sent: Tuesday, August 30, 2011 10:37 AM >>> To: Nicolas DEJEAN >>> Cc: roll@ietf.org >>> Subject: Re: [Roll] I-D Action: >>>draft-ietf-roll-applicability-ami-01.txt >>> >>> Hi Nicolas >>> >>> Thank you for your response. >>> >>> Please see my comments within >>> -- >>> Bora Akyol, Pacific Northwest National Laboratory >>> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>> >>> >>> >>> >>> On 8/30/11 1:25 AM, "Nicolas DEJEAN" >>> >>> wrote: >>> >>>>Hello Bora, >>>> >>>>2011/7/29 Akyol, Bora A : >>>>> I think the statement about AMI networks being used as an almost >>>>>general >>>>> purpose backhaul network for all other devices >>>>> is overreaching. I know there are some utilities that are looking >>>>>into >>>>> this, but a lot more that have shied away from >>>>> this vision. Secondly, there are a lot more AMI deployments not using >>>>> wireless mesh networks, e.g. using cellular modem, >>>>> powerline carrier, etc. >>>> >>>>I agree that all utilities are not looking into it. >>>>However this is one possible case that should be considered, isn't it? >>>>Could you please precise what you are expecting to be in the draft? >>> >>> I think the draft should be focusing on the applicability of ROLL from >>>a >>> technical front >>> without siting this one case as the only justification. >>> >>>> >>>>> >>>>> Is it possible to tone this "marketing" text Section 1.1. down and >>>>>also >>>>> potentially >>>>> remove Gas & Water meters from the scope of this document. >>>>> >>>> >>>>On our point of view, Gas and Water metering are part of AMI. >>> >>> This is not the widely-held view at least within the US electric >>>utility >>> community. >>> The gas and water meters have capabilities which are quite different >>>from >>> electric power meters. >>> For example, while the electric meter has easy access to mains power, >>>the >>> gas/water meters don't. >>> In most instances, the gas/water service may be provided by a >>>completely >>> different entity than the electric >>> power utility. >>> >>> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >>> backhaul were considered out of scope. >>> >>> Would the document lose technical integrity if the gas/water meter were >>> either removed or included as an optional. >>> >>> Regards >>> >>> >>> >>>>Could you please elaborate? >>>>According to you, why should Gas and Water be removed from the draft? >>>> >>>>Thank you in advance, >>>> >>>>Nicolas. >>>> >>>>> Regards >>>>> >>>>> -- >>>>> Bora Akyol, Pacific Northwest National Laboratory >>>>> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>>>> >>>>> _______________________________________________ >>>>> 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 ietf@thomasclausen.org Wed Aug 31 09:21:45 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2D121F8C3D for ; Wed, 31 Aug 2011 09:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJBsyP5QYbIa for ; Wed, 31 Aug 2011 09:21:45 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id E1F6621F8BEE for ; Wed, 31 Aug 2011 09:21:44 -0700 (PDT) Received: from sphinx.lix.polytechnique.fr ([129.104.11.1] helo=[10.0.1.5]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Qyn80-000P5G-IR; Wed, 31 Aug 2011 15:55: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: U2FsdGVkX1+pBQko1rI4WJ0LBBjQ7tbp Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Thomas Heide Clausen In-Reply-To: <4884.1314797912@marajade.sandelman.ca> Date: Wed, 31 Aug 2011 17:54:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1483809161.144962.1314763722334.JavaMail.root@mail05.pantherlink.uwm.edu> <4884.1314797912@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1244.3) Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 16:21:46 -0000 I think that this is somewhat going to the crux of what I was referring = to when I suggested updates/obsoletes RPL in case this (or, any) = compression scheme is introduced. As I understood the original design scope of ROLL, as retained in the = charter, 802.15.4 was one of the (but, not the only) target L2's. It may = be that a less verbose message format is required for 802.15.4 than that = currently proposed in RPL - in fact, we've got some indications from our = testing that this is the case (even for stock RPL) to avoid = fragmentation. However then the working group should fix the problem in RPL by updating = that specification, rather than propose an alternative, incompatible = message format as an option which - as Michael has pointed out in this = and previous messages - necessitating writing/testing multiple different = parsers, additional signaling to ensure that in a given deployment = messages are sent in the "right" format (or, do we disallow heterogenous = deployments?) etc. I'm concerned that the WG, so early after (well, before) that RPL is = published as RFC feels the need to consider such "patches" to the = protocol. Respectfully yours,=20 Thomas On Aug 31, 2011, at 15:38 , Michael Richardson wrote: >=20 >>>>>> "Mukul" =3D=3D Mukul Goyal writes: > Mukul> I understand your preference for GHC scheme. As for our > Mukul> scheme, it seems to me that you would like our scheme much > Mukul> better if there is a way for a node to solicit > Mukul> compressed/uncompressed DIOs. Is my understanding correct?=20= > Mukul> This could be done by a simple DIS flag. >=20 > No, I wouldn't like that. I'd like not to have to write and test two > parsers for options, and I'd like the scheme not to fall apart when we > introduce another option type. >=20 > I will evaluate GHC method, and write a draft this long weekend with = my > results. If anyone has sample RPL messages they want me to consider,=20= > I would appreciate a PCAP file, otherwise, I'll evaluate only my own. > In particular, I need more examples of metric options. >=20 >=20 > --=20 > ] He who is tired of Weird Al is tired of life! | = firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net = architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ = |device driver[ > Kyoto Plus: watch the video = > then sign the petition.=20 >=20 >=20 >=20 >=20 >=20 >=20 From ietf@thomasclausen.org Wed Aug 31 09:21:46 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4863E21F8B1C for ; Wed, 31 Aug 2011 09:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTnW1O2O0o12 for ; Wed, 31 Aug 2011 09:21:45 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 29ACE21F8C0D for ; Wed, 31 Aug 2011 09:21:45 -0700 (PDT) Received: from sphinx.lix.polytechnique.fr ([129.104.11.1] helo=[10.0.1.5]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Qyn8B-000P5G-K5; Wed, 31 Aug 2011 15:55:11 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 129.104.11.1 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+sD7Rzb75CprlDTpKkepha Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Thomas Heide Clausen In-Reply-To: <1593431155.140676.1314734802999.JavaMail.root@mail05.pantherlink.uwm.edu> Date: Wed, 31 Aug 2011 17:55:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1831033C-FE54-4B15-BC8B-B4C8E230AFD1@thomasclausen.org> References: <1593431155.140676.1314734802999.JavaMail.root@mail05.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1244.3) Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 16:21:46 -0000 I would actually argue that RPL and P2P-RPL are two entirely different = protocols (albeit sharing some commonalities in the overall message = structure). There are ways of making multiple routing protocols co-exist on the same = routers (and in the same network). However I am not sure that it is such = a good idea to do so in a LLN. I've always found it odd that P2P traffic was not supported in RPL -- = and really, dog-leg routing through a DODAG root and using source = routing isn't (efficiently) supporting P2P. In short, I do agree with Ulrich's logic. Respectfully yours, Thomas On Aug 30, 2011, at 22:06 , Mukul Goyal wrote: > By the same logic, you would argue that P2P-RPL would lead to = non-interoperable implementations since some devices would speak P2P-RPL = and others wont. >=20 > Thanks > Mukul >=20 > ----- Original Message ----- > From: "Ulrich Herberg" > To: "Michael Richardson" > Cc: "Mukul Goyal" , "roll WG" > Sent: Tuesday, August 30, 2011 2:58:21 PM > Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a = new ROLL WG document >=20 > I agree with Michael's concern that using GRRC could lead to = non-interoperable implementations, with some nodes "speaking" normal = RPL, some using GRRC. That might require some additional negotiation = between nodes, or worse, could lead to non-interoperable parts of the = network. That worries me.=20 >=20 > Ulrich=20 >=20 >=20 > On Tue, Aug 30, 2011 at 12:53 PM, Michael Richardson < = mcr@sandelman.ca > wrote:=20 >=20 >=20 >=20 >>>>>> "Mukul" =3D=3D Mukul Goyal < mukul@uwm.edu > writes:=20 > Mukul> I was wondering if you have the compression scheme described=20= > Mukul> in draft-bormann-6lowpan-ghc in mind. I guess it will be=20 > Mukul> useful to compare the compression achieved using the two=20 > Mukul> schemes for the two examples described in=20 > Mukul> draft-goyal-roll-rpl-compression. I think that compression=20= > Mukul> achieved with draft-bormann scheme would vary with the = actual=20 > Mukul> byte stream contained in the packet. There is ofcourse no=20 > Mukul> such dependency in case of our scheme.=20 >=20 > yes, but the goyal-roll-rpl-compression (GRRC from now on, okay?) = scheme=20 > will result in devices that support the compressed format only,=20 > essentially creating an entirely new protocol.=20 >=20 > 6lowpan-ghc applies things as a layered approach, which means that = after=20 > decompression, you still need a full RPL packet parser, which means = that=20 > the RPL protocol can in fact evolve.=20 >=20 > goyal-roll-rpl-compression (GRRC) scheme will have to be revised each = time=20 > there is an addition to the protocol, and will cause a flag day, as no=20= > node can use the new options until every node is upgraded, even if the=20= > nodes do not need to make use of the new options.=20 >=20 > In essence, the goyal-roll-rpl-compression is a fixed proprietary=20 > system.=20 >=20 >=20 >=20 >=20 > --=20 > ] He who is tired of Weird Al is tired of life! | = firewalls [=20 > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net = architect[=20 > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ = |device driver[=20 > Kyoto Plus: watch the video < = http://www.youtube.com/watch?v=3Dkzx1ycLXQSE >=20 > then sign the petition.=20 > _______________________________________________=20 > Roll mailing list=20 > Roll@ietf.org=20 > https://www.ietf.org/mailman/listinfo/roll=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From ietf@thomasclausen.org Wed Aug 31 09:21:46 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6DD121F8BEE for ; Wed, 31 Aug 2011 09:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wA0fhJnFqm0A for ; Wed, 31 Aug 2011 09:21:45 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 64D8F21F8C10 for ; Wed, 31 Aug 2011 09:21:45 -0700 (PDT) Received: from sphinx.lix.polytechnique.fr ([129.104.11.1] helo=[10.0.1.5]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Qyn7w-000P5G-9x; Wed, 31 Aug 2011 15:54: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: U2FsdGVkX1/I71cl3gPqCwIoytXiRLBI Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_0437FD2A-37C5-4093-936F-9747BC9FA9EB" From: Thomas Heide Clausen In-Reply-To: <521765682.140629.1314734702895.JavaMail.root@mail05.pantherlink.uwm.edu> Date: Wed, 31 Aug 2011 17:54:55 +0200 Message-Id: <4E01833C-2B92-41E6-8B19-8DABA9A65D88@thomasclausen.org> References: <521765682.140629.1314734702895.JavaMail.root@mail05.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1244.3) Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 16:21:47 -0000 --Apple-Mail=_0437FD2A-37C5-4093-936F-9747BC9FA9EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 30, 2011, at 22:05 , Mukul Goyal wrote: >> yes, but the goyal-roll-rpl-compression (GRRC from now on, okay?) = scheme >> will result in devices that support the compressed format only, >> essentially creating an entirely new protocol.=20 >=20 > This is not true. Compressed messages will have new code values. I = quote the relevant text from the draft: >=20 > "Code: The Code value of the compressed version of an RPL ICMPv6 > message is obtained by setting the 7th bit in the Code value > associated with the corresponding uncompressed message. For > example, the Code associated with a compressed DODAG Information > Object is 0x40." >=20 So, Michael is right in his observation that it is not a "compressed" = format, but an "alternative" format. Question: what expressiveness is lost by using the "alternative" GRRC = format over the verbose stock RPL format? What would be lost, in terms = of functionality, by replacing the stock RPL format by GRRC? What = additional parsing/encoding complexity does GRRC incur over RPL (if any, = it may also be less complex)? >> 6lowpan-ghc applies things as a layered approach, which means that = after >> decompression, you still need a full RPL packet parser, which means = that >> the RPL protocol can in fact evolve. >=20 > I am not doubting that. I guess the important question to answer is = whether the ghc scheme would provide enough compression. Or the devices = with ghc would have to implement additional compression mechanisms (e.g. = draft-goyal....) as well? >=20 >> goyal-roll-rpl-compression (GRRC) scheme will have to be revised each = time >> there is an addition to the protocol, >=20 > Again not true. Any new additions to the protocol DO NOT require their = compressed formats to be specified as well. One could ofcourse define = compressed formats (or define only the compressed formats) if they are = deemed useful. But it is not mandatory to do so. >=20 >> and will cause a flag day, as no >> node can use the new options until every node is upgraded, even if = the >> nodes do not need to make use of the new options. >=20 > Simply not true. I always find it preferable to try to educate those I disagree with, = rather than declaring their opinions as "simply not true". So, while I = do agree with Michael's ultimate opinion on the alternate RPL message = format proposed, let me try to do Mukul's job here and educate a bit ;) Quoting from section 4 of the draft: This section defines the compression format for some of the RPL options that may be carried inside an RPL control message. These RPL options SHOULD be compressed when carried inside an RPL control message compressed in the manner described in this document. The other RPL options, for which a compression format is not specified in this document, MUST follow the format in which they are defined when carried inside an RPL control message compressed as described in this document. In other words, the draft proposes the ability to carry uncompressed = options inside a compressed message. >=20 Note that I'm not expressing an opinion on if that is or is not a valid = design choice. Respectfully yours, Thomas >> In essence, the goyal-roll-rpl-compression is a fixed proprietary = system. >=20 > I am sorry but this is totally wrong characterization. >=20 > Thanks > Mukul >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail=_0437FD2A-37C5-4093-936F-9747BC9FA9EB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
yes, but the = goyal-roll-rpl-compression (GRRC from now on, okay?) = scheme
will result in devices = that support the compressed format only,
essentially creating an entirely new protocol. =

This is not true. Compressed messages will have new = code values. I quote the relevant text from the draft:

"Code: The = Code value of the compressed version of an RPL ICMPv6
=      message is obtained by setting the 7th bit = in the Code value
     associated with the = corresponding uncompressed message.  For
=      example, the Code associated with a = compressed DODAG Information
     Object is = 0x40."


So, Michael is right in = his observation that it is not a "compressed" format, but an = "alternative" format.

Question: what = expressiveness is lost by using the "alternative" GRRC format over the = verbose stock RPL format? What would be lost, in terms of =  functionality, by replacing the stock RPL format by GRRC? What = additional parsing/encoding complexity does GRRC incur over RPL (if any, = it may also be less complex)?

6lowpan-ghc applies things = as a layered approach, which means that = after
decompression, you still = need a full RPL packet parser, which means = that
the RPL protocol can in = fact evolve.

I am not doubting that. I guess the = important question to answer is whether the ghc scheme would provide = enough compression. Or the devices with ghc would have to implement = additional compression mechanisms (e.g. draft-goyal....) as = well?

goyal-roll-rpl-compression (GRRC) = scheme will have to be revised each time
there is an addition to the = protocol,

Again not true. Any new additions to the = protocol DO NOT require their compressed formats to be specified as = well. One could ofcourse define compressed formats (or define only the = compressed formats) if they are deemed useful. But it is not mandatory = to do so.

and will cause a flag day, = as no
node can use the new = options until every node is upgraded, even if = the
nodes do not need to make = use of the new options.

Simply not = true.

I always find it preferable = to try to educate those I disagree with, rather than declaring their = opinions as "simply not true". So, while I do agree with Michael's = ultimate opinion on the alternate RPL message format proposed, let me = try to do Mukul's job here and educate a bit = ;)

Quoting from section 4 of the = draft:

  This section defines the compression format =
for some of the RPL
   options that may be carried inside an RPL control message.  These RPL
   options SHOULD be compressed when carried inside an RPL control
   message compressed in the manner described in this document.  The
   other RPL options, for which a compression format is not specified in
   this document, MUST follow the format in which they are defined when
   carried inside an RPL control message compressed as described in this
   =
document.


In other words, the draft proposes the ability to carry uncompressed = options inside a compressed message.

Note that I'm not = expressing an opinion on if that is or is not a valid design = choice.

Respectfully = yours,

Thomas

In essence, the = goyal-roll-rpl-compression is a fixed proprietary = system.

I am sorry but this is totally wrong = characterization.

Thanks
Mukul


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

= --Apple-Mail=_0437FD2A-37C5-4093-936F-9747BC9FA9EB-- From pthubert@cisco.com Wed Aug 31 09:26:12 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B425F21F8B66 for ; Wed, 31 Aug 2011 09:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.053 X-Spam-Level: X-Spam-Status: No, score=-10.053 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHhaicKTxicd for ; Wed, 31 Aug 2011 09:26:09 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id DAD8121F8678 for ; Wed, 31 Aug 2011 09:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=10288; q=dns/txt; s=iport; t=1314808056; x=1316017656; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=UWrrGJfOyWokhCJn2wi8aD8kqmwmPvpJ8lABBiWztvU=; b=hYM5LRGZtuGz5/M7EUCuSIouPzXEmhquC9ibBrkf+8AauWnlSUDsuHXf SaomMw5Y0J6GzotOfLiSfBES/CW9f6zpN+j+zKniXl5x0xUDW/wOmTXyt GMY2HrhDFhJDcOtlQv8Skz32epFmEjlGhGMlgLx6vfrR1eZ8/gZ2j5rxH 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwAAH5gXk6Q/khM/2dsb2JhbABAA5hgj2p3gTkHAQEBAQMBAQEPAR0ZHgcBAQkMBAIBCBEBAwEBAQoGFwEGASYfAwYIAQEEEwgMDodUmxUBn0ODSoIrYASHOJEEi3I X-IronPort-AV: E=Sophos;i="4.68,308,1312156800"; d="scan'208";a="52733197" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 31 Aug 2011 16:27:11 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7VGRBis003940; Wed, 31 Aug 2011 16:27:11 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 31 Aug 2011 18:27:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Aug 2011 18:27:10 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D055AE297@XMB-AMS-107.cisco.com> In-Reply-To: <0368F388C03BB34BBBFA73209849D47A4CC5A0AD@ITR-EXMBXVS-2.itron.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Thread-Index: Acxn7/CjOvoA2I0MSE2h62drRPq3nAAAn1vwAABLMsAAAEDWUAAA9qog References: <0368F388C03BB34BBBFA73209849D47A4CC59F57@ITR-EXMBXVS-2.itron.com> <0368F388C03BB34BBBFA73209849D47A4CC5A0AD@ITR-EXMBXVS-2.itron.com> From: "Pascal Thubert (pthubert)" To: "Jetcheva, Jorjeta" , "Akyol, Bora A" X-OriginalArrivalTime: 31 Aug 2011 16:27:11.0305 (UTC) FILETIME=[D5C82390:01CC67FA] Cc: =?iso-8859-1?Q?D=E9jean_Nicolas?= , roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 16:26:12 -0000 Hello Jorjeta and Bora: About this: < These kinds of networks increase coverage and reduce installation cost, time and complexity, as well as operational costs, as compared to single-hop wireless networks, relying on a wireline or cellular backhaul. > assertion. I'd think that the general benefit of meshing is the spatial reuse of = the medium - same thing for any switched fabric at the end of the day -. This benefits most to environments where the medium is a constrained or = expensive resource. This is much is very well-known and justifies the = original text about cost savings. >From there, the meshing/routing mechanism has to be designed in such a = fashion that it is simple to deploy, with the classical self-* = properties. A radio meshing/routing system will indeed be simpler to deploy because = as the intro says, it will be easier to guarantee an appropriate = coverage, which you cannot do at all times with one hop of wire (because = of movement) or cellular (because of dark zones). So for all I know, the quoted text is not unsubstantiated and asilye = justified for people of the art. I have no issue leaving the text as is = and I find it relevant. Cheers, Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Jetcheva, Jorjeta Sent: mercredi 31 ao=FBt 2011 18:05 To: Akyol, Bora A Cc: D=E9jean Nicolas; roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Hello Bora, The text in this paragraph doesn't actually use the word "substantial", = and I think you meant "wireline", not "powerline". =20 What would you consider to be a "substantiated" statement of the = applicability/benefits of mesh networks relative to other deployment = paradigms? Thanks, Jorjeta Jorjeta Jetcheva, Ph.D. Principal Engineer, Architecture & Standards CTO Office Itron, Inc. -----Original Message----- From: Akyol, Bora A [mailto:bora@pnnl.gov] Sent: Wednesday, August 31, 2011 8:40 AM To: Jetcheva, Jorjeta Cc: D?jean Nicolas; roll@ietf.org Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Hi Jorjeta Sorry, I had two comments in my original email. One was regarding = gas/power meters and the second regarding the non-technical slant in the = introduction. The modified paragraph that I proposed is related to the second point. To answer your question, I disagree with the unbsubstantiated statement = that multi-hop wireless mesh networks have substantial cost benefits compared to either powerline or single-hop (e.g. cellular modems) = networks.=20 I am not saying this is completely wrong, I am saying that this = statement does not belong in an IETF document since it has no relevance = to ROLL or the applicability of ROLL to AMI networks. I think the paragraph I = proposed is clear-cut and technically accurate without having a bias = towards the use of wireless mesh networks. Regards Bora -----Original Message----- From: Jetcheva, Jorjeta [mailto:Jorjeta.Jetcheva@itron.com]=20 Sent: Wednesday, August 31, 2011 8:35 AM To: Akyol, Bora A Cc: D?jean Nicolas; roll@ietf.org Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Hello Bora, The paragraph you cited does not reference anything related to water or = gas meters which was the topic of your earlier comment and the = discussion that followed. Is this perhaps not the right paragraph or is = this the beginning of a new discussion? As far as the benefits of multi-hop networks over wireline or cellular = backhaul, I think that lower cost and deployment complexity are pretty = commonly cited. Do you disagree with this statement? Thanks, Jorjeta Jorjeta Jetcheva, Ph.D. Principal Engineer, Architecture & Standards CTO Office Itron, Inc. -----Original Message----- From: Akyol, Bora A [mailto:bora@pnnl.gov] Sent: Wednesday, August 31, 2011 8:09 AM To: Nicolas DEJEAN Cc: Jetcheva, Jorjeta; roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Hi Nicolas Yes, we had a private email exchange off-list. I would like to suggest alternate wording for this paragraph as follows: ORIGINAL: Electric meters are often interconnected into multi-hop mesh networks, each of which is connected to a backhaul network leading to the utility network through a network aggregation point (NAP). These kinds of networks increase coverage and reduce installation cost, time and complexity, as well as operational costs, as compared to single-hop wireless networks, relying on a wireline or cellular backhaul. Each electric meter mesh typically has on the order of several thousand wireless endpoints, with densities varying based on the area and the terrain. Apartment buildings in urban centers may have hundreds of meters in close proximity, whereas rural areas may have sparse node distributions and include nodes that only have one or two network neighbors. Paths in the mesh between a network device and the nearest aggregation point may be composed of several hops or even tens of hops. ALTERNATE WORDING: In one type of AMI network, electric meters are interconnected into multi-hop mesh networks, each of which is connected to a backhaul network leading to the utility network through a network aggregation point (NAP). In a multi-hop mesh network, each electric meter mesh may have up to several thousand wireless endpoints, with densities varying based on the area and the terrain. Apartment buildings in urban centers may have hundreds of meters in close proximity, whereas rural areas may have sparse node distributions and include nodes that only have one or = two network neighbors.=20 Paths in the mesh between a network device and the nearest aggregation point may be composed of several hops or even tens of hops. What do you think? Thanks --=20 Bora Akyol, Pacific Northwest National Laboratory +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov On 8/31/11 4:23 AM, "Nicolas DEJEAN" = wrote: >Hello Bora, > >Did Jorjeta answered your concerns about an AMI network considered as >a backhaul for Gas and Water? > >Thank you in advance, > >Nicolas. > >2011/8/30 Jetcheva, Jorjeta : >> Hello Bora, >> >>> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >>> backhaul were considered out of scope. >> >> Actually AMI backhaul for gas and water meters is very much in scope = as >>per the NIST Wireless Guidelines (PAP2) work and the related >>SG-Communications/SG-Net work. CSWG coordinates with the PAPs so they >>should be aware of this. >> >> Jorjeta >> >> Jorjeta Jetcheva, Ph.D. >> Principal Engineer, Architecture & Standards >> CTO Office >> Itron, Inc. >> >> >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of >>Akyol, Bora A >> Sent: Tuesday, August 30, 2011 10:37 AM >> To: Nicolas DEJEAN >> Cc: roll@ietf.org >> Subject: Re: [Roll] I-D Action: = draft-ietf-roll-applicability-ami-01.txt >> >> Hi Nicolas >> >> Thank you for your response. >> >> Please see my comments within >> -- >> Bora Akyol, Pacific Northwest National Laboratory >> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >> >> >> >> >> On 8/30/11 1:25 AM, "Nicolas DEJEAN" >> >> wrote: >> >>>Hello Bora, >>> >>>2011/7/29 Akyol, Bora A : >>>> I think the statement about AMI networks being used as an almost >>>>general >>>> purpose backhaul network for all other devices >>>> is overreaching. I know there are some utilities that are looking = into >>>> this, but a lot more that have shied away from >>>> this vision. Secondly, there are a lot more AMI deployments not = using >>>> wireless mesh networks, e.g. using cellular modem, >>>> powerline carrier, etc. >>> >>>I agree that all utilities are not looking into it. >>>However this is one possible case that should be considered, isn't = it? >>>Could you please precise what you are expecting to be in the draft? >> >> I think the draft should be focusing on the applicability of ROLL = from a >> technical front >> without siting this one case as the only justification. >> >>> >>>> >>>> Is it possible to tone this "marketing" text Section 1.1. down and >>>>also >>>> potentially >>>> remove Gas & Water meters from the scope of this document. >>>> >>> >>>On our point of view, Gas and Water metering are part of AMI. >> >> This is not the widely-held view at least within the US electric = utility >> community. >> The gas and water meters have capabilities which are quite different >>from >> electric power meters. >> For example, while the electric meter has easy access to mains power, >>the >> gas/water meters don't. >> In most instances, the gas/water service may be provided by a = completely >> different entity than the electric >> power utility. >> >> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >> backhaul were considered out of scope. >> >> Would the document lose technical integrity if the gas/water meter = were >> either removed or included as an optional. >> >> Regards >> >> >> >>>Could you please elaborate? >>>According to you, why should Gas and Water be removed from the draft? >>> >>>Thank you in advance, >>> >>>Nicolas. >>> >>>> Regards >>>> >>>> -- >>>> Bora Akyol, Pacific Northwest National Laboratory >>>> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>>> >>>> _______________________________________________ >>>> 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 prvs=21736f1ad=bora@pnnl.gov Wed Aug 31 09:33:01 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3255321F8C34 for ; Wed, 31 Aug 2011 09:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.187 X-Spam-Level: X-Spam-Status: No, score=-6.187 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZR8zKHzZFmhL for ; Wed, 31 Aug 2011 09:33:00 -0700 (PDT) Received: from emailgw04.pnl.gov (emailgw04.pnl.gov [192.101.109.35]) by ietfa.amsl.com (Postfix) with ESMTP id E1D4021F8C37 for ; Wed, 31 Aug 2011 09:32:59 -0700 (PDT) Received: from emailhub01.pnl.gov ([130.20.251.61]) by emailgw04.pnl.gov with ESMTP/TLS/AES128-SHA; 31 Aug 2011 09:34:30 -0700 Received: from Email05.pnl.gov ([130.20.251.70]) by emailhub01.pnl.gov ([130.20.251.61]) with mapi; Wed, 31 Aug 2011 09:34:30 -0700 From: "Akyol, Bora A" To: "Pascal Thubert (pthubert)" , Jorjeta Jetcheva Date: Wed, 31 Aug 2011 09:34:27 -0700 Thread-Topic: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Thread-Index: Acxn+9tahzOsl7x6TnqgnMSWFTeqzQ== Message-ID: In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D055AE297@XMB-AMS-107.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: D?jean Nicolas , "roll@ietf.org" Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 16:33:01 -0000 Hi Pascal There is nothing in the text that substantiates lower operational costs for the wireless mesh networks. If the customer (meter) density is such that you have 1-2 customers/acre (or less), then I don't think spatial reuse buys you anything. Once you figure in the OPEX of having to run these networks by the utilities versus having cellular backhaul (for example), the cost savings need to be carefully considered. Why do you think this one sentence is substantial to the rest of the draft? The draft is not about wireless mesh networks being best for AMI, it is about the applicability of ROLL working group products to AMI networks using wireless mesh technologies, yes? Regards --=20 Bora Akyol, Pacific Northwest National Laboratory +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov On 8/31/11 9:27 AM, "Pascal Thubert (pthubert)" wrote: >Hello Jorjeta and Bora: > >About this: > >< These > kinds of networks increase coverage and reduce installation cost, > time and complexity, as well as operational costs, as compared to > single-hop wireless networks, relying on a wireline or cellular > backhaul. > assertion. > >I'd think that the general benefit of meshing is the spatial reuse of the >medium - same thing for any switched fabric at the end of the day -. >This benefits most to environments where the medium is a constrained or >expensive resource. This is much is very well-known and justifies the >original text about cost savings. > >From there, the meshing/routing mechanism has to be designed in such a >fashion that it is simple to deploy, with the classical self-* properties. >A radio meshing/routing system will indeed be simpler to deploy because >as the intro says, it will be easier to guarantee an appropriate >coverage, which you cannot do at all times with one hop of wire (because >of movement) or cellular (because of dark zones). > >So for all I know, the quoted text is not unsubstantiated and asilye >justified for people of the art. I have no issue leaving the text as is >and I find it relevant. > >Cheers, > >Pascal > >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >Jetcheva, Jorjeta >Sent: mercredi 31 ao=FBt 2011 18:05 >To: Akyol, Bora A >Cc: D=E9jean Nicolas; roll@ietf.org >Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt > >Hello Bora, > >The text in this paragraph doesn't actually use the word "substantial", >and I think you meant "wireline", not "powerline". > >What would you consider to be a "substantiated" statement of the >applicability/benefits of mesh networks relative to other deployment >paradigms? > >Thanks, Jorjeta > >Jorjeta Jetcheva, Ph.D. >Principal Engineer, Architecture & Standards CTO Office Itron, Inc. > > >-----Original Message----- >From: Akyol, Bora A [mailto:bora@pnnl.gov] >Sent: Wednesday, August 31, 2011 8:40 AM >To: Jetcheva, Jorjeta >Cc: D?jean Nicolas; roll@ietf.org >Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt > > >Hi Jorjeta > >Sorry, I had two comments in my original email. One was regarding >gas/power meters and the second regarding the non-technical slant in the >introduction. >The modified paragraph that I proposed is related to the second point. > >To answer your question, I disagree with the unbsubstantiated statement >that multi-hop wireless mesh networks have substantial cost benefits >compared to either powerline or single-hop (e.g. cellular modems) >networks.=20 >I am not saying this is completely wrong, I am saying that this statement >does not belong in an IETF document since it has no relevance to ROLL >or the applicability of ROLL to AMI networks. I think the paragraph I >proposed is clear-cut and technically accurate without having a bias >towards the use of wireless mesh networks. > >Regards > >Bora > >-----Original Message----- >From: Jetcheva, Jorjeta [mailto:Jorjeta.Jetcheva@itron.com] >Sent: Wednesday, August 31, 2011 8:35 AM >To: Akyol, Bora A >Cc: D?jean Nicolas; roll@ietf.org >Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt > >Hello Bora, > >The paragraph you cited does not reference anything related to water or >gas meters which was the topic of your earlier comment and the discussion >that followed. Is this perhaps not the right paragraph or is this the >beginning of a new discussion? > >As far as the benefits of multi-hop networks over wireline or cellular >backhaul, I think that lower cost and deployment complexity are pretty >commonly cited. Do you disagree with this statement? > >Thanks, Jorjeta > >Jorjeta Jetcheva, Ph.D. >Principal Engineer, Architecture & Standards CTO Office Itron, Inc. > > >-----Original Message----- >From: Akyol, Bora A [mailto:bora@pnnl.gov] >Sent: Wednesday, August 31, 2011 8:09 AM >To: Nicolas DEJEAN >Cc: Jetcheva, Jorjeta; roll@ietf.org >Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt > > >Hi Nicolas > >Yes, we had a private email exchange off-list. > >I would like to suggest alternate wording for this paragraph as follows: > >ORIGINAL: > > Electric meters are often interconnected into multi-hop mesh > networks, each of which is connected to a backhaul network leading to > the utility network through a network aggregation point (NAP). These > kinds of networks increase coverage and reduce installation cost, > time and complexity, as well as operational costs, as compared to > single-hop wireless networks, relying on a wireline or cellular > backhaul. Each electric meter mesh typically has on the order of > several thousand wireless endpoints, with densities varying based on > the area and the terrain. Apartment buildings in urban centers may > have hundreds of meters in close proximity, whereas rural areas may >have sparse node distributions and include nodes that only have one or >two network neighbors. Paths in the mesh between a network device > and the nearest aggregation point may be composed of several hops or > even tens of hops. > > >ALTERNATE WORDING: > > >In one type of AMI network, electric meters are interconnected into >multi-hop mesh >networks, each of which is connected to a backhaul network leading to >the utility network through a network aggregation point (NAP). > >mesh> > >In a multi-hop mesh network, each electric meter mesh may have up to >several thousand wireless endpoints, with densities varying based on >the area and the terrain. Apartment buildings in urban centers may >have hundreds of meters in close proximity, whereas rural areas may >have sparse node distributions and include nodes that only have one or two >network neighbors. >Paths in the mesh between a network device >and the nearest aggregation point may be composed of several hops or >even tens of hops. > > > >What do you think? > >Thanks > > >--=20 >Bora Akyol, Pacific Northwest National Laboratory >+1 509 371 6682, bora@pnnl.gov, www.pnnl.gov > > > > >On 8/31/11 4:23 AM, "Nicolas DEJEAN" >wrote: > >>Hello Bora, >> >>Did Jorjeta answered your concerns about an AMI network considered as >>a backhaul for Gas and Water? >> >>Thank you in advance, >> >>Nicolas. >> >>2011/8/30 Jetcheva, Jorjeta : >>> Hello Bora, >>> >>>> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >>>> backhaul were considered out of scope. >>> >>> Actually AMI backhaul for gas and water meters is very much in scope as >>>per the NIST Wireless Guidelines (PAP2) work and the related >>>SG-Communications/SG-Net work. CSWG coordinates with the PAPs so they >>>should be aware of this. >>> >>> Jorjeta >>> >>> Jorjeta Jetcheva, Ph.D. >>> Principal Engineer, Architecture & Standards >>> CTO Office >>> Itron, Inc. >>> >>> >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >>>Akyol, Bora A >>> Sent: Tuesday, August 30, 2011 10:37 AM >>> To: Nicolas DEJEAN >>> Cc: roll@ietf.org >>> Subject: Re: [Roll] I-D Action: >>>draft-ietf-roll-applicability-ami-01.txt >>> >>> Hi Nicolas >>> >>> Thank you for your response. >>> >>> Please see my comments within >>> -- >>> Bora Akyol, Pacific Northwest National Laboratory >>> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>> >>> >>> >>> >>> On 8/30/11 1:25 AM, "Nicolas DEJEAN" >>> >>> wrote: >>> >>>>Hello Bora, >>>> >>>>2011/7/29 Akyol, Bora A : >>>>> I think the statement about AMI networks being used as an almost >>>>>general >>>>> purpose backhaul network for all other devices >>>>> is overreaching. I know there are some utilities that are looking >>>>>into >>>>> this, but a lot more that have shied away from >>>>> this vision. Secondly, there are a lot more AMI deployments not using >>>>> wireless mesh networks, e.g. using cellular modem, >>>>> powerline carrier, etc. >>>> >>>>I agree that all utilities are not looking into it. >>>>However this is one possible case that should be considered, isn't it? >>>>Could you please precise what you are expecting to be in the draft? >>> >>> I think the draft should be focusing on the applicability of ROLL from >>>a >>> technical front >>> without siting this one case as the only justification. >>> >>>> >>>>> >>>>> Is it possible to tone this "marketing" text Section 1.1. down and >>>>>also >>>>> potentially >>>>> remove Gas & Water meters from the scope of this document. >>>>> >>>> >>>>On our point of view, Gas and Water metering are part of AMI. >>> >>> This is not the widely-held view at least within the US electric >>>utility >>> community. >>> The gas and water meters have capabilities which are quite different >>>from >>> electric power meters. >>> For example, while the electric meter has easy access to mains power, >>>the >>> gas/water meters don't. >>> In most instances, the gas/water service may be provided by a >>>completely >>> different entity than the electric >>> power utility. >>> >>> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >>> backhaul were considered out of scope. >>> >>> Would the document lose technical integrity if the gas/water meter were >>> either removed or included as an optional. >>> >>> Regards >>> >>> >>> >>>>Could you please elaborate? >>>>According to you, why should Gas and Water be removed from the draft? >>>> >>>>Thank you in advance, >>>> >>>>Nicolas. >>>> >>>>> Regards >>>>> >>>>> -- >>>>> Bora Akyol, Pacific Northwest National Laboratory >>>>> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>>>> >>>>> _______________________________________________ >>>>> 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 jpv@cisco.com Wed Aug 31 09:38:16 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F38921F8CF4 for ; Wed, 31 Aug 2011 09:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDjwYozzbaJz for ; Wed, 31 Aug 2011 09:38:15 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 921A321F8CF0 for ; Wed, 31 Aug 2011 09:38:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=3054; q=dns/txt; s=iport; t=1314808786; x=1316018386; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=OhVMJG9H7J5QtKtajn5eEO+Z6y5GmwkoL84T+eRWUSs=; b=OJ3WwpDl/FA8sMXD+XCPr6I2rVXEPQ+FiYjOn/lIZycf0PKRPY5r9AZN 4aZ0ZMPOahRJgGxmy4fNG8U69PsFoefiMkbM1JI5kyTAUwUw/ZzbpDKPT Wl9x2mZ/cEcG+7VIEt/cgJMWCW0CLxKzkVcTTpVLJPWuFMt4vcB10MUoU 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkIANdiXk6rRDoH/2dsb2JhbABDqEp3DwEBgSgHAQEBAQIBAQEBDwEnNAsFCwsYLicwBhMZCYdQBJsOAZFKjXmFdWAEkyWFDgmLcg X-IronPort-AV: E=Sophos;i="4.68,308,1312156800"; d="scan'208";a="18202094" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-2.cisco.com with ESMTP; 31 Aug 2011 16:39:45 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7VGdjU8003484; Wed, 31 Aug 2011 16:39:45 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 31 Aug 2011 09:39:45 -0700 Received: from [10.60.114.226] ([10.60.114.226]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 31 Aug 2011 09:39:44 -0700 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: Date: Wed, 31 Aug 2011 18:39:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8CA251EF-2842-453A-964A-E3F30713917A@cisco.com> References: <1483809161.144962.1314763722334.JavaMail.root@mail05.pantherlink.uwm.edu> <4884.1314797912@marajade.sandelman.ca> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 31 Aug 2011 16:39:44.0793 (UTC) FILETIME=[96E54890:01CC67FC] Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 16:38:16 -0000 Dear Thomas, On Aug 31, 2011, at 5:54 PM, Thomas Heide Clausen wrote: > I think that this is somewhat going to the crux of what I was = referring to when I suggested updates/obsoletes RPL in case this (or, = any) compression scheme is introduced. >=20 > As I understood the original design scope of ROLL, as retained in the = charter, 802.15.4 was one of the (but, not the only) target L2's. It may = be that a less verbose message format is required for 802.15.4 than that = currently proposed in RPL - in fact, we've got some indications from our = testing that this is the case (even for stock RPL) to avoid = fragmentation. >=20 > However then the working group should fix the problem in RPL by = updating that specification, Once again, there is no fix to have.=20 Mukul is proposing an optional compression mechanism, currently = discussed by the WG, that's it. Thanks. JP. > rather than propose an alternative, incompatible message format as an = option which - as Michael has pointed out in this and previous messages = - necessitating writing/testing multiple different parsers, additional = signaling to ensure that in a given deployment messages are sent in the = "right" format (or, do we disallow heterogenous deployments?) etc. >=20 > I'm concerned that the WG, so early after (well, before) that RPL is = published as RFC feels the need to consider such "patches" to the = protocol. >=20 > Respectfully yours,=20 >=20 > Thomas >=20 > On Aug 31, 2011, at 15:38 , Michael Richardson wrote: >=20 >>=20 >>>>>>> "Mukul" =3D=3D Mukul Goyal writes: >> Mukul> I understand your preference for GHC scheme. As for our >> Mukul> scheme, it seems to me that you would like our scheme much >> Mukul> better if there is a way for a node to solicit >> Mukul> compressed/uncompressed DIOs. Is my understanding correct?=20= >> Mukul> This could be done by a simple DIS flag. >>=20 >> No, I wouldn't like that. I'd like not to have to write and test = two >> parsers for options, and I'd like the scheme not to fall apart when = we >> introduce another option type. >>=20 >> I will evaluate GHC method, and write a draft this long weekend with = my >> results. If anyone has sample RPL messages they want me to = consider,=20 >> I would appreciate a PCAP file, otherwise, I'll evaluate only my own. >> In particular, I need more examples of metric options. >>=20 >>=20 >> --=20 >> ] He who is tired of Weird Al is tired of life! | = firewalls [ >> ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net = architect[ >> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ = |device driver[ >> Kyoto Plus: watch the video = >> then sign the petition.=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Wed Aug 31 09:39:43 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3801221F8D64 for ; Wed, 31 Aug 2011 09:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.513 X-Spam-Level: X-Spam-Status: No, score=-110.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SL3tIziwQk1W for ; Wed, 31 Aug 2011 09:39:42 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id E64B421F8D29 for ; Wed, 31 Aug 2011 09:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=4261; q=dns/txt; s=iport; t=1314808873; x=1316018473; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=/XslVi8KLdPK7+nRQ0fQuCA0ZLKUsXrw/9zV34vZBzM=; b=WePwbe/Dqtn5VObc5mXntRRWgavIG8DpOg7qDdn0oiD31QVHPvcJ/fRc 14SMHF4DPNrTrXPVCHFU0675XxuVhfF4rPk3kpcBidMwIdmGV1KjV5mGb UkV0Dyd7bMxYyCmXV0HV7FVDyVTKTPcmDCe44ThfD6q2hMW1rvLydAGiI 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcBANdiXk5Io8UT/2dsb2JhbABDmGCPancPAQGBLwEBAQECAQEBAQ8BWwsFBwQLEQQBAQEuJygIBhMZCYdQBJsOAZFKjXmFdWAEkyWFDgmLcg X-IronPort-AV: E=Sophos;i="4.68,308,1312156800"; d="scan'208";a="52734394" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-2.cisco.com with ESMTP; 31 Aug 2011 16:41:10 +0000 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p7VGf8ct026608; Wed, 31 Aug 2011 16:41:08 GMT Received: from xfe-hkg-412.apac.cisco.com ([64.104.123.71]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Sep 2011 00:41:08 +0800 Received: from [10.60.114.226] ([10.60.114.226]) by xfe-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Sep 2011 00:41:07 +0800 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: JP Vasseur In-Reply-To: <1831033C-FE54-4B15-BC8B-B4C8E230AFD1@thomasclausen.org> Date: Wed, 31 Aug 2011 18:41:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0621F6C4-B7AA-4E04-9021-CE5CC9B8A888@cisco.com> References: <1593431155.140676.1314734802999.JavaMail.root@mail05.pantherlink.uwm.edu> <1831033C-FE54-4B15-BC8B-B4C8E230AFD1@thomasclausen.org> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 31 Aug 2011 16:41:07.0760 (UTC) FILETIME=[C8590B00:01CC67FC] Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 16:39:43 -0000 On Aug 31, 2011, at 5:55 PM, Thomas Heide Clausen wrote: > I would actually argue that RPL and P2P-RPL are two entirely different = protocols (albeit sharing some commonalities in the overall message = structure). >=20 > There are ways of making multiple routing protocols co-exist on the = same routers (and in the same network). However I am not sure that it is = such a good idea to do so in a LLN. >=20 > I've always found it odd that P2P traffic was not supported in RPL -- = and really, dog-leg routing through a DODAG root and using source = routing isn't (efficiently) supporting P2P. Thomas,=20 I cannot let you say this =85 you perfectly know that the core = specification of RPL supports P2P traffic. >=20 > In short, I do agree with Ulrich's logic. >=20 > Respectfully yours, >=20 > Thomas >=20 > On Aug 30, 2011, at 22:06 , Mukul Goyal wrote: >=20 >> By the same logic, you would argue that P2P-RPL would lead to = non-interoperable implementations since some devices would speak P2P-RPL = and others wont. >>=20 >> Thanks >> Mukul >>=20 >> ----- Original Message ----- >> From: "Ulrich Herberg" >> To: "Michael Richardson" >> Cc: "Mukul Goyal" , "roll WG" >> Sent: Tuesday, August 30, 2011 2:58:21 PM >> Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a = new ROLL WG document >>=20 >> I agree with Michael's concern that using GRRC could lead to = non-interoperable implementations, with some nodes "speaking" normal = RPL, some using GRRC. That might require some additional negotiation = between nodes, or worse, could lead to non-interoperable parts of the = network. That worries me.=20 >>=20 >> Ulrich=20 >>=20 >>=20 >> On Tue, Aug 30, 2011 at 12:53 PM, Michael Richardson < = mcr@sandelman.ca > wrote:=20 >>=20 >>=20 >>=20 >>>>>>> "Mukul" =3D=3D Mukul Goyal < mukul@uwm.edu > writes:=20 >> Mukul> I was wondering if you have the compression scheme described=20= >> Mukul> in draft-bormann-6lowpan-ghc in mind. I guess it will be=20 >> Mukul> useful to compare the compression achieved using the two=20 >> Mukul> schemes for the two examples described in=20 >> Mukul> draft-goyal-roll-rpl-compression. I think that compression=20= >> Mukul> achieved with draft-bormann scheme would vary with the = actual=20 >> Mukul> byte stream contained in the packet. There is ofcourse no=20 >> Mukul> such dependency in case of our scheme.=20 >>=20 >> yes, but the goyal-roll-rpl-compression (GRRC from now on, okay?) = scheme=20 >> will result in devices that support the compressed format only,=20 >> essentially creating an entirely new protocol.=20 >>=20 >> 6lowpan-ghc applies things as a layered approach, which means that = after=20 >> decompression, you still need a full RPL packet parser, which means = that=20 >> the RPL protocol can in fact evolve.=20 >>=20 >> goyal-roll-rpl-compression (GRRC) scheme will have to be revised each = time=20 >> there is an addition to the protocol, and will cause a flag day, as = no=20 >> node can use the new options until every node is upgraded, even if = the=20 >> nodes do not need to make use of the new options.=20 >>=20 >> In essence, the goyal-roll-rpl-compression is a fixed proprietary=20 >> system.=20 >>=20 >>=20 >>=20 >>=20 >> --=20 >> ] He who is tired of Weird Al is tired of life! | = firewalls [=20 >> ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net = architect[=20 >> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ = |device driver[=20 >> Kyoto Plus: watch the video < = http://www.youtube.com/watch?v=3Dkzx1ycLXQSE >=20 >> then sign the petition.=20 >> _______________________________________________=20 >> Roll mailing list=20 >> Roll@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/roll=20 >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From ietf@thomasclausen.org Wed Aug 31 09:55:45 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DC421F8DA5 for ; Wed, 31 Aug 2011 09:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2pIW87+YOey for ; Wed, 31 Aug 2011 09:55:44 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8BA21F8D9E for ; Wed, 31 Aug 2011 09:55:44 -0700 (PDT) Received: from sphinx.lix.polytechnique.fr ([129.104.11.1] helo=[10.0.1.5]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Qyo6D-0005dx-Rj; Wed, 31 Aug 2011 16:57:14 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 129.104.11.1 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/MDEv9Iec9Ipu40XDL7eZS Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Thomas Heide Clausen In-Reply-To: <0621F6C4-B7AA-4E04-9021-CE5CC9B8A888@cisco.com> Date: Wed, 31 Aug 2011 18:57:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <609341E6-F4B1-483B-8306-05265023C840@thomasclausen.org> References: <1593431155.140676.1314734802999.JavaMail.root@mail05.pantherlink.uwm.edu> <1831033C-FE54-4B15-BC8B-B4C8E230AFD1@thomasclausen.org> <0621F6C4-B7AA-4E04-9021-CE5CC9B8A888@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1244.3) Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 16:55:45 -0000 On Aug 31, 2011, at 18:41 , JP Vasseur wrote: >=20 > On Aug 31, 2011, at 5:55 PM, Thomas Heide Clausen wrote: >=20 >> I would actually argue that RPL and P2P-RPL are two entirely = different protocols (albeit sharing some commonalities in the overall = message structure). >>=20 >> There are ways of making multiple routing protocols co-exist on the = same routers (and in the same network). However I am not sure that it is = such a good idea to do so in a LLN. >>=20 >> I've always found it odd that P2P traffic was not supported in RPL -- = and really, dog-leg routing through a DODAG root and using source = routing isn't (efficiently) supporting P2P. >=20 > Thomas,=20 >=20 > I cannot let you say this =85 you perfectly know that the core = specification of RPL supports P2P traffic. Ah, but you must, JP, you must.=20 Note that I said in the above that RPL supports P2P traffic by way of = dog-leg routing through the DODAG root, then source routing -- that's = the _only_ way P2P is supported, guaranteed to work across all the = different RPL-flavors (storing/non-storing with/without RPL-P2P, =85) = that the WG is exploring. I suppose that if the incurred route-stretch, increased over-the-wire = overhead and number of transmissions (across a lossy medium, increasing = loss probability) are of no concern, then this is sufficient support=85=85= ?=20 Respectfully yours, Thomas >>=20 >> In short, I do agree with Ulrich's logic. >>=20 >> Respectfully yours, >>=20 >> Thomas >>=20 >> On Aug 30, 2011, at 22:06 , Mukul Goyal wrote: >>=20 >>> By the same logic, you would argue that P2P-RPL would lead to = non-interoperable implementations since some devices would speak P2P-RPL = and others wont. >>>=20 >>> Thanks >>> Mukul >>>=20 >>> ----- Original Message ----- >>> From: "Ulrich Herberg" >>> To: "Michael Richardson" >>> Cc: "Mukul Goyal" , "roll WG" >>> Sent: Tuesday, August 30, 2011 2:58:21 PM >>> Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as = a new ROLL WG document >>>=20 >>> I agree with Michael's concern that using GRRC could lead to = non-interoperable implementations, with some nodes "speaking" normal = RPL, some using GRRC. That might require some additional negotiation = between nodes, or worse, could lead to non-interoperable parts of the = network. That worries me.=20 >>>=20 >>> Ulrich=20 >>>=20 >>>=20 >>> On Tue, Aug 30, 2011 at 12:53 PM, Michael Richardson < = mcr@sandelman.ca > wrote:=20 >>>=20 >>>=20 >>>=20 >>>>>>>> "Mukul" =3D=3D Mukul Goyal < mukul@uwm.edu > writes:=20 >>> Mukul> I was wondering if you have the compression scheme described=20= >>> Mukul> in draft-bormann-6lowpan-ghc in mind. I guess it will be=20 >>> Mukul> useful to compare the compression achieved using the two=20 >>> Mukul> schemes for the two examples described in=20 >>> Mukul> draft-goyal-roll-rpl-compression. I think that compression=20= >>> Mukul> achieved with draft-bormann scheme would vary with the = actual=20 >>> Mukul> byte stream contained in the packet. There is ofcourse no=20 >>> Mukul> such dependency in case of our scheme.=20 >>>=20 >>> yes, but the goyal-roll-rpl-compression (GRRC from now on, okay?) = scheme=20 >>> will result in devices that support the compressed format only,=20 >>> essentially creating an entirely new protocol.=20 >>>=20 >>> 6lowpan-ghc applies things as a layered approach, which means that = after=20 >>> decompression, you still need a full RPL packet parser, which means = that=20 >>> the RPL protocol can in fact evolve.=20 >>>=20 >>> goyal-roll-rpl-compression (GRRC) scheme will have to be revised = each time=20 >>> there is an addition to the protocol, and will cause a flag day, as = no=20 >>> node can use the new options until every node is upgraded, even if = the=20 >>> nodes do not need to make use of the new options.=20 >>>=20 >>> In essence, the goyal-roll-rpl-compression is a fixed proprietary=20 >>> system.=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>> ] He who is tired of Weird Al is tired of life! | = firewalls [=20 >>> ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net = architect[=20 >>> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ = |device driver[=20 >>> Kyoto Plus: watch the video < = http://www.youtube.com/watch?v=3Dkzx1ycLXQSE >=20 >>> then sign the petition.=20 >>> _______________________________________________=20 >>> Roll mailing list=20 >>> Roll@ietf.org=20 >>> https://www.ietf.org/mailman/listinfo/roll=20 >>>=20 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 From mcr@sandelman.ca Wed Aug 31 10:04:36 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8494321F8DB8 for ; Wed, 31 Aug 2011 10:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbmqPPqetxpo for ; Wed, 31 Aug 2011 10:04:36 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6E421F8DB6 for ; Wed, 31 Aug 2011 10:04:31 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 53EAD342BD; Wed, 31 Aug 2011 13:05:22 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 6534D98C76; Wed, 31 Aug 2011 13:06:32 -0400 (EDT) From: Michael Richardson To: Mukul Goyal In-Reply-To: <334091358.146823.1314798695502.JavaMail.root@mail05.pantherlink.uwm.edu> References: <334091358.146823.1314798695502.JavaMail.root@mail05.pantherlink.uwm.edu> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Wed, 31 Aug 2011 13:06:32 -0400 Message-ID: <1168.1314810392@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 17:04:36 -0000 >>>>> "Mukul" == Mukul Goyal writes: Mukul> introduce another option type. Mukul> This is the part that I dont understand. Why does our scheme Mukul> fall apart when a new option is introduced? Because, when the new option is introduced: 1) I need to know if a node supports it in regular or compressed format, assuming that a compressed format is defined also defined. This means that we had better define a compressed format with every new option! But, why do that at all? Just make sure that it is already efficiently encoded. 2) if the presence of the new option blows the MTU, then there is significant pressure to never include that option, ever. 3) if these compressed formats work so well, then let's throw out rpl-19, and use the old formats, and the code involved. Problem #2 is particularly important, and has caused delays for new things. The new thing is not implemented as efficiently, and as a result, even turning it on slows down the other parts. For instance on a number of router platforms, for instance, IPv6 forwarding was not in ASIC, but in the slow path. This meant that even a small (1-2%) mix of IPv6 traffic would degrade ipv4 service. While we haven't even reached that level today, just the risk of degradation caused IPv6 to stay disabled. I started looking at doing some kind of straight huffman-type encoding, perhaps using a static (pre-distributed) tree. I'm not an expert here. This kind of thing could possibly be put into hardware, and would apply to all future extensions. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From jpv@cisco.com Wed Aug 31 10:05:56 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4410E21F8DB9 for ; Wed, 31 Aug 2011 10:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.112 X-Spam-Level: X-Spam-Status: No, score=-109.112 tagged_above=-999 required=5 tests=[AWL=1.486, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsEL9ZWIwJ3V for ; Wed, 31 Aug 2011 10:05:55 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 537CC21F8DB8 for ; Wed, 31 Aug 2011 10:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=13819; q=dns/txt; s=iport; t=1314810445; x=1316020045; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=w/jRgudRo8XHePj8g7GBAJ2mFG1iyOkG5dBN/RFkrMc=; b=Dlt411HvWE04Y8X2LVL3yl+LFhTSq6Ymg/zK6IzuQ3lY/uYZozIJx6yq u46VgXvECQ+R1zP7/lPYMhEnMStOICOlnNSS84WbJIou/6rqMa4Wh4Cne o+49I170RA1mmB8B5EDBzhP3ip2FFCRKCzCoupSOBLdIx8mddQar6zhoD E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmMBAGZoXk5Io8US/2dsb2JhbABDhzWRK49qdw8BAYEoBwEBAQECAQEBAQ8BGkECCQwECxEEAQEBLicoCAYTGQmHUASbBQGRSo16hXVgBJMlhQ4JikqBKA X-IronPort-AV: E=Sophos;i="4.68,308,1312156800"; d="scan'208,217";a="113408512" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 31 Aug 2011 17:05:21 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7VH5Lh3022083; Wed, 31 Aug 2011 17:05:21 GMT Received: from xfe-bgl-412.cisco.com ([72.163.129.200]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 31 Aug 2011 22:35:21 +0530 Received: from [10.60.114.226] ([10.60.114.226]) by xfe-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 31 Aug 2011 22:35:20 +0530 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_F6455659-A0E3-45BF-A5B6-84B2CA538680" From: JP Vasseur In-Reply-To: <609341E6-F4B1-483B-8306-05265023C840@thomasclausen.org> Date: Wed, 31 Aug 2011 19:05:18 +0200 Message-Id: References: <1593431155.140676.1314734802999.JavaMail.root@mail05.pantherlink.uwm.edu> <1831033C-FE54-4B15-BC8B-B4C8E230AFD1@thomasclausen.org> <0621F6C4-B7AA-4E04-9021-CE5CC9B8A888@cisco.com> <609341E6-F4B1-483B-8306-05265023C840@thomasclausen.org> To: "Thomas Heide Clausen" X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 31 Aug 2011 17:05:20.0878 (UTC) FILETIME=[2A7940E0:01CC6800] Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 17:05:56 -0000 --Apple-Mail=_F6455659-A0E3-45BF-A5B6-84B2CA538680 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 31, 2011, at 6:57 PM, Thomas Heide Clausen wrote: >=20 > On Aug 31, 2011, at 18:41 , JP Vasseur wrote: >=20 > > > > On Aug 31, 2011, at 5:55 PM, Thomas Heide Clausen wrote: > > > >> I would actually argue that RPL and P2P-RPL are two entirely = different protocols (albeit sharing some commonalities in the overall = message structure). > >> > >> There are ways of making multiple routing protocols co-exist on the = same routers (and in the same network). However I am not sure that it is = such a good idea to do so in a LLN. > >> > >> I've always found it odd that P2P traffic was not supported in RPL = -- and really, dog-leg routing through a DODAG root and using source = routing isn't (efficiently) supporting P2P. > > > > Thomas, > > > > I cannot let you say this =85 you perfectly know that the core = specification of RPL supports P2P traffic. >=20 > Ah, but you must, JP, you must. >=20 > Note that I said in the above that RPL supports P2P traffic by way of = dog-leg routing through the DODAG root, then source routing -- that's = the _only_ way P2P is supported, guaranteed to work across all the = different RPL-flavors (storing/non-storing with/without RPL-P2P, =85) = that the WG is exploring. >=20 Well the sentence was, to say the least, strangely worded =85 As you = know, you go via the root only if you deploy non-storing. So I guess that we agree Kind Regards. JP. >=20 > I suppose that if the incurred route-stretch, increased over-the-wire = overhead and number of transmissions (across a lossy medium, increasing = loss probability) are of no concern, then this is sufficient support=85=85= ? >=20 > Respectfully yours, >=20 > Thomas >=20 >=20 > >> > >> In short, I do agree with Ulrich's logic. > >> > >> Respectfully yours, > >> > >> Thomas > >> > >> On Aug 30, 2011, at 22:06 , Mukul Goyal wrote: > >> > >>> By the same logic, you would argue that P2P-RPL would lead to = non-interoperable implementations since some devices would speak P2P-RPL = and others wont. > >>> > >>> Thanks > >>> Mukul > >>> > >>> ----- Original Message ----- > >>> From: "Ulrich Herberg" > >>> To: "Michael Richardson" > >>> Cc: "Mukul Goyal" , "roll WG" > >>> Sent: Tuesday, August 30, 2011 2:58:21 PM > >>> Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression = as a new ROLL WG document > >>> > >>> I agree with Michael's concern that using GRRC could lead to = non-interoperable implementations, with some nodes "speaking" normal = RPL, some using GRRC. That might require some additional negotiation = between nodes, or worse, could lead to non-interoperable parts of the = network. That worries me. > >>> > >>> Ulrich > >>> > >>> > >>> On Tue, Aug 30, 2011 at 12:53 PM, Michael Richardson < = mcr@sandelman.ca > wrote: > >>> > >>> > >>> > >>>>>>>> "Mukul" =3D=3D Mukul Goyal < mukul@uwm.edu > writes: > >>> Mukul> I was wondering if you have the compression scheme = described > >>> Mukul> in draft-bormann-6lowpan-ghc in mind. I guess it will be > >>> Mukul> useful to compare the compression achieved using the two > >>> Mukul> schemes for the two examples described in > >>> Mukul> draft-goyal-roll-rpl-compression. I think that compression > >>> Mukul> achieved with draft-bormann scheme would vary with the = actual > >>> Mukul> byte stream contained in the packet. There is ofcourse no > >>> Mukul> such dependency in case of our scheme. > >>> > >>> yes, but the goyal-roll-rpl-compression (GRRC from now on, okay?) = scheme > >>> will result in devices that support the compressed format only, > >>> essentially creating an entirely new protocol. > >>> > >>> 6lowpan-ghc applies things as a layered approach, which means that = after > >>> decompression, you still need a full RPL packet parser, which = means that > >>> the RPL protocol can in fact evolve. > >>> > >>> goyal-roll-rpl-compression (GRRC) scheme will have to be revised = each time > >>> there is an addition to the protocol, and will cause a flag day, = as no > >>> node can use the new options until every node is upgraded, even if = the > >>> nodes do not need to make use of the new options. > >>> > >>> In essence, the goyal-roll-rpl-compression is a fixed proprietary > >>> system. > >>> > >>> > >>> > >>> > >>> -- > >>> ] He who is tired of Weird Al is tired of life! | = firewalls [ > >>> ] Michael Richardson, Sandelman Software Works, Ottawa, ON = |net architect[ > >>> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ = |device driver[ > >>> Kyoto Plus: watch the video < = http://www.youtube.com/watch?v=3Dkzx1ycLXQSE > > >>> then sign the petition. > >>> _______________________________________________ > >>> 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 > > >=20 >=20 --Apple-Mail=_F6455659-A0E3-45BF-A5B6-84B2CA538680 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new = ROLL WG document

On Aug 31, 2011, at 18:41 , JP Vasseur = wrote:

>
> On Aug 31, 2011, at 5:55 PM, Thomas Heide Clausen wrote:
>
>> I would actually argue that RPL and P2P-RPL are two entirely = different protocols (albeit sharing some commonalities in the overall = message structure).
>>
>> There are ways of making multiple routing protocols co-exist on = the same routers (and in the same network). However I am not sure that = it is such  a good idea to do so in a LLN.
>>
>> I've always found it odd that P2P traffic was not supported in = RPL -- and really, dog-leg routing through a DODAG root and using source = routing isn't (efficiently) supporting P2P.
>
> Thomas,
>
> I cannot let you say this =85 you perfectly know that the core = specification of RPL supports P2P traffic.

Ah, but you must, JP, you must.

Note that I said in the above that RPL supports P2P traffic by way of = dog-leg routing through the DODAG root, then source routing -- that's = the _only_ way P2P is supported, guaranteed to work across all the = different RPL-flavors (storing/non-storing with/without RPL-P2P, =85) = that the WG is exploring.

Well the = sentence was, to say the least, strangely worded =85 As you know, you go = via the root only if you deploy non-storing.

So = I guess that we agree

Kind = Regards.

JP.


I suppose that if the incurred route-stretch, increased over-the-wire = overhead and number of transmissions (across a lossy medium, increasing = loss probability) are of no concern, then this is sufficient = support=85=85?

Respectfully yours,

Thomas


>>
>> In short, I do agree with Ulrich's logic.
>>
>> Respectfully yours,
>>
>> Thomas
>>
>> On Aug 30, 2011, at 22:06 , Mukul Goyal wrote:
>>
>>> By the same logic, you would argue that P2P-RPL would lead = to non-interoperable implementations since some devices would speak = P2P-RPL and others wont.
>>>
>>> Thanks
>>> Mukul
>>>
>>> ----- Original Message -----
>>> From: "Ulrich Herberg" <ulrich@herberg.name>
>>> To: "Michael Richardson" <mcr@sandelman.ca>
>>> Cc: "Mukul Goyal" <mukul@uwm.edu>, "roll WG" <roll@ietf.org>
>>> Sent: Tuesday, August 30, 2011 2:58:21 PM
>>> Subject: Re: [Roll] Adoption of = draft-goyal-roll-rpl-compression as a new ROLL WG document
>>>
>>> I agree with Michael's concern that using GRRC could lead = to non-interoperable implementations, with some nodes "speaking" normal = RPL, some using GRRC. That might require some additional negotiation = between nodes, or worse, could lead to non-interoperable parts of the = network. That worries me.
>>>
>>> Ulrich
>>>
>>>
>>> On Tue, Aug 30, 2011 at 12:53 PM, Michael Richardson < = mcr@sandelman.ca > wrote:
>>>
>>>
>>>
>>>>>>>> "Mukul" =3D=3D Mukul Goyal < mukul@uwm.edu > writes:
>>>  Mukul> I was wondering if you have the compression = scheme described
>>>  Mukul> in draft-bormann-6lowpan-ghc in mind. I = guess it will be
>>>  Mukul> useful to compare the compression achieved = using the two
>>>  Mukul> schemes for the two examples described = in
>>>  Mukul> draft-goyal-roll-rpl-compression. I think = that compression
>>>  Mukul> achieved with draft-bormann scheme would = vary with the actual
>>>  Mukul> byte stream contained in the packet. There = is ofcourse no
>>>  Mukul> such dependency in case of our scheme.
>>>
>>> yes, but the goyal-roll-rpl-compression (GRRC from now on, = okay?) scheme
>>> will result in devices that support the compressed format = only,
>>> essentially creating an entirely new protocol.
>>>
>>> 6lowpan-ghc applies things as a layered approach, which = means that after
>>> decompression, you still need a full RPL packet parser, = which means that
>>> the RPL protocol can in fact evolve.
>>>
>>> goyal-roll-rpl-compression (GRRC) scheme will have to be = revised each time
>>> there is an addition to the protocol, and will cause a flag = day, as no
>>> node can use the new options until every node is upgraded, = even if the
>>> nodes do not need to make use of the new options.
>>>
>>> In essence, the goyal-roll-rpl-compression is a fixed = proprietary
>>> system.
>>>
>>>
>>>
>>>
>>> --
>>> ]       He who is tired of = Weird Al is tired of = life!           = |  firewalls  [
>>> ]   Michael Richardson, Sandelman Software Works, = Ottawa, ON    |net architect[
>>> ] mcr@sandelman.ottawa.on.ca = http://www.sandelman.ottawa.on= .ca/ |device driver[
>>> Kyoto Plus: watch the video < http://www.youtube.c= om/watch?v=3Dkzx1ycLXQSE >
= >>>          &n= bsp;          then sign the = petition.
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/m= ailman/listinfo/roll
>>>
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/m= ailman/listinfo/roll
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/m= ailman/listinfo/roll
>


= --Apple-Mail=_F6455659-A0E3-45BF-A5B6-84B2CA538680-- From ietf@thomasclausen.org Wed Aug 31 10:07:29 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4989121F8DD2 for ; Wed, 31 Aug 2011 10:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iE8mG72vwC29 for ; Wed, 31 Aug 2011 10:07:28 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id EB11D21F8BF4 for ; Wed, 31 Aug 2011 10:07:27 -0700 (PDT) Received: from sphinx.lix.polytechnique.fr ([129.104.11.1] helo=[10.0.1.5]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1QyoHW-000BXc-0X; Wed, 31 Aug 2011 17:08:54 +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: U2FsdGVkX197GbshDNvSFP4SkYAGELJv Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_3E1590E5-0198-4BF2-8F24-8C0BEE039C38" From: Thomas Heide Clausen In-Reply-To: Date: Wed, 31 Aug 2011 19:08:50 +0200 Message-Id: <0F84189A-987B-47A0-A732-9668F8469BAF@thomasclausen.org> References: <1593431155.140676.1314734802999.JavaMail.root@mail05.pantherlink.uwm.edu> <1831033C-FE54-4B15-BC8B-B4C8E230AFD1@thomasclausen.org> <0621F6C4-B7AA-4E04-9021-CE5CC9B8A888@cisco.com> <609341E6-F4B1-483B-8306-05265023C840@thomasclausen.org> To: JP Vasseur X-Mailer: Apple Mail (2.1244.3) Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 17:07:29 -0000 --Apple-Mail=_3E1590E5-0198-4BF2-8F24-8C0BEE039C38 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 31, 2011, at 19:05 , JP Vasseur wrote: >=20 > On Aug 31, 2011, at 6:57 PM, Thomas Heide Clausen wrote: >=20 >>=20 >> On Aug 31, 2011, at 18:41 , JP Vasseur wrote: >>=20 >> > >> > On Aug 31, 2011, at 5:55 PM, Thomas Heide Clausen wrote: >> > >> >> I would actually argue that RPL and P2P-RPL are two entirely = different protocols (albeit sharing some commonalities in the overall = message structure). >> >> >> >> There are ways of making multiple routing protocols co-exist on = the same routers (and in the same network). However I am not sure that = it is such a good idea to do so in a LLN. >> >> >> >> I've always found it odd that P2P traffic was not supported in RPL = -- and really, dog-leg routing through a DODAG root and using source = routing isn't (efficiently) supporting P2P. >> > >> > Thomas, >> > >> > I cannot let you say this =85 you perfectly know that the core = specification of RPL supports P2P traffic. >>=20 >> Ah, but you must, JP, you must. >>=20 >> Note that I said in the above that RPL supports P2P traffic by way of = dog-leg routing through the DODAG root, then source routing -- that's = the _only_ way P2P is supported, guaranteed to work across all the = different RPL-flavors (storing/non-storing with/without RPL-P2P, =85) = that the WG is exploring. >>=20 > Well the sentence was, to say the least, strangely worded =85 As you = know, you go via the root only if you deploy non-storing. >=20 Well, given the state requirements for storing-mode in networks larger = than a few handful of routers, non-storing mode seems to be the only = realistic choice for the lions share of deployments that I am aware of.=20= Thus, dog-leg-source-routing is pretty much the only viable option - and = you must admit that it's not a particularly elegant or efficient option = at that? Thomas > So I guess that we agree >=20 > Kind Regards. >=20 > JP. >>=20 >> I suppose that if the incurred route-stretch, increased over-the-wire = overhead and number of transmissions (across a lossy medium, increasing = loss probability) are of no concern, then this is sufficient support=85=85= ? >>=20 >> Respectfully yours, >>=20 >> Thomas >>=20 >>=20 >> >> >> >> In short, I do agree with Ulrich's logic. >> >> >> >> Respectfully yours, >> >> >> >> Thomas >> >> >> >> On Aug 30, 2011, at 22:06 , Mukul Goyal wrote: >> >> >> >>> By the same logic, you would argue that P2P-RPL would lead to = non-interoperable implementations since some devices would speak P2P-RPL = and others wont. >> >>> >> >>> Thanks >> >>> Mukul >> >>> >> >>> ----- Original Message ----- >> >>> From: "Ulrich Herberg" >> >>> To: "Michael Richardson" >> >>> Cc: "Mukul Goyal" , "roll WG" >> >>> Sent: Tuesday, August 30, 2011 2:58:21 PM >> >>> Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression = as a new ROLL WG document >> >>> >> >>> I agree with Michael's concern that using GRRC could lead to = non-interoperable implementations, with some nodes "speaking" normal = RPL, some using GRRC. That might require some additional negotiation = between nodes, or worse, could lead to non-interoperable parts of the = network. That worries me. >> >>> >> >>> Ulrich >> >>> >> >>> >> >>> On Tue, Aug 30, 2011 at 12:53 PM, Michael Richardson < = mcr@sandelman.ca > wrote: >> >>> >> >>> >> >>> >> >>>>>>>> "Mukul" =3D=3D Mukul Goyal < mukul@uwm.edu > writes: >> >>> Mukul> I was wondering if you have the compression scheme = described >> >>> Mukul> in draft-bormann-6lowpan-ghc in mind. I guess it will be >> >>> Mukul> useful to compare the compression achieved using the two >> >>> Mukul> schemes for the two examples described in >> >>> Mukul> draft-goyal-roll-rpl-compression. I think that = compression >> >>> Mukul> achieved with draft-bormann scheme would vary with the = actual >> >>> Mukul> byte stream contained in the packet. There is ofcourse no >> >>> Mukul> such dependency in case of our scheme. >> >>> >> >>> yes, but the goyal-roll-rpl-compression (GRRC from now on, okay?) = scheme >> >>> will result in devices that support the compressed format only, >> >>> essentially creating an entirely new protocol. >> >>> >> >>> 6lowpan-ghc applies things as a layered approach, which means = that after >> >>> decompression, you still need a full RPL packet parser, which = means that >> >>> the RPL protocol can in fact evolve. >> >>> >> >>> goyal-roll-rpl-compression (GRRC) scheme will have to be revised = each time >> >>> there is an addition to the protocol, and will cause a flag day, = as no >> >>> node can use the new options until every node is upgraded, even = if the >> >>> nodes do not need to make use of the new options. >> >>> >> >>> In essence, the goyal-roll-rpl-compression is a fixed proprietary >> >>> system. >> >>> >> >>> >> >>> >> >>> >> >>> -- >> >>> ] He who is tired of Weird Al is tired of life! | = firewalls [ >> >>> ] Michael Richardson, Sandelman Software Works, Ottawa, ON = |net architect[ >> >>> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ = |device driver[ >> >>> Kyoto Plus: watch the video < = http://www.youtube.com/watch?v=3Dkzx1ycLXQSE > >> >>> then sign the petition. >> >>> _______________________________________________ >> >>> 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 >> > >>=20 >>=20 >=20 --Apple-Mail=_3E1590E5-0198-4BF2-8F24-8C0BEE039C38 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

On Aug 31, 2011, = at 6:57 PM, Thomas Heide Clausen wrote:

Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new = ROLL WG document

On Aug 31, 2011, at 18:41 , JP Vasseur = wrote:

>
> On Aug 31, 2011, at 5:55 PM, Thomas Heide Clausen wrote:
>
>> I would actually argue that RPL and P2P-RPL are two entirely = different protocols (albeit sharing some commonalities in the overall = message structure).
>>
>> There are ways of making multiple routing protocols co-exist on = the same routers (and in the same network). However I am not sure that = it is such  a good idea to do so in a LLN.
>>
>> I've always found it odd that P2P traffic was not supported in = RPL -- and really, dog-leg routing through a DODAG root and using source = routing isn't (efficiently) supporting P2P.
>
> Thomas,
>
> I cannot let you say this =85 you perfectly know that the core = specification of RPL supports P2P traffic.

Ah, but you must, JP, you must.

Note that I said in the above that RPL supports P2P traffic by way of = dog-leg routing through the DODAG root, then source routing -- that's = the _only_ way P2P is supported, guaranteed to work across all the = different RPL-flavors (storing/non-storing with/without RPL-P2P, =85) = that the WG is exploring.

Well the = sentence was, to say the least, strangely worded =85 As you know, you go = via the root only if you deploy = non-storing.


W= ell, given the state requirements for storing-mode in networks larger = than a few handful of routers, non-storing mode seems to be the only = realistic choice for the lions share of deployments that I am aware = of. 

Thus, dog-leg-source-routing is = pretty much the only viable option - and you must admit that it's not a = particularly elegant or efficient option at = that?

Thomas

So I guess = that we agree

Kind = Regards.

JP.


I suppose that if the incurred route-stretch, increased over-the-wire = overhead and number of transmissions (across a lossy medium, increasing = loss probability) are of no concern, then this is sufficient = support=85=85?

Respectfully yours,

Thomas


>>
>> In short, I do agree with Ulrich's logic.
>>
>> Respectfully yours,
>>
>> Thomas
>>
>> On Aug 30, 2011, at 22:06 , Mukul Goyal wrote:
>>
>>> By the same logic, you would argue that P2P-RPL would lead = to non-interoperable implementations since some devices would speak = P2P-RPL and others wont.
>>>
>>> Thanks
>>> Mukul
>>>
>>> ----- Original Message -----
>>> From: "Ulrich Herberg" <ulrich@herberg.name>
>>> To: "Michael Richardson" <mcr@sandelman.ca>
>>> Cc: "Mukul Goyal" <mukul@uwm.edu>, "roll WG" <roll@ietf.org>
>>> Sent: Tuesday, August 30, 2011 2:58:21 PM
>>> Subject: Re: [Roll] Adoption of = draft-goyal-roll-rpl-compression as a new ROLL WG document
>>>
>>> I agree with Michael's concern that using GRRC could lead = to non-interoperable implementations, with some nodes "speaking" normal = RPL, some using GRRC. That might require some additional negotiation = between nodes, or worse, could lead to non-interoperable parts of the = network. That worries me.
>>>
>>> Ulrich
>>>
>>>
>>> On Tue, Aug 30, 2011 at 12:53 PM, Michael Richardson < = mcr@sandelman.ca > wrote:
>>>
>>>
>>>
>>>>>>>> "Mukul" =3D=3D Mukul Goyal < mukul@uwm.edu > writes:
>>>  Mukul> I was wondering if you have the compression = scheme described
>>>  Mukul> in draft-bormann-6lowpan-ghc in mind. I = guess it will be
>>>  Mukul> useful to compare the compression achieved = using the two
>>>  Mukul> schemes for the two examples described = in
>>>  Mukul> draft-goyal-roll-rpl-compression. I think = that compression
>>>  Mukul> achieved with draft-bormann scheme would = vary with the actual
>>>  Mukul> byte stream contained in the packet. There = is ofcourse no
>>>  Mukul> such dependency in case of our scheme.
>>>
>>> yes, but the goyal-roll-rpl-compression (GRRC from now on, = okay?) scheme
>>> will result in devices that support the compressed format = only,
>>> essentially creating an entirely new protocol.
>>>
>>> 6lowpan-ghc applies things as a layered approach, which = means that after
>>> decompression, you still need a full RPL packet parser, = which means that
>>> the RPL protocol can in fact evolve.
>>>
>>> goyal-roll-rpl-compression (GRRC) scheme will have to be = revised each time
>>> there is an addition to the protocol, and will cause a flag = day, as no
>>> node can use the new options until every node is upgraded, = even if the
>>> nodes do not need to make use of the new options.
>>>
>>> In essence, the goyal-roll-rpl-compression is a fixed = proprietary
>>> system.
>>>
>>>
>>>
>>>
>>> --
>>> ]       He who is tired of = Weird Al is tired of = life!           = |  firewalls  [
>>> ]   Michael Richardson, Sandelman Software Works, = Ottawa, ON    |net architect[
>>> ] mcr@sandelman.ottawa.on.ca = http://www.sandelman.ottawa.on= .ca/ |device driver[
>>> Kyoto Plus: watch the video < http://www.youtube.c= om/watch?v=3Dkzx1ycLXQSE >
= >>>          &n= bsp;          then sign the = petition.
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/m= ailman/listinfo/roll
>>>
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/m= ailman/listinfo/roll
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/m= ailman/listinfo/roll
>



= --Apple-Mail=_3E1590E5-0198-4BF2-8F24-8C0BEE039C38-- From jpv@cisco.com Wed Aug 31 10:11:26 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F0121F85B5 for ; Wed, 31 Aug 2011 10:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.261 X-Spam-Level: X-Spam-Status: No, score=-109.261 tagged_above=-999 required=5 tests=[AWL=1.337, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGMESO4TP0GQ for ; Wed, 31 Aug 2011 10:11:22 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8267721F8A66 for ; Wed, 31 Aug 2011 10:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=16650; q=dns/txt; s=iport; t=1314810772; x=1316020372; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=S61Z7O/Nl769KaXoSpdkiZzF6mqErTefPZohQQ+JgD0=; b=cw46GhfupCdeGcKagVPMnugv8raJg7ufKZ0Q8N+/MJkooVHidIcHYb2X s+Ffzv++ElqY/NzShJi6HZQfp66bGRCiVw4Uz8stgjytGl2IpwUsf+BBv fYpv1nDlvOJGCsam9W7IXHylDlp1bI/9guDXUdWxlYNniKgY5IUfTiPVj c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgBAA1qXk5Io8US/2dsb2JhbABDhzWRLo9qdw8BgSkHAQEBAQIBAQEBDwEaQQIJDAQLEQQBAQEuJygIBhMZCYdQBJp+AZFKjXqFdWAEkyWFDgmKSoEo X-IronPort-AV: E=Sophos;i="4.68,308,1312156800"; d="scan'208,217";a="52737056" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 31 Aug 2011 17:10:49 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7VHAnx7022764; Wed, 31 Aug 2011 17:10:49 GMT Received: from xfe-bgl-412.cisco.com ([72.163.129.200]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 31 Aug 2011 22:40:49 +0530 Received: from [10.60.114.226] ([10.60.114.226]) by xfe-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 31 Aug 2011 22:40:48 +0530 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_768C6C46-4366-48D9-B0DC-C1AC7912403F" From: JP Vasseur In-Reply-To: <0F84189A-987B-47A0-A732-9668F8469BAF@thomasclausen.org> Date: Wed, 31 Aug 2011 19:10:46 +0200 Message-Id: <4598998E-F7F6-4469-8977-BD49B5D7ECF7@cisco.com> References: <1593431155.140676.1314734802999.JavaMail.root@mail05.pantherlink.uwm.edu> <1831033C-FE54-4B15-BC8B-B4C8E230AFD1@thomasclausen.org> <0621F6C4-B7AA-4E04-9021-CE5CC9B8A888@cisco.com> <609341E6-F4B1-483B-8306-05265023C840@thomasclausen.org> <0F84189A-987B-47A0-A732-9668F8469BAF@thomasclausen.org> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 31 Aug 2011 17:10:48.0824 (UTC) FILETIME=[EDF1D780:01CC6800] Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 17:11:26 -0000 --Apple-Mail=_768C6C46-4366-48D9-B0DC-C1AC7912403F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 31, 2011, at 7:08 PM, Thomas Heide Clausen wrote: >=20 > On Aug 31, 2011, at 19:05 , JP Vasseur wrote: >=20 >>=20 >> On Aug 31, 2011, at 6:57 PM, Thomas Heide Clausen wrote: >>=20 >>>=20 >>> On Aug 31, 2011, at 18:41 , JP Vasseur wrote: >>>=20 >>> > >>> > On Aug 31, 2011, at 5:55 PM, Thomas Heide Clausen wrote: >>> > >>> >> I would actually argue that RPL and P2P-RPL are two entirely = different protocols (albeit sharing some commonalities in the overall = message structure). >>> >> >>> >> There are ways of making multiple routing protocols co-exist on = the same routers (and in the same network). However I am not sure that = it is such a good idea to do so in a LLN. >>> >> >>> >> I've always found it odd that P2P traffic was not supported in = RPL -- and really, dog-leg routing through a DODAG root and using source = routing isn't (efficiently) supporting P2P. >>> > >>> > Thomas, >>> > >>> > I cannot let you say this =85 you perfectly know that the core = specification of RPL supports P2P traffic. >>>=20 >>> Ah, but you must, JP, you must. >>>=20 >>> Note that I said in the above that RPL supports P2P traffic by way = of dog-leg routing through the DODAG root, then source routing -- that's = the _only_ way P2P is supported, guaranteed to work across all the = different RPL-flavors (storing/non-storing with/without RPL-P2P, =85) = that the WG is exploring. >>>=20 >> Well the sentence was, to say the least, strangely worded =85 As you = know, you go via the root only if you deploy non-storing. >>=20 >=20 > Well, given the state requirements for storing-mode in networks larger = than a few handful of routers, non-storing mode seems to be the only = realistic choice for the lions share of deployments that I am aware of.=20= >=20 > Thus, dog-leg-source-routing is pretty much the only viable option - = and you must admit that it's not a particularly elegant or efficient = option at that? *if* you think that this not elegant enough (which has to be = demonstrated IMO), then you must be supportive of the P2P IDs work that the WG has been working on ? Thanks. JP. >=20 > Thomas >=20 >> So I guess that we agree >>=20 >> Kind Regards. >>=20 >> JP. >>>=20 >>> I suppose that if the incurred route-stretch, increased = over-the-wire overhead and number of transmissions (across a lossy = medium, increasing loss probability) are of no concern, then this is = sufficient support=85=85? >>>=20 >>> Respectfully yours, >>>=20 >>> Thomas >>>=20 >>>=20 >>> >> >>> >> In short, I do agree with Ulrich's logic. >>> >> >>> >> Respectfully yours, >>> >> >>> >> Thomas >>> >> >>> >> On Aug 30, 2011, at 22:06 , Mukul Goyal wrote: >>> >> >>> >>> By the same logic, you would argue that P2P-RPL would lead to = non-interoperable implementations since some devices would speak P2P-RPL = and others wont. >>> >>> >>> >>> Thanks >>> >>> Mukul >>> >>> >>> >>> ----- Original Message ----- >>> >>> From: "Ulrich Herberg" >>> >>> To: "Michael Richardson" >>> >>> Cc: "Mukul Goyal" , "roll WG" >>> >>> Sent: Tuesday, August 30, 2011 2:58:21 PM >>> >>> Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression = as a new ROLL WG document >>> >>> >>> >>> I agree with Michael's concern that using GRRC could lead to = non-interoperable implementations, with some nodes "speaking" normal = RPL, some using GRRC. That might require some additional negotiation = between nodes, or worse, could lead to non-interoperable parts of the = network. That worries me. >>> >>> >>> >>> Ulrich >>> >>> >>> >>> >>> >>> On Tue, Aug 30, 2011 at 12:53 PM, Michael Richardson < = mcr@sandelman.ca > wrote: >>> >>> >>> >>> >>> >>> >>> >>>>>>>> "Mukul" =3D=3D Mukul Goyal < mukul@uwm.edu > writes: >>> >>> Mukul> I was wondering if you have the compression scheme = described >>> >>> Mukul> in draft-bormann-6lowpan-ghc in mind. I guess it will be >>> >>> Mukul> useful to compare the compression achieved using the two >>> >>> Mukul> schemes for the two examples described in >>> >>> Mukul> draft-goyal-roll-rpl-compression. I think that = compression >>> >>> Mukul> achieved with draft-bormann scheme would vary with the = actual >>> >>> Mukul> byte stream contained in the packet. There is ofcourse = no >>> >>> Mukul> such dependency in case of our scheme. >>> >>> >>> >>> yes, but the goyal-roll-rpl-compression (GRRC from now on, = okay?) scheme >>> >>> will result in devices that support the compressed format only, >>> >>> essentially creating an entirely new protocol. >>> >>> >>> >>> 6lowpan-ghc applies things as a layered approach, which means = that after >>> >>> decompression, you still need a full RPL packet parser, which = means that >>> >>> the RPL protocol can in fact evolve. >>> >>> >>> >>> goyal-roll-rpl-compression (GRRC) scheme will have to be revised = each time >>> >>> there is an addition to the protocol, and will cause a flag day, = as no >>> >>> node can use the new options until every node is upgraded, even = if the >>> >>> nodes do not need to make use of the new options. >>> >>> >>> >>> In essence, the goyal-roll-rpl-compression is a fixed = proprietary >>> >>> system. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> ] He who is tired of Weird Al is tired of life! = | firewalls [ >>> >>> ] Michael Richardson, Sandelman Software Works, Ottawa, ON = |net architect[ >>> >>> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ = |device driver[ >>> >>> Kyoto Plus: watch the video < = http://www.youtube.com/watch?v=3Dkzx1ycLXQSE > >>> >>> then sign the petition. >>> >>> _______________________________________________ >>> >>> 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 >>> > >>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_768C6C46-4366-48D9-B0DC-C1AC7912403F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

On Aug 31, = 2011, at 19:05 , JP Vasseur wrote:


On Aug 31, 2011, = at 6:57 PM, Thomas Heide Clausen wrote:

Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new = ROLL WG document

On Aug 31, 2011, at 18:41 , JP Vasseur = wrote:

>
> On Aug 31, 2011, at 5:55 PM, Thomas Heide Clausen wrote:
>
>> I would actually argue that RPL and P2P-RPL are two entirely = different protocols (albeit sharing some commonalities in the overall = message structure).
>>
>> There are ways of making multiple routing protocols co-exist on = the same routers (and in the same network). However I am not sure that = it is such  a good idea to do so in a LLN.
>>
>> I've always found it odd that P2P traffic was not supported in = RPL -- and really, dog-leg routing through a DODAG root and using source = routing isn't (efficiently) supporting P2P.
>
> Thomas,
>
> I cannot let you say this =85 you perfectly know that the core = specification of RPL supports P2P traffic.

Ah, but you must, JP, you must.

Note that I said in the above that RPL supports P2P traffic by way of = dog-leg routing through the DODAG root, then source routing -- that's = the _only_ way P2P is supported, guaranteed to work across all the = different RPL-flavors (storing/non-storing with/without RPL-P2P, =85) = that the WG is exploring.

Well the = sentence was, to say the least, strangely worded =85 As you know, you go = via the root only if you deploy = non-storing.


W= ell, given the state requirements for storing-mode in networks larger = than a few handful of routers, non-storing mode seems to be the only = realistic choice for the lions share of deployments that I am aware = of. 

Thus, dog-leg-source-routing is = pretty much the only viable option - and you must admit that it's not a = particularly elegant or efficient option at = that?

*if* you think that = this not elegant enough (which has to be demonstrated IMO), then you = must be supportive
of the P2P IDs work that the WG has been = working on = ?

Thanks.

JP.

<= blockquote type=3D"cite">
So I guess that we = agree

Kind = Regards.

JP.


I suppose that if the incurred route-stretch, increased over-the-wire = overhead and number of transmissions (across a lossy medium, increasing = loss probability) are of no concern, then this is sufficient = support=85=85?

Respectfully yours,

Thomas


>>
>> In short, I do agree with Ulrich's logic.
>>
>> Respectfully yours,
>>
>> Thomas
>>
>> On Aug 30, 2011, at 22:06 , Mukul Goyal wrote:
>>
>>> By the same logic, you would argue that P2P-RPL would lead = to non-interoperable implementations since some devices would speak = P2P-RPL and others wont.
>>>
>>> Thanks
>>> Mukul
>>>
>>> ----- Original Message -----
>>> From: "Ulrich Herberg" <ulrich@herberg.name>
>>> To: "Michael Richardson" <mcr@sandelman.ca>
>>> Cc: "Mukul Goyal" <mukul@uwm.edu>, "roll WG" <roll@ietf.org>
>>> Sent: Tuesday, August 30, 2011 2:58:21 PM
>>> Subject: Re: [Roll] Adoption of = draft-goyal-roll-rpl-compression as a new ROLL WG document
>>>
>>> I agree with Michael's concern that using GRRC could lead = to non-interoperable implementations, with some nodes "speaking" normal = RPL, some using GRRC. That might require some additional negotiation = between nodes, or worse, could lead to non-interoperable parts of the = network. That worries me.
>>>
>>> Ulrich
>>>
>>>
>>> On Tue, Aug 30, 2011 at 12:53 PM, Michael Richardson < = mcr@sandelman.ca > wrote:
>>>
>>>
>>>
>>>>>>>> "Mukul" =3D=3D Mukul Goyal < mukul@uwm.edu > writes:
>>>  Mukul> I was wondering if you have the compression = scheme described
>>>  Mukul> in draft-bormann-6lowpan-ghc in mind. I = guess it will be
>>>  Mukul> useful to compare the compression achieved = using the two
>>>  Mukul> schemes for the two examples described = in
>>>  Mukul> draft-goyal-roll-rpl-compression. I think = that compression
>>>  Mukul> achieved with draft-bormann scheme would = vary with the actual
>>>  Mukul> byte stream contained in the packet. There = is ofcourse no
>>>  Mukul> such dependency in case of our scheme.
>>>
>>> yes, but the goyal-roll-rpl-compression (GRRC from now on, = okay?) scheme
>>> will result in devices that support the compressed format = only,
>>> essentially creating an entirely new protocol.
>>>
>>> 6lowpan-ghc applies things as a layered approach, which = means that after
>>> decompression, you still need a full RPL packet parser, = which means that
>>> the RPL protocol can in fact evolve.
>>>
>>> goyal-roll-rpl-compression (GRRC) scheme will have to be = revised each time
>>> there is an addition to the protocol, and will cause a flag = day, as no
>>> node can use the new options until every node is upgraded, = even if the
>>> nodes do not need to make use of the new options.
>>>
>>> In essence, the goyal-roll-rpl-compression is a fixed = proprietary
>>> system.
>>>
>>>
>>>
>>>
>>> --
>>> ]       He who is tired of = Weird Al is tired of = life!           = |  firewalls  [
>>> ]   Michael Richardson, Sandelman Software Works, = Ottawa, ON    |net architect[
>>> ] mcr@sandelman.ottawa.on.ca = http://www.sandelman.ottawa.on= .ca/ |device driver[
>>> Kyoto Plus: watch the video < http://www.youtube.c= om/watch?v=3Dkzx1ycLXQSE >
= >>>          &n= bsp;          then sign the = petition.
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/m= ailman/listinfo/roll
>>>
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/m= ailman/listinfo/roll
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/m= ailman/listinfo/roll
>

=



= --Apple-Mail=_768C6C46-4366-48D9-B0DC-C1AC7912403F-- From Jorjeta.Jetcheva@itron.com Wed Aug 31 10:15:03 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE55821F8DB6 for ; Wed, 31 Aug 2011 10:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxoyZPlbTpmq for ; Wed, 31 Aug 2011 10:15:02 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.116]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6D021F8DE9 for ; Wed, 31 Aug 2011 10:15:02 -0700 (PDT) Received: from ITR-EXMBXVS-2.itron.com ([192.168.9.111]) by spo-exchcn-2.itron.com ([192.168.9.116]) with mapi; Wed, 31 Aug 2011 10:16:32 -0700 From: "Jetcheva, Jorjeta" To: "Akyol, Bora A" Date: Wed, 31 Aug 2011 10:16:30 -0700 Thread-Topic: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Thread-Index: Acxn+N7nNlDzn16jT/a4Vz4B6K8W6wABlihA Message-ID: <0368F388C03BB34BBBFA73209849D47A4CCB9745@ITR-EXMBXVS-2.itron.com> References: <0368F388C03BB34BBBFA73209849D47A4CC5A0AD@ITR-EXMBXVS-2.itron.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: D?jean Nicolas , "roll@ietf.org" Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 17:15:04 -0000 Hi Bora and all, There were some comments on the list related to adding text about the appli= cability of multi-hop vs. single-hop deployments. This paragraph attempted= to distinguish between the two. Perhaps it is not necessary to motivate t= he existence/use of multi-hop networks because they are already the focus o= f the protocol development within this group. Does anyone else have any additional comments regarding including text abou= t the benefits of multi-hop networks as compared to single-hop networks in = the draft?=20 Thanks, Jorjeta Jorjeta Jetcheva, Ph.D. Principal Engineer, Architecture & Standards CTO Office Itron, Inc. -----Original Message----- From: Akyol, Bora A [mailto:bora@pnnl.gov]=20 Sent: Wednesday, August 31, 2011 9:13 AM To: Jetcheva, Jorjeta Cc: D?jean Nicolas; roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Hi again, My point is that this statement adds no value to the document and in my opinion subtracts value. The alternate wording I suggested is technical and avoids "markitecture" type statements. I meant powerline (as in Aclara TWACS or the newer technologies) which is essentially a single hop technology. I believe the cost effectiveness of a particular technology highly depends on the OPEX as well as the CAPEX, and customer density. I don't think we should take that on in an IETF document. Regards --=20 Bora Akyol, Pacific Northwest National Laboratory +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov On 8/31/11 9:05 AM, "Jetcheva, Jorjeta" wrote: >Hello Bora, > >The text in this paragraph doesn't actually use the word "substantial", >and I think you meant "wireline", not "powerline". > >What would you consider to be a "substantiated" statement of the >applicability/benefits of mesh networks relative to other deployment >paradigms? > >Thanks, Jorjeta > >Jorjeta Jetcheva, Ph.D. >Principal Engineer, Architecture & Standards >CTO Office >Itron, Inc. > > >-----Original Message----- >From: Akyol, Bora A [mailto:bora@pnnl.gov] >Sent: Wednesday, August 31, 2011 8:40 AM >To: Jetcheva, Jorjeta >Cc: D?jean Nicolas; roll@ietf.org >Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt > > >Hi Jorjeta > >Sorry, I had two comments in my original email. One was regarding >gas/power meters and the second regarding the non-technical slant in the >introduction. >The modified paragraph that I proposed is related to the second point. > >To answer your question, I disagree with the unbsubstantiated statement >that multi-hop wireless mesh networks have substantial cost benefits >compared to either powerline or single-hop (e.g. cellular modems) >networks.=20 >I am not saying this is completely wrong, I am saying that this statement >does not belong in an IETF document since it has no relevance to ROLL >or the applicability of ROLL to AMI networks. I think the paragraph I >proposed is clear-cut and technically accurate without having a bias >towards the use of wireless mesh networks. > >Regards > >Bora > >-----Original Message----- >From: Jetcheva, Jorjeta [mailto:Jorjeta.Jetcheva@itron.com] >Sent: Wednesday, August 31, 2011 8:35 AM >To: Akyol, Bora A >Cc: D?jean Nicolas; roll@ietf.org >Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt > >Hello Bora, > >The paragraph you cited does not reference anything related to water or >gas meters which was the topic of your earlier comment and the discussion >that followed. Is this perhaps not the right paragraph or is this the >beginning of a new discussion? > >As far as the benefits of multi-hop networks over wireline or cellular >backhaul, I think that lower cost and deployment complexity are pretty >commonly cited. Do you disagree with this statement? > >Thanks, Jorjeta > >Jorjeta Jetcheva, Ph.D. >Principal Engineer, Architecture & Standards CTO Office Itron, Inc. > > >-----Original Message----- >From: Akyol, Bora A [mailto:bora@pnnl.gov] >Sent: Wednesday, August 31, 2011 8:09 AM >To: Nicolas DEJEAN >Cc: Jetcheva, Jorjeta; roll@ietf.org >Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt > > >Hi Nicolas > >Yes, we had a private email exchange off-list. > >I would like to suggest alternate wording for this paragraph as follows: > >ORIGINAL: > > Electric meters are often interconnected into multi-hop mesh > networks, each of which is connected to a backhaul network leading to > the utility network through a network aggregation point (NAP). These > kinds of networks increase coverage and reduce installation cost, > time and complexity, as well as operational costs, as compared to > single-hop wireless networks, relying on a wireline or cellular > backhaul. Each electric meter mesh typically has on the order of > several thousand wireless endpoints, with densities varying based on > the area and the terrain. Apartment buildings in urban centers may > have hundreds of meters in close proximity, whereas rural areas may >have sparse node distributions and include nodes that only have one or >two network neighbors. Paths in the mesh between a network device > and the nearest aggregation point may be composed of several hops or > even tens of hops. > > >ALTERNATE WORDING: > > >In one type of AMI network, electric meters are interconnected into >multi-hop mesh >networks, each of which is connected to a backhaul network leading to >the utility network through a network aggregation point (NAP). > >mesh> > >In a multi-hop mesh network, each electric meter mesh may have up to >several thousand wireless endpoints, with densities varying based on >the area and the terrain. Apartment buildings in urban centers may >have hundreds of meters in close proximity, whereas rural areas may >have sparse node distributions and include nodes that only have one or two >network neighbors. >Paths in the mesh between a network device >and the nearest aggregation point may be composed of several hops or >even tens of hops. > > > >What do you think? > >Thanks > > >--=20 >Bora Akyol, Pacific Northwest National Laboratory >+1 509 371 6682, bora@pnnl.gov, www.pnnl.gov > > > > >On 8/31/11 4:23 AM, "Nicolas DEJEAN" >wrote: > >>Hello Bora, >> >>Did Jorjeta answered your concerns about an AMI network considered as >>a backhaul for Gas and Water? >> >>Thank you in advance, >> >>Nicolas. >> >>2011/8/30 Jetcheva, Jorjeta : >>> Hello Bora, >>> >>>> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >>>> backhaul were considered out of scope. >>> >>> Actually AMI backhaul for gas and water meters is very much in scope as >>>per the NIST Wireless Guidelines (PAP2) work and the related >>>SG-Communications/SG-Net work. CSWG coordinates with the PAPs so they >>>should be aware of this. >>> >>> Jorjeta >>> >>> Jorjeta Jetcheva, Ph.D. >>> Principal Engineer, Architecture & Standards >>> CTO Office >>> Itron, Inc. >>> >>> >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >>>Akyol, Bora A >>> Sent: Tuesday, August 30, 2011 10:37 AM >>> To: Nicolas DEJEAN >>> Cc: roll@ietf.org >>> Subject: Re: [Roll] I-D Action: >>>draft-ietf-roll-applicability-ami-01.txt >>> >>> Hi Nicolas >>> >>> Thank you for your response. >>> >>> Please see my comments within >>> -- >>> Bora Akyol, Pacific Northwest National Laboratory >>> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>> >>> >>> >>> >>> On 8/30/11 1:25 AM, "Nicolas DEJEAN" >>> >>> wrote: >>> >>>>Hello Bora, >>>> >>>>2011/7/29 Akyol, Bora A : >>>>> I think the statement about AMI networks being used as an almost >>>>>general >>>>> purpose backhaul network for all other devices >>>>> is overreaching. I know there are some utilities that are looking >>>>>into >>>>> this, but a lot more that have shied away from >>>>> this vision. Secondly, there are a lot more AMI deployments not using >>>>> wireless mesh networks, e.g. using cellular modem, >>>>> powerline carrier, etc. >>>> >>>>I agree that all utilities are not looking into it. >>>>However this is one possible case that should be considered, isn't it? >>>>Could you please precise what you are expecting to be in the draft? >>> >>> I think the draft should be focusing on the applicability of ROLL from >>>a >>> technical front >>> without siting this one case as the only justification. >>> >>>> >>>>> >>>>> Is it possible to tone this "marketing" text Section 1.1. down and >>>>>also >>>>> potentially >>>>> remove Gas & Water meters from the scope of this document. >>>>> >>>> >>>>On our point of view, Gas and Water metering are part of AMI. >>> >>> This is not the widely-held view at least within the US electric >>>utility >>> community. >>> The gas and water meters have capabilities which are quite different >>>from >>> electric power meters. >>> For example, while the electric meter has easy access to mains power, >>>the >>> gas/water meters don't. >>> In most instances, the gas/water service may be provided by a >>>completely >>> different entity than the electric >>> power utility. >>> >>> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >>> backhaul were considered out of scope. >>> >>> Would the document lose technical integrity if the gas/water meter were >>> either removed or included as an optional. >>> >>> Regards >>> >>> >>> >>>>Could you please elaborate? >>>>According to you, why should Gas and Water be removed from the draft? >>>> >>>>Thank you in advance, >>>> >>>>Nicolas. >>>> >>>>> Regards >>>>> >>>>> -- >>>>> Bora Akyol, Pacific Northwest National Laboratory >>>>> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>>>> >>>>> _______________________________________________ >>>>> 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 ietf@thomasclausen.org Wed Aug 31 10:23:46 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951B121F8DDA for ; Wed, 31 Aug 2011 10:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmRQkJ9FrqnM for ; Wed, 31 Aug 2011 10:23:45 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8016221F8DD4 for ; Wed, 31 Aug 2011 10:23:45 -0700 (PDT) Received: from sphinx.lix.polytechnique.fr ([129.104.11.1] helo=[10.0.1.5]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1QyoXK-0002QW-Vu; Wed, 31 Aug 2011 17:25:15 +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: U2FsdGVkX19qw8V/jQs1lYEBo6WVKPzy Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Thomas Heide Clausen In-Reply-To: <8CA251EF-2842-453A-964A-E3F30713917A@cisco.com> Date: Wed, 31 Aug 2011 19:25:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2507C27F-0589-488C-902F-52B55A0FCE49@thomasclausen.org> References: <1483809161.144962.1314763722334.JavaMail.root@mail05.pantherlink.uwm.edu> <4884.1314797912@marajade.sandelman.ca> <8CA251EF-2842-453A-964A-E3F30713917A@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1244.3) Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 17:23:46 -0000 On Aug 31, 2011, at 18:39 , JP Vasseur wrote: > Dear Thomas, >=20 > On Aug 31, 2011, at 5:54 PM, Thomas Heide Clausen wrote: >=20 >> I think that this is somewhat going to the crux of what I was = referring to when I suggested updates/obsoletes RPL in case this (or, = any) compression scheme is introduced. >>=20 >> As I understood the original design scope of ROLL, as retained in the = charter, 802.15.4 was one of the (but, not the only) target L2's. It may = be that a less verbose message format is required for 802.15.4 than that = currently proposed in RPL - in fact, we've got some indications from our = testing that this is the case (even for stock RPL) to avoid = fragmentation. >>=20 >> However then the working group should fix the problem in RPL by = updating that specification, >=20 > Once again, there is no fix to have.=20 I would submit that if when running RPL on 802.15.4 I manage to get = fragmented RPL control packets, then there's something that should be = fixed in a protocol from a working group, which has 802.15.4 among its = design targets. Daniel Popa said in his email that: > Hi Emmanuel, Thomas, > =20 > One case where we do not necessarily need compression is the use of = the new IEEE 802.15.4 amendments, specifically designed for smart grids. = 802.15.4g is a PHY Layer for Smart Utility Networks and 802.15.4e, a new = MAC sub-layer that among others functionalities provide support for a 4g = PHY layer. For information, 4g PHY amendment mandates the support of = IPv6 MTU. =20 > =20 > Regards, > Daniel It seems that Daniel indicates that there may be exceptional MACs where = compression isn't needed. But, it also seems that in the majority of the = cases, it is needed and thus should be default. Do note that my main point is, that "simple is good".=20 As Michael has said repeatedly, having two different, incompatible, = packet formats is extra overhead in coding and testing and isn't without = complications for extensibility etc.=20 As Ulrich and Michael have pointed out, there are issues when running = two different and incompatible flavors of RPL (as would be the case if = there were two different packet format) in the same network. If such is = prohibited, then the WG has effectively created 4 different, = non-interoperable protocols as previously enumerated. I'd much like a routing protocol, designed for low-power, lossy networks = and with low-MTU MACs as one of its design-target to be able to run over = these networks. If _this_ early a need for an alternative, more compact, = packet format is identified, then by all means let's get RPL updated to = use that alternative, more compact, packet format. I have absolutely no = problems with that. I do, however, think that it should be avoided adding yet another = component of functionality and complexity to an already complex = protocol. And, it should be avoided to adding another set of = non-interoperable modes-of-operation rendering deployments more complex. Respectfully yours, Thomas > Mukul is proposing an optional compression mechanism, currently = discussed by the WG, that's it. > Thanks. >=20 > JP. >=20 >> rather than propose an alternative, incompatible message format as an = option which - as Michael has pointed out in this and previous messages = - necessitating writing/testing multiple different parsers, additional = signaling to ensure that in a given deployment messages are sent in the = "right" format (or, do we disallow heterogenous deployments?) etc. >>=20 >> I'm concerned that the WG, so early after (well, before) that RPL is = published as RFC feels the need to consider such "patches" to the = protocol. >>=20 >> Respectfully yours,=20 >>=20 >> Thomas >>=20 >> On Aug 31, 2011, at 15:38 , Michael Richardson wrote: >>=20 >>>=20 >>>>>>>> "Mukul" =3D=3D Mukul Goyal writes: >>> Mukul> I understand your preference for GHC scheme. As for our >>> Mukul> scheme, it seems to me that you would like our scheme much >>> Mukul> better if there is a way for a node to solicit >>> Mukul> compressed/uncompressed DIOs. Is my understanding correct?=20= >>> Mukul> This could be done by a simple DIS flag. >>>=20 >>> No, I wouldn't like that. I'd like not to have to write and test = two >>> parsers for options, and I'd like the scheme not to fall apart when = we >>> introduce another option type. >>>=20 >>> I will evaluate GHC method, and write a draft this long weekend with = my >>> results. If anyone has sample RPL messages they want me to = consider,=20 >>> I would appreciate a PCAP file, otherwise, I'll evaluate only my = own. >>> In particular, I need more examples of metric options. >>>=20 >>>=20 >>> --=20 >>> ] He who is tired of Weird Al is tired of life! | = firewalls [ >>> ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net = architect[ >>> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ = |device driver[ >>> Kyoto Plus: watch the video = >>> then sign the petition.=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 From alexandru.petrescu@gmail.com Wed Aug 31 10:48:38 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B40C21F8E10 for ; Wed, 31 Aug 2011 10:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.839 X-Spam-Level: X-Spam-Status: No, score=-1.839 tagged_above=-999 required=5 tests=[AWL=1.760, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsfvaEJoKcMV for ; Wed, 31 Aug 2011 10:48:37 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 15B4921F8E0B for ; Wed, 31 Aug 2011 10:48:36 -0700 (PDT) Received: by ewy19 with SMTP id 19so654295ewy.31 for ; Wed, 31 Aug 2011 10:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=XH4Q3owWgQQ6BT1LDdoH+dD69JaFdU+7ed0CR7/xRTE=; b=MSbEjmjugCUL7FBvyMp+HV0GJvmaLxxI7wXwFv0obl8Pv/C7lyTWATrd4GONmKHvcO xTSOuJBCtnIUhvw9zHqj8zAbNPY/nmziKj6HPTxFeP3njUoKLCEs2iLC+FhD+VLnk3xF adDX/D2Tz3qltf88Se+vnvLnxm5di/0QeeYqc= Received: by 10.213.10.142 with SMTP id p14mr408691ebp.46.1314813006267; Wed, 31 Aug 2011 10:50:06 -0700 (PDT) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by mx.google.com with ESMTPS id w51sm4885370eef.11.2011.08.31.10.50.04 (version=SSLv3 cipher=OTHER); Wed, 31 Aug 2011 10:50:05 -0700 (PDT) Message-ID: <4E5E7448.5010106@gmail.com> Date: Wed, 31 Aug 2011 19:50:00 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: roll@ietf.org References: <1593431155.140676.1314734802999.JavaMail.root@mail05.pantherlink.uwm.edu> <1831033C-FE54-4B15-BC8B-B4C8E230AFD1@thomasclausen.org> <0621F6C4-B7AA-4E04-9021-CE5CC9B8A888@cisco.com> <609341E6-F4B1-483B-8306-05265023C840@thomasclausen.org> <0F84189A-987B-47A0-A732-9668F8469BAF@thomasclausen.org> <4598998E-F7F6-4469-8977-BD49B5D7ECF7@cisco.com> In-Reply-To: <4598998E-F7F6-4469-8977-BD49B5D7ECF7@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 17:48:38 -0000 Le 31/08/2011 19:10, JP Vasseur a écrit : > > On Aug 31, 2011, at 7:08 PM, Thomas Heide Clausen wrote: > >> >> On Aug 31, 2011, at 19:05 , JP Vasseur wrote: >> >>> >>> On Aug 31, 2011, at 6:57 PM, Thomas Heide Clausen wrote: >>> >>>> >>>> On Aug 31, 2011, at 18:41 , JP Vasseur wrote: >>>> >>>> > >>>> > On Aug 31, 2011, at 5:55 PM, Thomas Heide Clausen wrote: >>>> > >>>> >> I would actually argue that RPL and P2P-RPL are two entirely >>>> different protocols (albeit sharing some commonalities in the >>>> overall message structure). >>>> >> >>>> >> There are ways of making multiple routing protocols co-exist on >>>> the same routers (and in the same network). However I am not sure >>>> that it is such a good idea to do so in a LLN. >>>> >> >>>> >> I've always found it odd that P2P traffic was not supported in >>>> RPL -- and really, dog-leg routing through a DODAG root and using >>>> source routing isn't (efficiently) supporting P2P. >>>> > >>>> > Thomas, >>>> > >>>> > I cannot let you say this … you perfectly know that the core >>>> specification of RPL supports P2P traffic. >>>> >>>> Ah, but you must, JP, you must. >>>> >>>> Note that I said in the above that RPL supports P2P traffic by way >>>> of dog-leg routing through the DODAG root, then source routing -- >>>> that's the _only_ way P2P is supported, guaranteed to work across >>>> all the different RPL-flavors (storing/non-storing with/without >>>> RPL-P2P, …) that the WG is exploring. >>>> >>> Well the sentence was, to say the least, strangely worded … As you >>> know, you go via the root only if you deploy non-storing. >>> >> >> Well, given the state requirements for storing-mode in networks larger >> than a few handful of routers, non-storing mode seems to be the only >> realistic choice for the lions share of deployments that I am aware of. >> >> Thus, dog-leg-source-routing is pretty much the only viable option - >> and you must admit that it's not a particularly elegant or efficient >> option at that? > > *if* you think that this not elegant enough (which has to be > demonstrated IMO), then you must be supportive > of the P2P IDs work that the WG has been working on ? it's not a matter of elegance but of the routing being shortest path different than routing being trees and dags in a computer's memory. mip has dogleg routing and mechanisms to alleviate it (ro) imposed by the sheer size of Internet (not the case of rpl nets), no need of new mechanisms to avoid dogleg in small nets - there exist simple mechanisms already to do that. imho, Alex > > Thanks. > > JP. > >> >> Thomas >> >>> So I guess that we agree >>> >>> Kind Regards. >>> >>> JP. >>>> >>>> >>>> I suppose that if the incurred route-stretch, increased >>>> over-the-wire overhead and number of transmissions (across a lossy >>>> medium, increasing loss probability) are of no concern, then this is >>>> sufficient support……? >>>> >>>> Respectfully yours, >>>> >>>> Thomas >>>> >>>> >>>> >> >>>> >> In short, I do agree with Ulrich's logic. >>>> >> >>>> >> Respectfully yours, >>>> >> >>>> >> Thomas >>>> >> >>>> >> On Aug 30, 2011, at 22:06 , Mukul Goyal wrote: >>>> >> >>>> >>> By the same logic, you would argue that P2P-RPL would lead to >>>> non-interoperable implementations since some devices would speak >>>> P2P-RPL and others wont. >>>> >>> >>>> >>> Thanks >>>> >>> Mukul >>>> >>> >>>> >>> ----- Original Message ----- >>>> >>> From: "Ulrich Herberg" >>> > >>>> >>> To: "Michael Richardson" >>> > >>>> >>> Cc: "Mukul Goyal" >, "roll >>>> WG" > >>>> >>> Sent: Tuesday, August 30, 2011 2:58:21 PM >>>> >>> Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression >>>> as a new ROLL WG document >>>> >>> >>>> >>> I agree with Michael's concern that using GRRC could lead to >>>> non-interoperable implementations, with some nodes "speaking" normal >>>> RPL, some using GRRC. That might require some additional negotiation >>>> between nodes, or worse, could lead to non-interoperable parts of >>>> the network. That worries me. >>>> >>> >>>> >>> Ulrich >>>> >>> >>>> >>> >>>> >>> On Tue, Aug 30, 2011 at 12:53 PM, Michael Richardson < >>>> mcr@sandelman.ca > wrote: >>>> >>> >>>> >>> >>>> >>> >>>> >>>>>>>> "Mukul" == Mukul Goyal < mukul@uwm.edu >>>> > writes: >>>> >>> Mukul> I was wondering if you have the compression scheme described >>>> >>> Mukul> in draft-bormann-6lowpan-ghc in mind. I guess it will be >>>> >>> Mukul> useful to compare the compression achieved using the two >>>> >>> Mukul> schemes for the two examples described in >>>> >>> Mukul> draft-goyal-roll-rpl-compression. I think that compression >>>> >>> Mukul> achieved with draft-bormann scheme would vary with the actual >>>> >>> Mukul> byte stream contained in the packet. There is ofcourse no >>>> >>> Mukul> such dependency in case of our scheme. >>>> >>> >>>> >>> yes, but the goyal-roll-rpl-compression (GRRC from now on, >>>> okay?) scheme >>>> >>> will result in devices that support the compressed format only, >>>> >>> essentially creating an entirely new protocol. >>>> >>> >>>> >>> 6lowpan-ghc applies things as a layered approach, which means >>>> that after >>>> >>> decompression, you still need a full RPL packet parser, which >>>> means that >>>> >>> the RPL protocol can in fact evolve. >>>> >>> >>>> >>> goyal-roll-rpl-compression (GRRC) scheme will have to be revised >>>> each time >>>> >>> there is an addition to the protocol, and will cause a flag day, >>>> as no >>>> >>> node can use the new options until every node is upgraded, even >>>> if the >>>> >>> nodes do not need to make use of the new options. >>>> >>> >>>> >>> In essence, the goyal-roll-rpl-compression is a fixed proprietary >>>> >>> system. >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> -- >>>> >>> ] He who is tired of Weird Al is tired of life! | firewalls [ >>>> >>> ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net >>>> architect[ >>>> >>> ] mcr@sandelman.ottawa.on.ca >>>> http://www.sandelman.ottawa.on.ca/ |device driver[ >>>> >>> Kyoto Plus: watch the video < >>>> http://www.youtube.com/watch?v=kzx1ycLXQSE > >>>> >>> then sign the petition. >>>> >>> _______________________________________________ >>>> >>> 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 Ruben.Salazar@landisgyr.com Wed Aug 31 10:58:08 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A81721F8D85 for ; Wed, 31 Aug 2011 10:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRWoS5QEHHpZ for ; Wed, 31 Aug 2011 10:58:07 -0700 (PDT) Received: from VA3EHSOBE001.bigfish.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id E2B5D21F8DD4 for ; Wed, 31 Aug 2011 10:58:06 -0700 (PDT) Received: from mail1-va3-R.bigfish.com (10.7.14.254) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.22; Wed, 31 Aug 2011 17:59:36 +0000 Received: from mail1-va3 (localhost.localdomain [127.0.0.1]) by mail1-va3-R.bigfish.com (Postfix) with ESMTP id E7EDDC101AD; Wed, 31 Aug 2011 17:59:36 +0000 (UTC) X-SpamScore: -56 X-BigFish: PS-56(zzbb2dK9371K542M1dbaL1418M1432Nc540K98dK4015Lzz1202hzz1033IL8275bh8275dhz2dh668h839h8aah61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:80.12.107.23; KIP:(null); UIP:(null); IPVD:NLI; SRV:BULK; H:av-smtp2.lng.gmessaging.net; RD:av-smtp2.lng.gmessaging.net; EFVD:NLI Received: from mail1-va3 (localhost.localdomain [127.0.0.1]) by mail1-va3 (MessageSwitch) id 1314813576324596_27984; Wed, 31 Aug 2011 17:59:36 +0000 (UTC) Received: from VA3EHSMHS002.bigfish.com (unknown [10.7.14.239]) by mail1-va3.bigfish.com (Postfix) with ESMTP id 450C015804C; Wed, 31 Aug 2011 17:59:36 +0000 (UTC) Received: from av-smtp2.lng.gmessaging.net (80.12.107.23) by VA3EHSMHS002.bigfish.com (10.7.99.12) with Microsoft SMTP Server id 14.1.225.22; Wed, 31 Aug 2011 17:59:27 +0000 Received: from av-smtp2.lng.gmessaging.net (localhost.localdomain [127.0.0.1]) by localhost.lng.gmessaging.net (Postfix) with SMTP id 9E1A776807F; Wed, 31 Aug 2011 18:22:28 +0200 (CEST) Received: from secure1.landisgyr.com (unknown [10.33.192.45]) by av-smtp2.lng.gmessaging.net (Postfix) with ESMTP id 5E3A9768088; Wed, 31 Aug 2011 18:22:18 +0200 (CEST) Received: from FRPARSV10.mx.bm.net ([10.33.192.40]) by frparsv11.mx.bm.net ([10.33.192.45]) with mapi; Wed, 31 Aug 2011 19:59:15 +0200 From: "Salazar, Ruben" To: "Jetcheva, Jorjeta" , "Akyol, Bora A" Date: Wed, 31 Aug 2011 19:59:14 +0200 Thread-Topic: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Thread-Index: Acxn+N7nNlDzn16jT/a4Vz4B6K8W6wABlihAAAIAh7A= Message-ID: <4EA811E84AEC874FA69EE87C8C6BBEB5869A3495B3@FRPARSV10.mx.bm.net> References: <0368F388C03BB34BBBFA73209849D47A4CC5A0AD@ITR-EXMBXVS-2.itron.com> <0368F388C03BB34BBBFA73209849D47A4CCB9745@ITR-EXMBXVS-2.itron.com> In-Reply-To: <0368F388C03BB34BBBFA73209849D47A4CCB9745@ITR-EXMBXVS-2.itron.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: a70a6184-0c20-4798-8bda-10a8eb498786 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com Cc: D?jean Nicolas , "roll@ietf.org" Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 17:58:08 -0000 All, The benefit of multi-hop networks is clear as it relates to geography cover= age: that is why star topologies have some hidden repeat-route-relay featur= es/mechanisms to extend coverage, which comes naturally with mesh topologie= s. And this statement applies to both wireless and wired networks. Regards Ruben Salazar Director Research and Technology Landis+Gyr Energy Management Solutions Office: +1 678 258 3165=A0=A0=A0=A0=A0=A0=A0=A0 Ruben.Salazar@landisgyr.com www.landisgyr.com=20 manage energy better -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jet= cheva, Jorjeta Sent: Wednesday, August 31, 2011 1:17 PM To: Akyol, Bora A Cc: D?jean Nicolas; roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Hi Bora and all, There were some comments on the list related to adding text about the appli= cability of multi-hop vs. single-hop deployments. This paragraph attempted= to distinguish between the two. Perhaps it is not necessary to motivate t= he existence/use of multi-hop networks because they are already the focus o= f the protocol development within this group. Does anyone else have any additional comments regarding including text abou= t the benefits of multi-hop networks as compared to single-hop networks in = the draft?=20 Thanks, Jorjeta Jorjeta Jetcheva, Ph.D. Principal Engineer, Architecture & Standards CTO Office Itron, Inc. -----Original Message----- From: Akyol, Bora A [mailto:bora@pnnl.gov]=20 Sent: Wednesday, August 31, 2011 9:13 AM To: Jetcheva, Jorjeta Cc: D?jean Nicolas; roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Hi again, My point is that this statement adds no value to the document and in my opinion subtracts value. The alternate wording I suggested is technical and avoids "markitecture" type statements. I meant powerline (as in Aclara TWACS or the newer technologies) which is essentially a single hop technology. I believe the cost effectiveness of a particular technology highly depends on the OPEX as well as the CAPEX, and customer density. I don't think we should take that on in an IETF document. Regards --=20 Bora Akyol, Pacific Northwest National Laboratory +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov On 8/31/11 9:05 AM, "Jetcheva, Jorjeta" wrote: >Hello Bora, > >The text in this paragraph doesn't actually use the word "substantial", >and I think you meant "wireline", not "powerline". > >What would you consider to be a "substantiated" statement of the >applicability/benefits of mesh networks relative to other deployment >paradigms? > >Thanks, Jorjeta > >Jorjeta Jetcheva, Ph.D. >Principal Engineer, Architecture & Standards >CTO Office >Itron, Inc. > > >-----Original Message----- >From: Akyol, Bora A [mailto:bora@pnnl.gov] >Sent: Wednesday, August 31, 2011 8:40 AM >To: Jetcheva, Jorjeta >Cc: D?jean Nicolas; roll@ietf.org >Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt > > >Hi Jorjeta > >Sorry, I had two comments in my original email. One was regarding >gas/power meters and the second regarding the non-technical slant in the >introduction. >The modified paragraph that I proposed is related to the second point. > >To answer your question, I disagree with the unbsubstantiated statement >that multi-hop wireless mesh networks have substantial cost benefits >compared to either powerline or single-hop (e.g. cellular modems) >networks.=20 >I am not saying this is completely wrong, I am saying that this statement >does not belong in an IETF document since it has no relevance to ROLL >or the applicability of ROLL to AMI networks. I think the paragraph I >proposed is clear-cut and technically accurate without having a bias >towards the use of wireless mesh networks. > >Regards > >Bora > >-----Original Message----- >From: Jetcheva, Jorjeta [mailto:Jorjeta.Jetcheva@itron.com] >Sent: Wednesday, August 31, 2011 8:35 AM >To: Akyol, Bora A >Cc: D?jean Nicolas; roll@ietf.org >Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt > >Hello Bora, > >The paragraph you cited does not reference anything related to water or >gas meters which was the topic of your earlier comment and the discussion >that followed. Is this perhaps not the right paragraph or is this the >beginning of a new discussion? > >As far as the benefits of multi-hop networks over wireline or cellular >backhaul, I think that lower cost and deployment complexity are pretty >commonly cited. Do you disagree with this statement? > >Thanks, Jorjeta > >Jorjeta Jetcheva, Ph.D. >Principal Engineer, Architecture & Standards CTO Office Itron, Inc. > > >-----Original Message----- >From: Akyol, Bora A [mailto:bora@pnnl.gov] >Sent: Wednesday, August 31, 2011 8:09 AM >To: Nicolas DEJEAN >Cc: Jetcheva, Jorjeta; roll@ietf.org >Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt > > >Hi Nicolas > >Yes, we had a private email exchange off-list. > >I would like to suggest alternate wording for this paragraph as follows: > >ORIGINAL: > > Electric meters are often interconnected into multi-hop mesh > networks, each of which is connected to a backhaul network leading to > the utility network through a network aggregation point (NAP). These > kinds of networks increase coverage and reduce installation cost, > time and complexity, as well as operational costs, as compared to > single-hop wireless networks, relying on a wireline or cellular > backhaul. Each electric meter mesh typically has on the order of > several thousand wireless endpoints, with densities varying based on > the area and the terrain. Apartment buildings in urban centers may > have hundreds of meters in close proximity, whereas rural areas may >have sparse node distributions and include nodes that only have one or >two network neighbors. Paths in the mesh between a network device > and the nearest aggregation point may be composed of several hops or > even tens of hops. > > >ALTERNATE WORDING: > > >In one type of AMI network, electric meters are interconnected into >multi-hop mesh >networks, each of which is connected to a backhaul network leading to >the utility network through a network aggregation point (NAP). > >mesh> > >In a multi-hop mesh network, each electric meter mesh may have up to >several thousand wireless endpoints, with densities varying based on >the area and the terrain. Apartment buildings in urban centers may >have hundreds of meters in close proximity, whereas rural areas may >have sparse node distributions and include nodes that only have one or two >network neighbors. >Paths in the mesh between a network device >and the nearest aggregation point may be composed of several hops or >even tens of hops. > > > >What do you think? > >Thanks > > >--=20 >Bora Akyol, Pacific Northwest National Laboratory >+1 509 371 6682, bora@pnnl.gov, www.pnnl.gov > > > > >On 8/31/11 4:23 AM, "Nicolas DEJEAN" >wrote: > >>Hello Bora, >> >>Did Jorjeta answered your concerns about an AMI network considered as >>a backhaul for Gas and Water? >> >>Thank you in advance, >> >>Nicolas. >> >>2011/8/30 Jetcheva, Jorjeta : >>> Hello Bora, >>> >>>> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >>>> backhaul were considered out of scope. >>> >>> Actually AMI backhaul for gas and water meters is very much in scope as >>>per the NIST Wireless Guidelines (PAP2) work and the related >>>SG-Communications/SG-Net work. CSWG coordinates with the PAPs so they >>>should be aware of this. >>> >>> Jorjeta >>> >>> Jorjeta Jetcheva, Ph.D. >>> Principal Engineer, Architecture & Standards >>> CTO Office >>> Itron, Inc. >>> >>> >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >>>Akyol, Bora A >>> Sent: Tuesday, August 30, 2011 10:37 AM >>> To: Nicolas DEJEAN >>> Cc: roll@ietf.org >>> Subject: Re: [Roll] I-D Action: >>>draft-ietf-roll-applicability-ami-01.txt >>> >>> Hi Nicolas >>> >>> Thank you for your response. >>> >>> Please see my comments within >>> -- >>> Bora Akyol, Pacific Northwest National Laboratory >>> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>> >>> >>> >>> >>> On 8/30/11 1:25 AM, "Nicolas DEJEAN" >>> >>> wrote: >>> >>>>Hello Bora, >>>> >>>>2011/7/29 Akyol, Bora A : >>>>> I think the statement about AMI networks being used as an almost >>>>>general >>>>> purpose backhaul network for all other devices >>>>> is overreaching. I know there are some utilities that are looking >>>>>into >>>>> this, but a lot more that have shied away from >>>>> this vision. Secondly, there are a lot more AMI deployments not using >>>>> wireless mesh networks, e.g. using cellular modem, >>>>> powerline carrier, etc. >>>> >>>>I agree that all utilities are not looking into it. >>>>However this is one possible case that should be considered, isn't it? >>>>Could you please precise what you are expecting to be in the draft? >>> >>> I think the draft should be focusing on the applicability of ROLL from >>>a >>> technical front >>> without siting this one case as the only justification. >>> >>>> >>>>> >>>>> Is it possible to tone this "marketing" text Section 1.1. down and >>>>>also >>>>> potentially >>>>> remove Gas & Water meters from the scope of this document. >>>>> >>>> >>>>On our point of view, Gas and Water metering are part of AMI. >>> >>> This is not the widely-held view at least within the US electric >>>utility >>> community. >>> The gas and water meters have capabilities which are quite different >>>from >>> electric power meters. >>> For example, while the electric meter has easy access to mains power, >>>the >>> gas/water meters don't. >>> In most instances, the gas/water service may be provided by a >>>completely >>> different entity than the electric >>> power utility. >>> >>> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >>> backhaul were considered out of scope. >>> >>> Would the document lose technical integrity if the gas/water meter were >>> either removed or included as an optional. >>> >>> Regards >>> >>> >>> >>>>Could you please elaborate? >>>>According to you, why should Gas and Water be removed from the draft? >>>> >>>>Thank you in advance, >>>> >>>>Nicolas. >>>> >>>>> Regards >>>>> >>>>> -- >>>>> Bora Akyol, Pacific Northwest National Laboratory >>>>> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>>>> >>>>> _______________________________________________ >>>>> 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 cardenas@fla.fujitsu.com Wed Aug 31 11:52:13 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6845321F8E7E for ; Wed, 31 Aug 2011 11:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JYzG7dF6Wtr for ; Wed, 31 Aug 2011 11:52:11 -0700 (PDT) Received: from fujitsu24.fnanic.fujitsu.com (fujitsu24.fnanic.fujitsu.com [192.240.6.14]) by ietfa.amsl.com (Postfix) with ESMTP id BF95D21F8E6C for ; Wed, 31 Aug 2011 11:52:11 -0700 (PDT) Received: from pps.filterd (fujitsu24 [127.0.0.1]) by fujitsu24.fnanic.fujitsu.com (8.14.4/8.14.4) with SMTP id p7VIpT7w011947; Wed, 31 Aug 2011 11:53:39 -0700 Received: from fujitsui.fna.fujitsu.com ([133.164.253.1]) by fujitsu24.fnanic.fujitsu.com with ESMTP id yh4pmrpgk-1; Wed, 31 Aug 2011 11:53:39 -0700 Received: from toyama.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsui.fna.fujitsu.com (8.13.8/8.13.8) with ESMTP id p7VIIClF003582; Wed, 31 Aug 2011 11:18:14 -0700 (PDT) Received: from [133.164.59.81] (localhost [127.0.0.1]) by toyama.fla.fujitsu.com (8.11.6+Sun/8.11.6) with ESMTP id p7VIIBJ27850; Wed, 31 Aug 2011 11:18:11 -0700 (PDT) Message-ID: <4E5E7AF7.1020506@fla.fujitsu.com> Date: Wed, 31 Aug 2011 11:18:31 -0700 From: "Alvaro A. Cardenas" User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: "Jetcheva, Jorjeta" References: <0368F388C03BB34BBBFA73209849D47A4CC5A0AD@ITR-EXMBXVS-2.itron.com> <0368F388C03BB34BBBFA73209849D47A4CCB9745@ITR-EXMBXVS-2.itron.com> In-Reply-To: <0368F388C03BB34BBBFA73209849D47A4CCB9745@ITR-EXMBXVS-2.itron.com> Content-Type: multipart/alternative; boundary="------------060402040309070105060507" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-08-31_07:2011-08-31, 2011-08-31, 1970-01-01 signatures=0 Cc: D?jean Nicolas , "roll@ietf.org" Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 18:52:13 -0000 This is a multi-part message in MIME format. --------------060402040309070105060507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Jorjeta, While I agree with you that mesh networks have a lot of advantages in many AMI deployments, I think Bora has made very good points. The text on the benefits of multi-hop networks vs. single-hop networks does not appear to be within the scope of the applicability statement of RPL to AMI MESH networks. I think the introduction shared by Bora is concise and clear. Regards, Alvaro Jetcheva, Jorjeta wrote: > Hi Bora and all, > > There were some comments on the list related to adding text about the applicability of multi-hop vs. single-hop deployments. This paragraph attempted to distinguish between the two. Perhaps it is not necessary to motivate the existence/use of multi-hop networks because they are already the focus of the protocol development within this group. > > Does anyone else have any additional comments regarding including text about the benefits of multi-hop networks as compared to single-hop networks in the draft? > > Thanks, Jorjeta > > Jorjeta Jetcheva, Ph.D. > Principal Engineer, Architecture & Standards > CTO Office > Itron, Inc. > > > -----Original Message----- > From: Akyol, Bora A [mailto:bora@pnnl.gov] > Sent: Wednesday, August 31, 2011 9:13 AM > To: Jetcheva, Jorjeta > Cc: D?jean Nicolas; roll@ietf.org > Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt > > Hi again, > > My point is that this statement adds no value to the document and in my > opinion subtracts value. > The alternate wording I suggested is technical and avoids "markitecture" > type statements. > > I meant powerline (as in Aclara TWACS or the newer technologies) which is > essentially a single hop technology. > > I believe the cost effectiveness of a particular technology highly depends > on the OPEX as well as the CAPEX, > and customer density. I don't think we should take that on in an IETF > document. > > Regards > > > -- > Bora Akyol, Pacific Northwest National Laboratory > +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov > > > > > On 8/31/11 9:05 AM, "Jetcheva, Jorjeta" wrote: > > >> Hello Bora, >> >> The text in this paragraph doesn't actually use the word "substantial", >> and I think you meant "wireline", not "powerline". >> >> What would you consider to be a "substantiated" statement of the >> applicability/benefits of mesh networks relative to other deployment >> paradigms? >> >> Thanks, Jorjeta >> >> Jorjeta Jetcheva, Ph.D. >> Principal Engineer, Architecture & Standards >> CTO Office >> Itron, Inc. >> >> >> -----Original Message----- >> From: Akyol, Bora A [mailto:bora@pnnl.gov] >> Sent: Wednesday, August 31, 2011 8:40 AM >> To: Jetcheva, Jorjeta >> Cc: D?jean Nicolas; roll@ietf.org >> Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt >> >> >> Hi Jorjeta >> >> Sorry, I had two comments in my original email. One was regarding >> gas/power meters and the second regarding the non-technical slant in the >> introduction. >> The modified paragraph that I proposed is related to the second point. >> >> To answer your question, I disagree with the unbsubstantiated statement >> that multi-hop wireless mesh networks have substantial cost benefits >> compared to either powerline or single-hop (e.g. cellular modems) >> networks. >> I am not saying this is completely wrong, I am saying that this statement >> does not belong in an IETF document since it has no relevance to ROLL >> or the applicability of ROLL to AMI networks. I think the paragraph I >> proposed is clear-cut and technically accurate without having a bias >> towards the use of wireless mesh networks. >> >> Regards >> >> Bora >> >> -----Original Message----- >> From: Jetcheva, Jorjeta [mailto:Jorjeta.Jetcheva@itron.com] >> Sent: Wednesday, August 31, 2011 8:35 AM >> To: Akyol, Bora A >> Cc: D?jean Nicolas; roll@ietf.org >> Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt >> >> Hello Bora, >> >> The paragraph you cited does not reference anything related to water or >> gas meters which was the topic of your earlier comment and the discussion >> that followed. Is this perhaps not the right paragraph or is this the >> beginning of a new discussion? >> >> As far as the benefits of multi-hop networks over wireline or cellular >> backhaul, I think that lower cost and deployment complexity are pretty >> commonly cited. Do you disagree with this statement? >> >> Thanks, Jorjeta >> >> Jorjeta Jetcheva, Ph.D. >> Principal Engineer, Architecture & Standards CTO Office Itron, Inc. >> >> >> -----Original Message----- >> From: Akyol, Bora A [mailto:bora@pnnl.gov] >> Sent: Wednesday, August 31, 2011 8:09 AM >> To: Nicolas DEJEAN >> Cc: Jetcheva, Jorjeta; roll@ietf.org >> Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt >> >> >> Hi Nicolas >> >> Yes, we had a private email exchange off-list. >> >> I would like to suggest alternate wording for this paragraph as follows: >> >> ORIGINAL: >> >> Electric meters are often interconnected into multi-hop mesh >> networks, each of which is connected to a backhaul network leading to >> the utility network through a network aggregation point (NAP). These >> kinds of networks increase coverage and reduce installation cost, >> time and complexity, as well as operational costs, as compared to >> single-hop wireless networks, relying on a wireline or cellular >> backhaul. Each electric meter mesh typically has on the order of >> several thousand wireless endpoints, with densities varying based on >> the area and the terrain. Apartment buildings in urban centers may >> have hundreds of meters in close proximity, whereas rural areas may >> have sparse node distributions and include nodes that only have one or >> two network neighbors. Paths in the mesh between a network device >> and the nearest aggregation point may be composed of several hops or >> even tens of hops. >> >> >> ALTERNATE WORDING: >> >> >> In one type of AMI network, electric meters are interconnected into >> multi-hop mesh >> networks, each of which is connected to a backhaul network leading to >> the utility network through a network aggregation point (NAP). >> >> > mesh> >> >> In a multi-hop mesh network, each electric meter mesh may have up to >> several thousand wireless endpoints, with densities varying based on >> the area and the terrain. Apartment buildings in urban centers may >> have hundreds of meters in close proximity, whereas rural areas may >> have sparse node distributions and include nodes that only have one or two >> network neighbors. >> Paths in the mesh between a network device >> and the nearest aggregation point may be composed of several hops or >> even tens of hops. >> >> >> >> What do you think? >> >> Thanks >> >> >> -- >> Bora Akyol, Pacific Northwest National Laboratory >> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >> >> >> >> >> On 8/31/11 4:23 AM, "Nicolas DEJEAN" >> wrote: >> >> >>> Hello Bora, >>> >>> Did Jorjeta answered your concerns about an AMI network considered as >>> a backhaul for Gas and Water? >>> >>> Thank you in advance, >>> >>> Nicolas. >>> >>> 2011/8/30 Jetcheva, Jorjeta : >>> >>>> Hello Bora, >>>> >>>> >>>>> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >>>>> backhaul were considered out of scope. >>>>> >>>> Actually AMI backhaul for gas and water meters is very much in scope as >>>> per the NIST Wireless Guidelines (PAP2) work and the related >>>> SG-Communications/SG-Net work. CSWG coordinates with the PAPs so they >>>> should be aware of this. >>>> >>>> Jorjeta >>>> >>>> Jorjeta Jetcheva, Ph.D. >>>> Principal Engineer, Architecture & Standards >>>> CTO Office >>>> Itron, Inc. >>>> >>>> >>>> -----Original Message----- >>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >>>> Akyol, Bora A >>>> Sent: Tuesday, August 30, 2011 10:37 AM >>>> To: Nicolas DEJEAN >>>> Cc: roll@ietf.org >>>> Subject: Re: [Roll] I-D Action: >>>> draft-ietf-roll-applicability-ami-01.txt >>>> >>>> Hi Nicolas >>>> >>>> Thank you for your response. >>>> >>>> Please see my comments within >>>> -- >>>> Bora Akyol, Pacific Northwest National Laboratory >>>> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>>> >>>> >>>> >>>> >>>> On 8/30/11 1:25 AM, "Nicolas DEJEAN" >>>> >>>> wrote: >>>> >>>> >>>>> Hello Bora, >>>>> >>>>> 2011/7/29 Akyol, Bora A : >>>>> >>>>>> I think the statement about AMI networks being used as an almost >>>>>> general >>>>>> purpose backhaul network for all other devices >>>>>> is overreaching. I know there are some utilities that are looking >>>>>> into >>>>>> this, but a lot more that have shied away from >>>>>> this vision. Secondly, there are a lot more AMI deployments not using >>>>>> wireless mesh networks, e.g. using cellular modem, >>>>>> powerline carrier, etc. >>>>>> >>>>> I agree that all utilities are not looking into it. >>>>> However this is one possible case that should be considered, isn't it? >>>>> Could you please precise what you are expecting to be in the draft? >>>>> >>>> I think the draft should be focusing on the applicability of ROLL from >>>> a >>>> technical front >>>> without siting this one case as the only justification. >>>> >>>> >>>>>> Is it possible to tone this "marketing" text Section 1.1. down and >>>>>> also >>>>>> potentially >>>>>> remove Gas & Water meters from the scope of this document. >>>>>> >>>>>> >>>>> On our point of view, Gas and Water metering are part of AMI. >>>>> >>>> This is not the widely-held view at least within the US electric >>>> utility >>>> community. >>>> The gas and water meters have capabilities which are quite different >>>> from >>>> electric power meters. >>>> For example, while the electric meter has easy access to mains power, >>>> the >>>> gas/water meters don't. >>>> In most instances, the gas/water service may be provided by a >>>> completely >>>> different entity than the electric >>>> power utility. >>>> >>>> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >>>> backhaul were considered out of scope. >>>> >>>> Would the document lose technical integrity if the gas/water meter were >>>> either removed or included as an optional. >>>> >>>> Regards >>>> >>>> >>>> >>>> >>>>> Could you please elaborate? >>>>> According to you, why should Gas and Water be removed from the draft? >>>>> >>>>> Thank you in advance, >>>>> >>>>> Nicolas. >>>>> >>>>> >>>>>> Regards >>>>>> >>>>>> -- >>>>>> Bora Akyol, Pacific Northwest National Laboratory >>>>>> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>>>>> >>>>>> _______________________________________________ >>>>>> 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 > --------------060402040309070105060507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Jorjeta,

While I agree with you that mesh networks have a lot of advantages in many AMI deployments, I think Bora has made very good points. The text on the benefits of multi-hop networks vs. single-hop networks does not appear to be within the scope of the applicability statement of RPL to AMI MESH networks.

I think the introduction shared by Bora is concise and clear.

Regards,
Alvaro

Jetcheva, Jorjeta wrote: 
Hi Bora and all,

There were some comments on the list related to adding text about the applicability of multi-hop vs. single-hop deployments.  This paragraph attempted to distinguish between the two.  Perhaps it is not necessary to motivate the existence/use of multi-hop networks because they are already the focus of the protocol development within this group.

Does anyone else have any additional comments regarding including text about the benefits of multi-hop networks as compared to single-hop networks in the draft?

Thanks, Jorjeta

Jorjeta Jetcheva, Ph.D.
Principal Engineer, Architecture & Standards
CTO Office
Itron, Inc.


-----Original Message-----
From: Akyol, Bora A [mailto:bora@pnnl.gov]
Sent: Wednesday, August 31, 2011 9:13 AM
To: Jetcheva, Jorjeta
Cc: D?jean Nicolas; roll@ietf.org
Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt

Hi again,

My point is that this statement adds no value to the document and in my
opinion subtracts value.
The alternate wording I suggested is technical and avoids "markitecture"
type statements.

I meant powerline (as in Aclara TWACS or the newer technologies) which is
essentially a single hop technology.

I believe the cost effectiveness of a particular technology highly depends
on the OPEX as well as the CAPEX,
and customer density. I don't think we should take that on in an IETF
document.

Regards


--
Bora Akyol, Pacific Northwest National Laboratory
+1 509 371 6682, bora@pnnl.gov, www.pnnl.gov




On 8/31/11 9:05 AM, "Jetcheva, Jorjeta" <Jorjeta.Jetcheva@itron.com> wrote:

  
Hello Bora,

The text in this paragraph doesn't actually use the word "substantial",
and I think you meant "wireline", not "powerline".

What would you consider to be a "substantiated" statement of the
applicability/benefits of mesh networks relative to other deployment
paradigms?

Thanks, Jorjeta

Jorjeta Jetcheva, Ph.D.
Principal Engineer, Architecture & Standards
CTO Office
Itron, Inc.


-----Original Message-----
From: Akyol, Bora A [mailto:bora@pnnl.gov]
Sent: Wednesday, August 31, 2011 8:40 AM
To: Jetcheva, Jorjeta
Cc: D?jean Nicolas; roll@ietf.org
Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt


Hi Jorjeta

Sorry, I had two comments in my original email. One was regarding
gas/power meters and the second regarding the non-technical slant in the
introduction.
The modified paragraph that I proposed is related to the second point.

To answer your question, I disagree with the unbsubstantiated statement
that multi-hop wireless mesh networks have substantial cost benefits
compared to either powerline or single-hop (e.g. cellular modems)
networks.
I am not saying this is completely wrong, I am saying that this statement
does not belong in an IETF document since it has no relevance to ROLL
or the applicability of ROLL to AMI networks. I think the paragraph I
proposed is clear-cut and technically accurate without having a bias
towards the use of wireless mesh networks.

Regards

Bora

-----Original Message-----
From: Jetcheva, Jorjeta [mailto:Jorjeta.Jetcheva@itron.com]
Sent: Wednesday, August 31, 2011 8:35 AM
To: Akyol, Bora A
Cc: D?jean Nicolas; roll@ietf.org
Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt

Hello Bora,

The paragraph you cited does not reference anything related to water or
gas meters which was the topic of your earlier comment and the discussion
that followed.  Is this perhaps not the right paragraph or is this the
beginning of a new discussion?

As far as the benefits of multi-hop networks over wireline or cellular
backhaul, I think that lower cost and deployment complexity are pretty
commonly cited.  Do you disagree with this statement?

Thanks, Jorjeta

Jorjeta Jetcheva, Ph.D.
Principal Engineer, Architecture & Standards CTO Office Itron, Inc.


-----Original Message-----
From: Akyol, Bora A [mailto:bora@pnnl.gov]
Sent: Wednesday, August 31, 2011 8:09 AM
To: Nicolas DEJEAN
Cc: Jetcheva, Jorjeta; roll@ietf.org
Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt


Hi Nicolas

Yes, we had a private email exchange off-list.

I would like to suggest alternate wording for this paragraph as follows:

ORIGINAL:

Electric meters are often interconnected into multi-hop mesh
  networks, each of which is connected to a backhaul network leading to
  the utility network through a network aggregation point (NAP).  These
  kinds of networks increase coverage and reduce installation cost,
  time and complexity, as well as operational costs, as compared to
  single-hop wireless networks, relying on a wireline or cellular
  backhaul.  Each electric meter mesh typically has on the order of
  several thousand wireless endpoints, with densities varying based on
  the area and the terrain.  Apartment buildings in urban centers may
  have hundreds of meters in close proximity, whereas rural areas may
have sparse node distributions and include nodes that only have one   or
two network neighbors.  Paths in the mesh between a network device
  and the nearest aggregation point may be composed of several hops or
  even tens of hops.


ALTERNATE WORDING:


In one type of AMI network, electric meters are interconnected into
multi-hop mesh
networks, each of which is connected to a backhaul network leading to
the utility network through a network aggregation point (NAP).

<remove unsubstantiated assertion regarding cost benefits of multi-hop
mesh>

In a multi-hop mesh network, each electric meter mesh may have up to
several thousand wireless endpoints, with densities varying based on
the area and the terrain. Apartment buildings in urban centers may
have hundreds of meters in close proximity, whereas rural areas may
have sparse node distributions and include nodes that only have one or two
network neighbors.
Paths in the mesh between a network device
and the nearest aggregation point may be composed of several hops or
even tens of hops.



What do you think?

Thanks


--
Bora Akyol, Pacific Northwest National Laboratory
+1 509 371 6682, bora@pnnl.gov, www.pnnl.gov




On 8/31/11 4:23 AM, "Nicolas DEJEAN" <nicolas.dejean.ietf@googlemail.com>
wrote:

    
Hello Bora,

Did Jorjeta answered your concerns about an AMI network considered as
a backhaul for Gas and Water?

Thank you in advance,

Nicolas.

2011/8/30 Jetcheva, Jorjeta <Jorjeta.Jetcheva@itron.com>:
      
Hello Bora,

        
At least within the US NIST SGIP CSWG, the gas/water meters and AMI
backhaul were considered out of scope.
          
Actually AMI backhaul for gas and water meters is very much in scope as
per the NIST Wireless Guidelines (PAP2) work and the related
SG-Communications/SG-Net work.  CSWG coordinates with the PAPs so they
should be aware of this.

Jorjeta

Jorjeta Jetcheva, Ph.D.
Principal Engineer, Architecture & Standards
CTO Office
Itron, Inc.


-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Akyol, Bora A
Sent: Tuesday, August 30, 2011 10:37 AM
To: Nicolas DEJEAN
Cc: roll@ietf.org
Subject: Re: [Roll] I-D Action:
draft-ietf-roll-applicability-ami-01.txt

Hi Nicolas

Thank you for your response.

Please see my comments within
--
Bora Akyol, Pacific Northwest National Laboratory
+1 509 371 6682, bora@pnnl.gov, www.pnnl.gov




On 8/30/11 1:25 AM, "Nicolas DEJEAN"
<nicolas.dejean.ietf@googlemail.com>
wrote:

        
Hello Bora,

2011/7/29 Akyol, Bora A <bora@pnnl.gov>:
          
I think the statement about AMI networks being used as an almost
general
purpose backhaul network for all other devices
is overreaching. I know there are some utilities that are looking
into
this, but a lot more that have shied away from
this vision. Secondly, there are a lot more AMI deployments not using
wireless mesh networks, e.g. using cellular modem,
powerline carrier, etc.
            
I agree that all utilities are not looking into it.
However this is one possible case that should be considered, isn't it?
Could you please precise what you are expecting to be in the draft?
          
I think the draft should be focusing on the applicability of ROLL from
a
technical front
without siting this one case as the only justification.

        
Is it possible to tone this "marketing" text Section 1.1. down and
also
potentially
remove Gas & Water meters from the scope of this document.

            
On our point of view, Gas and Water metering are part of AMI.
          
This is not the widely-held view at least within the US electric
utility
community.
The gas and water meters have capabilities which are quite different
from
electric power meters.
For example, while the electric meter has easy access to mains power,
the
gas/water meters don't.
In most instances, the gas/water service may be provided by a
completely
different entity than the electric
power utility.

At least within the US NIST SGIP CSWG, the gas/water meters and AMI
backhaul were considered out of scope.

Would the document lose technical integrity if the gas/water meter were
either removed or included as an optional.

Regards



        
Could you please elaborate?
According to you, why should Gas and Water be removed from the draft?

Thank you in advance,

Nicolas.

          
Regards

--
Bora Akyol, Pacific Northwest National Laboratory
+1 509 371 6682, bora@pnnl.gov, www.pnnl.gov

_______________________________________________
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

--------------060402040309070105060507-- From prvs=21736f1ad=bora@pnnl.gov Wed Aug 31 13:37:37 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7658921F8F13 for ; Wed, 31 Aug 2011 13:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7R756qlZ3Zv for ; Wed, 31 Aug 2011 13:37:36 -0700 (PDT) Received: from emailgw04.pnl.gov (emailgw04.pnl.gov [192.101.109.35]) by ietfa.amsl.com (Postfix) with ESMTP id 05B0F21F8F09 for ; Wed, 31 Aug 2011 13:37:35 -0700 (PDT) Received: from emailhub01.pnl.gov ([130.20.251.61]) by emailgw04.pnl.gov with ESMTP/TLS/AES128-SHA; 31 Aug 2011 13:39:07 -0700 Received: from Email05.pnl.gov ([130.20.251.70]) by emailhub01.pnl.gov ([130.20.251.61]) with mapi; Wed, 31 Aug 2011 13:39:07 -0700 From: "Akyol, Bora A" To: "Salazar, Ruben" , Jorjeta Jetcheva Date: Wed, 31 Aug 2011 13:39:05 -0700 Thread-Topic: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Thread-Index: AcxoHgdouVr1zpYlRQ2FeCJZrDyWRQ== Message-ID: In-Reply-To: <4EA811E84AEC874FA69EE87C8C6BBEB5869A3495B3@FRPARSV10.mx.bm.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: D?jean Nicolas , "roll@ietf.org" Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 20:37:37 -0000 Hi Ruben I think if you are in rural US (think Montana), I am not sure wireless mesh network is going to have any advantages for coverage when compared to cellular. Regardless, I would propose that the suggested wording below is used to replace the existing paragraph in this draft. In one type of AMI network, electric meters are interconnected into multi-hop mesh networks, each of which is connected to a backhaul network leading to the utility network through a network aggregation point (NAP). In a multi-hop mesh network, each electric meter mesh may have up toseveral thousand wireless endpoints, with densities varying based on the area and the terrain. Apartment buildings in urban centers may have hundreds of meters in close proximity, whereas rural areas may have sparse node distributions and include nodes that only have one or two network neighbors. Paths in the mesh between a network device and the nearest aggregation point may be composed of several hops or even tens of hops. Do you have any objections? Thanks --=20 Bora Akyol, Pacific Northwest National Laboratory +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov On 8/31/11 10:59 AM, "Salazar, Ruben" wrote: >All, >The benefit of multi-hop networks is clear as it relates to geography >coverage: that is why star topologies have some hidden repeat-route-relay >features/mechanisms to extend coverage, which comes naturally with mesh >topologies. And this statement applies to both wireless and wired >networks. >Regards > >Ruben Salazar >Director Research and Technology >Landis+Gyr >Energy Management Solutions >Office: +1 678 258 3165 >Ruben.Salazar@landisgyr.com >www.landisgyr.com >manage energy better > > >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >Jetcheva, Jorjeta >Sent: Wednesday, August 31, 2011 1:17 PM >To: Akyol, Bora A >Cc: D?jean Nicolas; roll@ietf.org >Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt > >Hi Bora and all, > >There were some comments on the list related to adding text about the >applicability of multi-hop vs. single-hop deployments. This paragraph >attempted to distinguish between the two. Perhaps it is not necessary to >motivate the existence/use of multi-hop networks because they are already >the focus of the protocol development within this group. > >Does anyone else have any additional comments regarding including text >about the benefits of multi-hop networks as compared to single-hop >networks in the draft? > >Thanks, Jorjeta > >Jorjeta Jetcheva, Ph.D. >Principal Engineer, Architecture & Standards >CTO Office >Itron, Inc. > > >-----Original Message----- >From: Akyol, Bora A [mailto:bora@pnnl.gov] >Sent: Wednesday, August 31, 2011 9:13 AM >To: Jetcheva, Jorjeta >Cc: D?jean Nicolas; roll@ietf.org >Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt > >Hi again, > >My point is that this statement adds no value to the document and in my >opinion subtracts value. >The alternate wording I suggested is technical and avoids "markitecture" >type statements. > >I meant powerline (as in Aclara TWACS or the newer technologies) which is >essentially a single hop technology. > >I believe the cost effectiveness of a particular technology highly depends >on the OPEX as well as the CAPEX, >and customer density. I don't think we should take that on in an IETF >document. > >Regards > > >-- >Bora Akyol, Pacific Northwest National Laboratory >+1 509 371 6682, bora@pnnl.gov, www.pnnl.gov > > > > >On 8/31/11 9:05 AM, "Jetcheva, Jorjeta" >wrote: > >>Hello Bora, >> >>The text in this paragraph doesn't actually use the word "substantial", >>and I think you meant "wireline", not "powerline". >> >>What would you consider to be a "substantiated" statement of the >>applicability/benefits of mesh networks relative to other deployment >>paradigms? >> >>Thanks, Jorjeta >> >>Jorjeta Jetcheva, Ph.D. >>Principal Engineer, Architecture & Standards >>CTO Office >>Itron, Inc. >> >> >>-----Original Message----- >>From: Akyol, Bora A [mailto:bora@pnnl.gov] >>Sent: Wednesday, August 31, 2011 8:40 AM >>To: Jetcheva, Jorjeta >>Cc: D?jean Nicolas; roll@ietf.org >>Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt >> >> >>Hi Jorjeta >> >>Sorry, I had two comments in my original email. One was regarding >>gas/power meters and the second regarding the non-technical slant in the >>introduction. >>The modified paragraph that I proposed is related to the second point. >> >>To answer your question, I disagree with the unbsubstantiated statement >>that multi-hop wireless mesh networks have substantial cost benefits >>compared to either powerline or single-hop (e.g. cellular modems) >>networks. >>I am not saying this is completely wrong, I am saying that this statement >>does not belong in an IETF document since it has no relevance to ROLL >>or the applicability of ROLL to AMI networks. I think the paragraph I >>proposed is clear-cut and technically accurate without having a bias >>towards the use of wireless mesh networks. >> >>Regards >> >>Bora >> >>-----Original Message----- >>From: Jetcheva, Jorjeta [mailto:Jorjeta.Jetcheva@itron.com] >>Sent: Wednesday, August 31, 2011 8:35 AM >>To: Akyol, Bora A >>Cc: D?jean Nicolas; roll@ietf.org >>Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt >> >>Hello Bora, >> >>The paragraph you cited does not reference anything related to water or >>gas meters which was the topic of your earlier comment and the discussion >>that followed. Is this perhaps not the right paragraph or is this the >>beginning of a new discussion? >> >>As far as the benefits of multi-hop networks over wireline or cellular >>backhaul, I think that lower cost and deployment complexity are pretty >>commonly cited. Do you disagree with this statement? >> >>Thanks, Jorjeta >> >>Jorjeta Jetcheva, Ph.D. >>Principal Engineer, Architecture & Standards CTO Office Itron, Inc. >> >> >>-----Original Message----- >>From: Akyol, Bora A [mailto:bora@pnnl.gov] >>Sent: Wednesday, August 31, 2011 8:09 AM >>To: Nicolas DEJEAN >>Cc: Jetcheva, Jorjeta; roll@ietf.org >>Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt >> >> >>Hi Nicolas >> >>Yes, we had a private email exchange off-list. >> >>I would like to suggest alternate wording for this paragraph as follows: >> >>ORIGINAL: >> >> Electric meters are often interconnected into multi-hop mesh >> networks, each of which is connected to a backhaul network leading to >> the utility network through a network aggregation point (NAP). These >> kinds of networks increase coverage and reduce installation cost, >> time and complexity, as well as operational costs, as compared to >> single-hop wireless networks, relying on a wireline or cellular >> backhaul. Each electric meter mesh typically has on the order of >> several thousand wireless endpoints, with densities varying based on >> the area and the terrain. Apartment buildings in urban centers may >> have hundreds of meters in close proximity, whereas rural areas may >>have sparse node distributions and include nodes that only have one or >>two network neighbors. Paths in the mesh between a network device >> and the nearest aggregation point may be composed of several hops or >> even tens of hops. >> >> >>ALTERNATE WORDING: >> >> >>In one type of AMI network, electric meters are interconnected into >>multi-hop mesh >>networks, each of which is connected to a backhaul network leading to >>the utility network through a network aggregation point (NAP). >> >>>mesh> >> >>In a multi-hop mesh network, each electric meter mesh may have up to >>several thousand wireless endpoints, with densities varying based on >>the area and the terrain. Apartment buildings in urban centers may >>have hundreds of meters in close proximity, whereas rural areas may >>have sparse node distributions and include nodes that only have one or >>two >>network neighbors. >>Paths in the mesh between a network device >>and the nearest aggregation point may be composed of several hops or >>even tens of hops. >> >> >> >>What do you think? >> >>Thanks >> >> >>-- >>Bora Akyol, Pacific Northwest National Laboratory >>+1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >> >> >> >> >>On 8/31/11 4:23 AM, "Nicolas DEJEAN" >>wrote: >> >>>Hello Bora, >>> >>>Did Jorjeta answered your concerns about an AMI network considered as >>>a backhaul for Gas and Water? >>> >>>Thank you in advance, >>> >>>Nicolas. >>> >>>2011/8/30 Jetcheva, Jorjeta : >>>> Hello Bora, >>>> >>>>> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >>>>> backhaul were considered out of scope. >>>> >>>> Actually AMI backhaul for gas and water meters is very much in scope >>>>as >>>>per the NIST Wireless Guidelines (PAP2) work and the related >>>>SG-Communications/SG-Net work. CSWG coordinates with the PAPs so they >>>>should be aware of this. >>>> >>>> Jorjeta >>>> >>>> Jorjeta Jetcheva, Ph.D. >>>> Principal Engineer, Architecture & Standards >>>> CTO Office >>>> Itron, Inc. >>>> >>>> >>>> -----Original Message----- >>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >>>>Of >>>>Akyol, Bora A >>>> Sent: Tuesday, August 30, 2011 10:37 AM >>>> To: Nicolas DEJEAN >>>> Cc: roll@ietf.org >>>> Subject: Re: [Roll] I-D Action: >>>>draft-ietf-roll-applicability-ami-01.txt >>>> >>>> Hi Nicolas >>>> >>>> Thank you for your response. >>>> >>>> Please see my comments within >>>> -- >>>> Bora Akyol, Pacific Northwest National Laboratory >>>> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>>> >>>> >>>> >>>> >>>> On 8/30/11 1:25 AM, "Nicolas DEJEAN" >>>> >>>> wrote: >>>> >>>>>Hello Bora, >>>>> >>>>>2011/7/29 Akyol, Bora A : >>>>>> I think the statement about AMI networks being used as an almost >>>>>>general >>>>>> purpose backhaul network for all other devices >>>>>> is overreaching. I know there are some utilities that are looking >>>>>>into >>>>>> this, but a lot more that have shied away from >>>>>> this vision. Secondly, there are a lot more AMI deployments not >>>>>>using >>>>>> wireless mesh networks, e.g. using cellular modem, >>>>>> powerline carrier, etc. >>>>> >>>>>I agree that all utilities are not looking into it. >>>>>However this is one possible case that should be considered, isn't it? >>>>>Could you please precise what you are expecting to be in the draft? >>>> >>>> I think the draft should be focusing on the applicability of ROLL from >>>>a >>>> technical front >>>> without siting this one case as the only justification. >>>> >>>>> >>>>>> >>>>>> Is it possible to tone this "marketing" text Section 1.1. down and >>>>>>also >>>>>> potentially >>>>>> remove Gas & Water meters from the scope of this document. >>>>>> >>>>> >>>>>On our point of view, Gas and Water metering are part of AMI. >>>> >>>> This is not the widely-held view at least within the US electric >>>>utility >>>> community. >>>> The gas and water meters have capabilities which are quite different >>>>from >>>> electric power meters. >>>> For example, while the electric meter has easy access to mains power, >>>>the >>>> gas/water meters don't. >>>> In most instances, the gas/water service may be provided by a >>>>completely >>>> different entity than the electric >>>> power utility. >>>> >>>> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >>>> backhaul were considered out of scope. >>>> >>>> Would the document lose technical integrity if the gas/water meter >>>>were >>>> either removed or included as an optional. >>>> >>>> Regards >>>> >>>> >>>> >>>>>Could you please elaborate? >>>>>According to you, why should Gas and Water be removed from the draft? >>>>> >>>>>Thank you in advance, >>>>> >>>>>Nicolas. >>>>> >>>>>> Regards >>>>>> >>>>>> -- >>>>>> Bora Akyol, Pacific Northwest National Laboratory >>>>>> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>>>>> >>>>>> _______________________________________________ >>>>>> 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 yi.jiazi@gmail.com Wed Aug 31 14:27:27 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F1721F8E2D for ; Wed, 31 Aug 2011 14:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQ9lcgL+AeD4 for ; Wed, 31 Aug 2011 14:27:26 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2E521F8E27 for ; Wed, 31 Aug 2011 14:27:25 -0700 (PDT) Received: by wyg8 with SMTP id 8so984821wyg.31 for ; Wed, 31 Aug 2011 14:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=qlhcvMWRKe4JhNx+hkY0197JwJDxHX5yq60pL+c7kD4=; b=bkbeQHdagi1OVis8rnu8E/Dv5ifWJcM8W268ySE8LqMG2SLBTIAaviTrAbCLL71KlW hDnbTew3dWy2gGokkspgEDR24nmFCUSreq4uzCxi4wIQ95jBk21Uu5WuJ/BwEiUlF3QF 7umh7dQxwemdXoOVsg1E+4pMS8KKBnLFqxse8= Received: by 10.227.36.4 with SMTP id r4mr841890wbd.24.1314826132610; Wed, 31 Aug 2011 14:28:52 -0700 (PDT) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr [89.87.201.6]) by mx.google.com with ESMTPS id n20sm5799128wbh.33.2011.08.31.14.28.51 (version=SSLv3 cipher=OTHER); Wed, 31 Aug 2011 14:28:51 -0700 (PDT) Message-ID: <4E5EA792.7040306@gmail.com> Date: Wed, 31 Aug 2011 23:28:50 +0200 From: Jiazi YI User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 CC: roll WG References: <1483809161.144962.1314763722334.JavaMail.root@mail05.pantherlink.uwm.edu> <4884.1314797912@marajade.sandelman.ca> <8CA251EF-2842-453A-964A-E3F30713917A@cisco.com> In-Reply-To: <8CA251EF-2842-453A-964A-E3F30713917A@cisco.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 21:27:27 -0000 Dear all, On 8/31/11 6:39 PM, JP Vasseur wrote: > Dear Thomas, > > On Aug 31, 2011, at 5:54 PM, Thomas Heide Clausen wrote: > >> I think that this is somewhat going to the crux of what I was referring to when I suggested updates/obsoletes RPL in case this (or, any) compression scheme is introduced. >> >> As I understood the original design scope of ROLL, as retained in the charter, 802.15.4 was one of the (but, not the only) target L2's. It may be that a less verbose message format is required for 802.15.4 than that currently proposed in RPL - in fact, we've got some indications from our testing that this is the case (even for stock RPL) to avoid fragmentation. >> >> However then the working group should fix the problem in RPL by updating that specification, > Once again, there is no fix to have. > > Mukul is proposing an optional compression mechanism, currently discussed by the WG, that's it. Considering this "optional mechanism", I think some of us might concern: 1. The interoperability with the "main mechanism". It's hard for me to agree the statement that "there is no danger of lack of interoperability" for a protocol -- especially for a "optional mechanism" with its main document, developed in almost the same period. Even for a router with this compression mechanism, it might facing the problem of sending out message in which format. 2. If the interoperability is hard to achieve, it's better to make it clear how to make the choices: - in which kind of scenarios, this should be applied, and what's the benefit of it regarding reducing fragmentation and overhead. - what is the cost of using this option (performance, complexity, etc?) If the cost of compression is acceptable and considering the scale of network and heterogeneous environment, it seems to me that, for this "optional mechanism", it's actually always necessary. If it doesn't do any harm to the performance, it might make more sense to update RPL itself ... Considering the complexity, if I was a engineer who needs to implement RPL, I won't mind reading 4 more pages, after taking care of the 160-page RPL draft (RFC), to save the trouble of interoperability and fragmentation. respectfully yours, Jiazi > > Thanks. > > JP. > >> rather than propose an alternative, incompatible message format as an option which - as Michael has pointed out in this and previous messages - necessitating writing/testing multiple different parsers, additional signaling to ensure that in a given deployment messages are sent in the "right" format (or, do we disallow heterogenous deployments?) etc. >> >> I'm concerned that the WG, so early after (well, before) that RPL is published as RFC feels the need to consider such "patches" to the protocol. >> >> Respectfully yours, >> >> Thomas >> >> On Aug 31, 2011, at 15:38 , Michael Richardson wrote: >> >>>>>>>> "Mukul" == Mukul Goyal writes: >>> Mukul> I understand your preference for GHC scheme. As for our >>> Mukul> scheme, it seems to me that you would like our scheme much >>> Mukul> better if there is a way for a node to solicit >>> Mukul> compressed/uncompressed DIOs. Is my understanding correct? >>> Mukul> This could be done by a simple DIS flag. >>> >>> No, I wouldn't like that. I'd like not to have to write and test two >>> parsers for options, and I'd like the scheme not to fall apart when we >>> introduce another option type. >>> >>> I will evaluate GHC method, and write a draft this long weekend with my >>> results. If anyone has sample RPL messages they want me to consider, >>> I would appreciate a PCAP file, otherwise, I'll evaluate only my own. >>> In particular, I need more examples of metric options. >>> >>> >>> -- >>> ] He who is tired of Weird Al is tired of life! | firewalls [ >>> ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ >>> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ >>> Kyoto Plus: watch the video >>> then sign the petition. >>> >>> >>> >>> >>> >>> >> _______________________________________________ >> 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 -- Jiazi YI From mcr@sandelman.ca Wed Aug 31 14:44:25 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D180421F8EF3 for ; Wed, 31 Aug 2011 14:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.782 X-Spam-Level: X-Spam-Status: No, score=-1.782 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmkF72HJ5FPB for ; Wed, 31 Aug 2011 14:44:25 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6E90521F8EF2 for ; Wed, 31 Aug 2011 14:44:25 -0700 (PDT) Received: from marajade.sandelman.ca (wlan204.sandelman.ca [209.87.252.204]) by relay.sandelman.ca (Postfix) with ESMTPS id 89FEAA0067 for ; Wed, 31 Aug 2011 17:45:12 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 2F73798C6E for ; Wed, 31 Aug 2011 17:46:23 -0400 (EDT) From: Michael Richardson To: roll WG In-Reply-To: <2507C27F-0589-488C-902F-52B55A0FCE49@thomasclausen.org> References: <1483809161.144962.1314763722334.JavaMail.root@mail05.pantherlink.uwm.edu> <4884.1314797912@marajade.sandelman.ca> <8CA251EF-2842-453A-964A-E3F30713917A@cisco.com> <2507C27F-0589-488C-902F-52B55A0FCE49@thomasclausen.org> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Wed, 31 Aug 2011 17:46:23 -0400 Message-ID: <24100.1314827183@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 21:44:25 -0000 >>>>> "Thomas" == Thomas Heide Clausen writes: Thomas> I'd much like a routing protocol, designed for low-power, Thomas> lossy networks and with low-MTU MACs as one of its Thomas> design-target to be able to run over these networks. If Thomas> _this_ early a need for an alternative, more compact, packet Thomas> format is identified, then by all means let's get RPL Thomas> updated to use that alternative, more compact, packet Thomas> format. I have absolutely no problems with that. +1