From jpv@cisco.com Mon Jul 4 14:16: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 A17F521F8556 for ; Mon, 4 Jul 2011 14:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.576 X-Spam-Level: X-Spam-Status: No, score=-110.576 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 7MUy-Ifyg3dp for ; Mon, 4 Jul 2011 14:16:11 -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 7EEEE21F8555 for ; Mon, 4 Jul 2011 14:16:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=4865; q=dns/txt; s=iport; t=1309814171; x=1311023771; h=from:subject:date:references:to:message-id:mime-version; bh=DnQAPm/cz0x6bIUlTzpCr+Hxu4WZBo4d/KORNB4Mmm8=; b=A5rMcYhqtLxUWU9gOYBGY7aXiJRrITE/gHuG2q7kJ14dnbbE0fNQ7DDG pAxyHEEffbH6OOrgyhHrfsOB/BPBZWEH+9+VfdUx/gzk6GJe0O7t5bDFH K+lkZDX3kjQu453nEln7/qC0vT63nqagqJu5MY/5lB306SSUPCjBLu2X7 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAE8sEk5Io8UT/2dsb2JhbABTp3x3iHqjXp1hhjYEkjaEeAmLNw X-IronPort-AV: E=Sophos;i="4.65,475,1304294400"; d="scan'208,217";a="40549552" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-2.cisco.com with ESMTP; 04 Jul 2011 21:16:09 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p64LG7HD012790 for ; Mon, 4 Jul 2011 21:16:09 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Jul 2011 23:16:08 +0200 Received: from [10.62.125.30] ([10.55.86.137]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Jul 2011 23:16:07 +0200 From: JP Vasseur Content-Type: multipart/alternative; boundary=Apple-Mail-116-786837163 Date: Mon, 4 Jul 2011 21:08:38 +0200 References: <61CA521C-CA47-41D3-996B-F2483D20844D@cisco.com> To: ROLL WG Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 04 Jul 2011 21:16:07.0512 (UTC) FILETIME=[9701E580:01CC3A8F] Subject: [Roll] Fwd: Provisional Fwd: ROLL - Requested session has been scheduled for IETF 81 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, 04 Jul 2011 21:16:12 -0000 --Apple-Mail-116-786837163 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii just a gentle reminder to let us know by July 8 if you need a slot. Many Thanks. JP. Begin forwarded message: > From: JP Vasseur > Date: June 25, 2011 5:52:50 AM GMT+02:00 > To: ROLL WG > Subject: [Roll] Provisional Fwd: ROLL - Requested session has been = scheduled for IETF 81 >=20 > Dear all, >=20 > The provisional ROLL WG meeting slot is >=20 >> ROLL Session 1 (2 hours) >> Friday, Afternoon Session I 1300-1400 >> Room Name: 208 AB >> ---------------------------------------------- >>=20 >>=20 >>=20 >> Requested Information: >>=20 >>=20 >> --------------------------------------------------------- >> Working Group Name: roll >> Area Name: Routing Area >> Session Requester: JP Vasseur >>=20 >> Number of Sessions: 1 >> Length of Session(s): 2 hours >>=20 >=20 > Please indicate to the chairs before July 8 if you are requesting a = slot. >=20 > Thanks. >=20 > JP. >=20 >=20 >>=20 >>=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-116-786837163 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii just = a gentle reminder to let us know by July 8 if you need a = slot.

Many = Thanks.

JP.

Begin forwarded = message:

From: JP Vasseur <jpv@cisco.com>
Date: June 25, 2011 = 5:52:50 AM GMT+02:00
To: ROLL WG <roll@ietf.org>
Subject: [Roll] = Provisional Fwd: ROLL - Requested session has been scheduled for IETF = 81

Dear all,

The provisional ROLL WG = meeting slot is

ROLL Session 1 (2 = hours)
Friday, Afternoon = Session I 1300-1400
Room Name: = 208 AB
----------------------------------------------



Requested = Information:


---------------------------------------------------------
Working Group Name: = roll
Area Name: Routing = Area
Session Requester: JP = Vasseur

Number of = Sessions: 1
Length of = Session(s):  2 hours


Please indicate to the chairs before = July 8 if you are requesting a = slot.

Thanks.

JP.





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

= --Apple-Mail-116-786837163-- From vincent.brillault@imag.fr Thu Jul 7 02:21: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 7A07821F8677 for ; Thu, 7 Jul 2011 02:21: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEkMrnm3Gsxp for ; Thu, 7 Jul 2011 02:21:57 -0700 (PDT) Received: from mx.lerya.net (lerya.net [213.251.186.118]) by ietfa.amsl.com (Postfix) with ESMTP id 9277121F862D for ; Thu, 7 Jul 2011 02:21:57 -0700 (PDT) Received: from fea.lerya.net (fea.lerya.net [10.9.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.lerya.net (Postfix) with ESMTPS id 7178662108 for ; Thu, 7 Jul 2011 11:22:27 +0200 (CEST) Received: by fea.lerya.net (Postfix, from userid 1042) id D4FEB20042; Thu, 7 Jul 2011 11:21:45 +0200 (CEST) Date: Thu, 7 Jul 2011 11:21:45 +0200 From: Vincent Brillault To: roll@ietf.org Message-ID: <20110707092145.GB18094@Fea> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline X-Mailer: Mutt 1.5.x User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [Roll] Section 11.2.2.3. of draft-ietf-roll-rpl-19 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 09:21:58 -0000 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, I have some problems with Section 11.2.2.3. and its "DAO inconsistency loop recovery". It seems to work, but only if I interpret some terms in two different ways: ---- Let's consider a single DODAG, operating in storing mode without multicast support and without the behaviors described in rpl-p2p. Let's consider 6 nodes. Each have one preferred parent, the OF is not relevant here. A1 --- A2 --!-- | | |----- B2 --- C1 --- C2 --- D "--" or "|" means that the connection is used. "-!-" means that an existing connection is unused. D sends a DAO, the routing states for D are: A1 A2 | |----> B2 --> C1 --> C2 --> D C1 reboots, and attaches to A2. C2 and D follow C1 : A1 --- A2 --- C1 --- C2 --- D | | |----- B2 --!-- D sends a DAO, the routing states for D are : A1 --> A2 --> C1 --> C2 --> D | B2 --->| We can see that, as D just re-announces the new route and A1 is not able to transfer to B2 the cleaning information, that B2 has an unclean state that will stay until a time-out. D disappears (it could for example reattach directly to A1 or just die =66rom energy exhaustion): A1 --- A2 --- C1 --- C2 | | |----- B2 --!--=20 A1 --> A2 --> C1 --> C2 | B2 --->| Now B2 wants to send a message to D. As B2 has a recorded route to C2 and we don't use rpl-p2p, B2 sends a message directly to C1. C1 receives a downward message to D, with a correct Packet Information (correct instance and rank) and forwards it to C2. Section 11.2.2.3. of the current draft apply : """ In a general manner, a packet that goes Down should never go Up again. If DAO inconsistency loop recovery is applied, then the router SHOULD send the packet back to the parent that passed it with the Forwarding-Error 'F' bit set and the 'O' bit left untouched. Otherwise the router MUST silently discard the packet. """ C2 will send back the message to C1, with the O flag untouched. C1 will clean the route and try to send it. I don't understand the end of Section 11.2.2.3. : """ Upon receiving a packet with a Forwarding-Error bit set, the node MUST remove the routing states that caused forwarding to that neighbor, clear the Forwarding-Error bit and attempt to send the packet again. The packet may be sent to an alternate neighbor, after the expiration of a user-configurable implementation specific timer. If that alternate neighbor still has an inconsistent DAO state via this node, the process will recurse, this node will set the Forwarding-Error 'F' bit and the routing state in the alternate neighbor will be cleaned up as well. """ C1 receive a packet with a Forwarding-Error bit set and wants to send it to the only route present : its parent. The draft is unclear on this situation : Can the node change the 'O' flag or not ? I think that the correct behaviour should be to send the packet to a parent (if we have more than one parent, I don't really know how to choose), with the O flag untouched and the Forwarding-Error bit=20 set. As a result, this parent will do the same and as a result the route will be cleaned back to the root.=20 It's an interpretation of the current draft that make the following assumptions: - "neighbor" is RPL independent: it can be a parent - The node MUST NOT change the 'O' flag. - When trying to forward the packet to the parent, "a packet that goes Down " tries to "go Up", so "DAO inconsistency loop recovery is applied" - The terms "the parent that passed it" is interpreted here as "a parent" As a result, the message will go up to A1 (if D reattached to A1, it can receive the message) and the resulting state will be: A1 A2 C1 C2 | B2 --->| One of the two unclean routes have been cleaned. Now B2 tries to reach D again. C1 will receive a correct packet again, but has no route to D so according to its routing table, the packet would have to go up; and then "DAO inconsistency loop recovery is applied".=20 I think that the correct behaviour should be to send the packet with the 'F' bit set to B2. It's an interpretation of the current draft that make the following assumption: - The terms "the parent that passed it" is interpreted here as "the node that passed it" B2 will clean the unclean route state and, as A2 did, will send it back to A1: A1 A2 C1 C2 B2 It works ! ---- RPL seems to be able to clear the irregular routing states but only if we understand the "the parent that passed it" terms in two different ways... Maybe this part of the draft should be rewritten ? Perhaps another way to clear the unclean statecould be to reject directly downward trafic from a node that isn't in the node's parents set. It seems dangerous during Version Number increase but allows faster clean-up. If I missed a part in the current draft(s), please give me the references. Yours Sincerely, Vincent Brillault --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk4VeqkACgkQZq4yYBXMAIBTzgEAuiXdg4XxWrw6sDQqrjgzQeaU hvVCGVmjEO8T9OL/1GYBAK5lmLGmHD0HEyWfdjWRgbkY7ifNMdmol6SKIyuIaUA1 =PC/u -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- From prvs=162732577=Roger.Alexander@cooperindustries.com Thu Jul 7 15: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 1947A21F8712 for ; Thu, 7 Jul 2011 15:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkvqxPXkv4nj for ; Thu, 7 Jul 2011 15:21:43 -0700 (PDT) Received: from cooperlighting-sw.cooperlighting.com (cooperlighting-sw.cooperlighting.com [216.130.131.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6538D21F86F5 for ; Thu, 7 Jul 2011 15:21:38 -0700 (PDT) Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.65,495,1304308800"; d="scan'208";a="17273419" Received: from cipt0174.nam.ci.root ([10.132.108.174]) by cooperlighting-sw.cooperlighting.com with ESMTP; 07 Jul 2011 18:21:37 -0400 Received: from EVS4.NAM.CI.ROOT ([10.132.108.172]) by cipt0174.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jul 2011 18:21:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 7 Jul 2011 18:21:18 -0400 Message-ID: <9BB070DB2D281946859EA89837931EEE0140B34A@EVS4.nam.ci.root> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-alexander-roll-mikey-lln-key-mgmt-00.txt Thread-Index: Acw88Xp7IigEXd3rTrilbhJp0RGEGwAABS8A From: "Alexander, Roger" To: X-OriginalArrivalTime: 07 Jul 2011 22:21:37.0093 (UTC) FILETIME=[3C759F50:01CC3CF4] Cc: "Tsao, Tzeta" Subject: [Roll] FW: New Version Notification for draft-alexander-roll-mikey-lln-key-mgmt-00.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: Thu, 07 Jul 2011 22:21:44 -0000 RGVhciBXRywNCg0KRm9yIHNlY3VyZWQgcm91dGluZywgUlBMIHNlY3VyaXR5IGN1cnJlbnRseSBz cGVjaWZpZXMgYSDigJxwcmUtaW5zdGFsbGVkIGtleeKAnSBhbmQgYW4g4oCcYXV0aGVudGljYXRl ZOKAnSBtb2RlIChzZWUgUlBMIFNlY3Rpb24gMy4yLjMpLiBBcyBpbmRpY2F0ZWQsIGhvd2V2ZXIs IGEgZnVydGhlciBjb21wYW5pb24gc3BlY2lmaWNhdGlvbiBpcyBuZWVkZWQgdG8gZnVsbHkgc3Vw cG9ydCB0aGUg4oCcYXV0aGVudGljYXRlZOKAnSBtb2RlLiBBZGRpdGlvbmFsbHksIGZvciBsYXJn ZSBzY2FsZSBuZXR3b3JrcyB0aGVyZSBtYXkgYmUgcmVxdWlyZW1lbnRzIGZvciBhdXRvbWF0ZWQg a2V5IG1hbmFnZW1lbnQgdXBkYXRlIGV2ZW4gZm9yIHRoZSBsb25nLXRlcm0gc2VjdXJpdHkgY3Jl ZGVudGlhbHMgYXNzb2NpYXRlZCB3aXRoIHRoZSBwcmUtaW5zdGFsbGVkIGtleSBtb2RlLg0KDQpG b3IgTExOIGVudmlyb25tZW50cyBpdCB3aWxsIGFsc28gYmUgZWZmaWNpZW50IHRvIGhhdmUgdGhl IG9wdGlvbiB0byBzaW11bHRhbmVvdXNseSBtYW5hZ2Uga2V5cyBmb3Igb25lIG9yIG1vcmUgY29t bXVuaWNhdGlvbnMgcHJvdG9jb2wgbGF5ZXJzIHdpdGggYSBsaWdodC13ZWlnaHQsIGxvdyBvdmVy aGVhZCBtZWNoYW5pc20uIFJhdGhlciB0aGFuIGF0dGVtcHRpbmcgdG8gcmVpbnZlbnQgdGhlIHdo ZWVsLCB0aGUgYWRhcHRpb24gYW5kIHJlLXVzZSBvZiBhIHZhbGlkYXRlZCBrZXkgbWFuYWdlbWVu dCBzY2hlbWUgd291bGQgYmUgYmVuZWZpY2lhbC4gSW4gdGhhdCByZWdhcmQgdGhlIE1JS0VZIHBy b3RvY29sIChSRkMzODMwKSBhbmQgdGhlIG9wdGlvbnMgb2Ygc3Vic2VxdWVudCBleHRlbnNpb25z IChpbmNsdWRpbmcgW1JGQzQ1NjNdLCBbUkZDNDY1MF0sIFtSRkM0NzM4XSwgW1JGQzYwNDNdIGFu ZCBbUkZDNjI2N10pIHByb3ZpZGUgYW4gZXhjZWxsZW50IGNhbmRpZGF0ZS4gVGhlIG11bHRpcGxl IGtleSBtYW5hZ2VtZW50IG1ldGhvZHMgb2YgdGhlIGJhc2UgcHJvdG9jb2wgaW5jbHVkZSBzdXBw b3J0IGZvciBwcmUtc2hhcmVkIGtleXMsIHB1YmxpYy1rZXkgZW5jcnlwdGlvbiwgYW5kIERpZmZp ZS1IZWxsbWFuIGtleSBleGNoYW5nZS4gVGhlIHByb3RvY29sIG9mZmVycyBsb3cgbGF0ZW5jeSBv cHRpb25zIGFuZCBhIGxvdyBvdmVyaGVhZCwgMSBieXRlLWFsaWduZWQgYmluYXJ5IGVuY29kZWQg bWVzc2FnZSBmb3JtYXQgdGhhdCBjYW4gYmUgZW1iZWRkZWQgaW4gb3RoZXIgc2lnbmFsaW5nIHBy b3RvY29scyBvciB0cmFuc3BvcnRlZCBkaXJlY3RseSBvdmVyIFRDUCBvciBVRFAgKHBvcnQgMjI2 OSkuIFRoZXNlIGZlYXR1cmVzIGFsbG93IGZvciBmbGV4aWJsZSBhcHBsaWNhdGlvbiBpbiBkaWZm ZXJlbnQgTExOIGVudmlyb25tZW50cy4gDQoNClRoZSBwcm9wb3NlZCBMTE4gZXh0ZW5zaW9uIHRv IE1JS0VZIHdpbGwgYmUgdG8gYWxsb3cgdXNlIG9mIGFsbCBBRVMtYmFzZWQgYWxnb3JpdGhtcyBh cyB3ZWxsIGFzIHJlLXB1cnBvc2UgaXRzIG11bHRpLXN0cmVhbSBjYXBhYmlsaXRpZXMgdG8gb3B0 aW9uYWxseSBzdXBwb3J0IHNpbXVsdGFuZW91cyBtdWx0aS1sYXllciBrZXkgbWFuYWdlbWVudC4g VGhlc2UgY2hhbmdlcyBtYWludGFpbiB0aGUgZ2VuZXJhbCBsaWdodHdlaWdodCBNSUtFWSBzdHJ1 Y3R1cmUgd2hpbGUgcHJvdmlkaW5nIExMTnMgd2l0aCBhY2Nlc3MgdG8gYW4gYXJyYXkgb2YgdmFs aWRhdGVkIG1ldGhvZHMgZm9yIGltcGxlbWVudGluZyBhdXRvbWF0ZWQgc2Vzc2lvbiBvciBsb25n LXRlcm0gZGV2aWNlIGtleSBtYW5hZ2VtZW50Lg0KDQpUaGUgZHJhZnQgaGlnaGxpZ2h0cyB0aGUg Y2VudHJhbCBlbGVtZW50cyBvZiB0aGUgcHJvcG9zZWQgZXh0ZW5zaW9uLg0KDQpSb2dlcg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFRodXJzZGF5LCBKdWx5 IDA3LCAyMDExIDY6MDIgUE0NClRvOiBBbGV4YW5kZXIsIFJvZ2VyDQpDYzogQWxleGFuZGVyLCBS b2dlcjsgVHNhbywgVHpldGENClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Jk cmFmdC1hbGV4YW5kZXItcm9sbC1taWtleS1sbG4ta2V5LW1nbXQtMDAudHh0DQoNCkEgbmV3IHZl cnNpb24gb2YgSS1ELCBkcmFmdC1hbGV4YW5kZXItcm9sbC1taWtleS1sbG4ta2V5LW1nbXQtMDAu dHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUm9nZXIgQWxleGFuZGVyIGFu ZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1hbGV4 YW5kZXItcm9sbC1taWtleS1sbG4ta2V5LW1nbXQNClJldmlzaW9uOgkgMDANClRpdGxlOgkJIEFk YXB0ZWQgTXVsdGltZWRpYSBJbnRlcm5ldCBLRVlpbmcgKEFNSUtFWSk6IEFuIGV4dGVuc2lvbiBv ZiBNdWx0aW1lZGlhIEludGVybmV0IEtFWWluZyAoTUlLRVkpIE1ldGhvZHMgZm9yIEdlbmVyaWMg TExOIEVudmlyb25tZW50cw0KQ3JlYXRpb24gZGF0ZToJIDIwMTEtMDctMDcNCldHIElEOgkJIElu ZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAyOA0KDQpBYnN0cmFjdDoNCiAg IE11bHRpbWVkaWEgSW50ZXJuZXQgS2V5aW5nIChNSUtFWSkgaXMgYSBrZXkgbWFuYWdlbWVudCBw cm90b2NvbCB1c2VkDQogICBmb3IgcmVhbC10aW1lIGFwcGxpY2F0aW9ucy4gIEFzIHN0YW5kYXJk aXplZCB3aXRoaW4gUkZDMzgzMCBpdA0KICAgZGVmaW5lcyBmb3VyIGtleSBkaXN0cmlidXRpb24g bWV0aG9kcywgaW5jbHVkaW5nIHByZS1zaGFyZWQga2V5cywNCiAgIHB1YmxpYy1rZXkgZW5jcnlw dGlvbiwgYW5kIERpZmZpZS1IZWxsbWFuIGtleSBleGNoYW5nZSwgd2l0aA0KICAgYWxsb3dhbmNl cyBmb3IgcmVhZHkgcHJvdG9jb2wgZXh0ZW5zaW9uLiAgQSBudW1iZXIgb2YgYWRkaXRpb25hbA0K ICAgbWV0aG9kcyBoYXZlIGJlZW4gZGV2ZWxvcGVkIGFuZCBjb250aW51ZSB0byBiZSBidWlsdCBm cm9tIHRoZSBiYXNlDQogICBwcm90b2NvbCAoc2VlIGZvciBleGFtcGxlLCBSRkM0NDQyLCBSRkM0 NTYzLCBSRkM0NjUwLCBSRkM0NzM4LA0KICAgUkZDNTQxMCwgUkZDNjA0MyBhbmQgUkZDNjI2Ny4g IEhvd2V2ZXIsIGluIHNwaXRlIG9mIGl0cyBleHRlbnNpYmlsaXR5DQogICBhbmQgbW9yZSBnZW5l cmFsIGFwcGxpY2FiaWxpdHksIE1JS0VZIGFuZCBpdHMgcmVsYXRlZCBleHRlbnNpb25zIGhhdmUN CiAgIHByaW1hcmlseSBmb2N1c2VkIG9uIHRoZSBzdXBwb3J0IG9mIHRoZSBTZWN1cmUgUmVhbC10 aW1lIFRyYW5zcG9ydA0KICAgUHJvdG9jb2wgKFNSVFApLg0KDQogICBUaGlzIGRvY3VtZW50IHNw ZWNpZmllcyBhIHNpbXBsZSBhZGFwdGF0aW9uIG9mIHRoZSBNSUtFWQ0KICAgc3BlY2lmaWNhdGlv biB0byBhbGxvdyB0aGUgYmFzZSBwcm90b2NvbCBhbmQgaXRzIHZhcmlvdXMga2V5DQogICBtYW5h Z2VtZW50IG1vZGUgZXh0ZW5zaW9ucyB0byBiZSByZWFkaWx5IGFwcGxpZWQgaW4gbW9yZSBnZW5l cmFsDQogICBlbnZpcm9ubWVudHMgYmV5b25kIHRoZSBtdWx0aW1lZGlhIFNSVFAgZG9tYWluLiAg SW4gcGFydGljdWxhciwgdGhlDQogICBkb2N1bWVudCBkZWZpbmVzIGEgcmVwdXJwb3Npbmcgb2Yg dGhlIE1JS0VZIG11bHRpbWVkaWEgY3J5cHRvDQogICBzZXNzaW9ucyBzdHJ1Y3R1cmUgYW5kIGlu dHJvZHVjZXMgYSBzZXQgb2YgbWVzc2FnZSBleHRlbnNpb25zIHRvIHRoZQ0KICAgYmFzZSBzcGVj aWZpY2F0aW9uIHRvIGFsbG93IHRoZSBNSUtFWSBrZXkgbWFuYWdlbWVudCBtZXRob2RzIHRvIGJl DQogICBhcHBsaWVkIHdpdGhpbiBMb3ctcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzIChMTE5zKSBh bmQgb3RoZXIgZ2VuZXJhbA0KICAgY29uc3RyYWluZWQtZGV2aWNlIG5ldHdvcmtzLg0KDQoNCg0K QSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQpodHRwOi8vd3d3LmlldGYub3JnL2lk L2RyYWZ0LWFsZXhhbmRlci1yb2xsLW1pa2V5LWxsbi1rZXktbWdtdC0wMC50eHQNCg0KDQoNCg== From internet-drafts@ietf.org Fri Jul 8 08:52: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 C70F621F8B0C; Fri, 8 Jul 2011 08:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 GfjInQZA67Wd; Fri, 8 Jul 2011 08:52:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325F221F87C5; Fri, 8 Jul 2011 08:52:04 -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.55 Message-ID: <20110708155204.17743.58116.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2011 08:52:04 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-of0-15.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, 08 Jul 2011 15:52: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-15.txt Pages : 13 Date : 2011-07-08 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-15.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-15.txt From internet-drafts@ietf.org Sun Jul 10 23:56: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 1112321F8A6F; Sun, 10 Jul 2011 23:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 UtXiVEPEcqnH; Sun, 10 Jul 2011 23:56:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E43A21F89F7; Sun, 10 Jul 2011 23:56:40 -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.55 Message-ID: <20110711065640.18229.53019.idtracker@ietfa.amsl.com> Date: Sun, 10 Jul 2011 23:56:40 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-04.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, 11 Jul 2011 06:56:41 -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 : Reactive Discovery of Point-to-Point Routes in Low Power= and Lossy Networks Author(s) : Mukul Goyal Emmanuel Baccelli Matthias Philipp Anders Brandt Robert Cragie Jerald Martocci Filename : draft-ietf-roll-p2p-rpl-04.txt Pages : 24 Date : 2011-07-10 Point to point (P2P) communication between arbitrary IPv6 routers in a Low power and Lossy Network (LLN) is a key requirement for many applications. RPL, the IPv6 Routing Protocol for LLNs, constrains the LLN topology to a Directed Acyclic Graph (DAG) and requires the P2P routing to take place along the DAG links. Such P2P routes may be suboptimal and may lead to traffic congestion near the DAG root. This document specifies a P2P route discovery mechanism, complementary to the RPL base functionality. This mechanism allows an IPv6 router to discover and establish, on demand, a route to another IPv6 router in the LLN such that the discovered route meets specified constraints. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-04.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-p2p-rpl-04.txt From internet-drafts@ietf.org Mon Jul 11 00:30: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 5003B21F89C8; Mon, 11 Jul 2011 00:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 y+OumYdM0lF4; Mon, 11 Jul 2011 00:30:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B079721F8927; Mon, 11 Jul 2011 00:30:14 -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.55 Message-ID: <20110711073014.6291.69366.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 00:30:14 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-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: Mon, 11 Jul 2011 07:30:15 -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 : A Mechanism to Measure the Quality of a Point-to-point R= oute in a Low Power and Lossy Network Author(s) : Mukul Goyal Emmanuel Baccelli Anders Brandt Robert Cragie Jerald Martocci Filename : draft-ietf-roll-p2p-measurement-01.txt Pages : 14 Date : 2011-07-11 This document specifies a mechanism that enables an RPL router to measure the quality of an existing route to another RPL router in a low power and lossy network, thereby allowing the router to decide if it wants to initiate the discovery of a more optimal route. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-measurement-01.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-p2p-measurement-01.txt From prvs=1672db6a9=Roger.Alexander@cooperindustries.com Tue Jul 12 13:39: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 6563121F8B3C for ; Tue, 12 Jul 2011 13:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sfKdjrdGEuf for ; Tue, 12 Jul 2011 13:39:27 -0700 (PDT) Received: from cooperlighting-sw.cooperlighting.com (cooperlighting-sw.cooperlighting.com [216.130.131.68]) by ietfa.amsl.com (Postfix) with ESMTP id B2D2A21F8B35 for ; Tue, 12 Jul 2011 13:39:27 -0700 (PDT) Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.65,522,1304308800"; d="scan'208";a="17820726" Received: from cipt0175.nam.ci.root ([10.132.108.175]) by cooperlighting-sw.cooperlighting.com with ESMTP; 12 Jul 2011 16:39:27 -0400 Received: from EVS4.NAM.CI.ROOT ([10.132.108.172]) by cipt0175.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Jul 2011 16:39:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Tue, 12 Jul 2011 16:39:25 -0400 Message-ID: <9BB070DB2D281946859EA89837931EEE014891EC@EVS4.nam.ci.root> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification fordraft-alexander-roll-mikey-lln-key-mgmt-01.txt thread-index: AcxAyIDRwv7JezaLTxuziJRzycgMwwAAH+6wAAKvLKA= From: "Alexander, Roger" To: X-OriginalArrivalTime: 12 Jul 2011 20:39:26.0600 (UTC) FILETIME=[CA776080:01CC40D3] Subject: [Roll] FW: New Version Notification fordraft-alexander-roll-mikey-lln-key-mgmt-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, 12 Jul 2011 20:39:28 -0000 RGVhciBXRywNCg0KVGhlIGZvbGxvd2luZyBkcmFmdCBoYXMgYmVlbiB1cGRhdGVkIHRvIHByb3Zp ZGUgcGFydGljdWxhciBhbGlnbm1lbnQgc3VwcG9ydCBmb3IgdGhlIFJQTCByb3V0aW5nIHByb3Rv Y29sIHNlY3VyaXR5LiANCg0KWW91ciBmZWVkYmFjayBhbmQgY29tbWVudHMgYXJlIGFwcHJlY2lh dGVkLg0KDQpUaGFua3MsDQoNClJvZ2VyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmddIA0KU2VudDogVHVlc2RheSwgSnVseSAxMiwgMjAxMSAzOjE5IFBNDQpUbzogQWxleGFu ZGVyLCBSb2dlcg0KQ2M6IEFsZXhhbmRlciwgUm9nZXI7IFRzYW8sIFR6ZXRhDQpTdWJqZWN0OiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yZHJhZnQtYWxleGFuZGVyLXJvbGwtbWlrZXktbGxu LWtleS1tZ210LTAxLnR4dA0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYWxleGFuZGVy LXJvbGwtbWlrZXktbGxuLWtleS1tZ210LTAxLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IFJvZ2VyIEFsZXhhbmRlciBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRv cnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtYWxleGFuZGVyLXJvbGwtbWlrZXktbGxuLWtleS1tZ210 DQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBBZGFwdGVkIE11bHRpbWVkaWEgSW50ZXJuZXQgS0VZ aW5nIChBTUlLRVkpOiBBbiBleHRlbnNpb24gb2YgTXVsdGltZWRpYSBJbnRlcm5ldCBLRVlpbmcg KE1JS0VZKSBNZXRob2RzIGZvciBHZW5lcmljIExMTiBFbnZpcm9ubWVudHMNCkNyZWF0aW9uIGRh dGU6CSAyMDExLTA3LTEyDQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBv ZiBwYWdlczogMzENCg0KQWJzdHJhY3Q6DQogICBNdWx0aW1lZGlhIEludGVybmV0IEtleWluZyAo TUlLRVkpIGlzIGEga2V5IG1hbmFnZW1lbnQgcHJvdG9jb2wgdXNlZA0KICAgZm9yIHJlYWwtdGlt ZSBhcHBsaWNhdGlvbnMuICBBcyBzdGFuZGFyZGl6ZWQgd2l0aGluIFJGQzM4MzAgaXQNCiAgIGRl ZmluZXMgZm91ciBrZXkgZGlzdHJpYnV0aW9uIG1ldGhvZHMsIGluY2x1ZGluZyBwcmUtc2hhcmVk IGtleXMsDQogICBwdWJsaWMta2V5IGVuY3J5cHRpb24sIGFuZCBEaWZmaWUtSGVsbG1hbiBrZXkg ZXhjaGFuZ2UsIHdpdGgNCiAgIGFsbG93YW5jZXMgZm9yIHJlYWR5IHByb3RvY29sIGV4dGVuc2lv bi4gIEEgbnVtYmVyIG9mIGFkZGl0aW9uYWwNCiAgIG1ldGhvZHMgaGF2ZSBiZWVuIGRldmVsb3Bl ZCBhbmQgY29udGludWUgdG8gYmUgYnVpbHQgZnJvbSB0aGUgYmFzZQ0KICAgcHJvdG9jb2wgKHNl ZSBmb3IgZXhhbXBsZSwgUkZDNDQ0MiwgUkZDNDU2MywgUkZDNDY1MCwgUkZDNDczOCwNCiAgIFJG QzU0MTAsIFJGQzYwNDMgYW5kIFJGQzYyNjcuICBIb3dldmVyLCBpbiBzcGl0ZSBvZiBpdHMgZXh0 ZW5zaWJpbGl0eQ0KICAgYW5kIG1vcmUgZ2VuZXJhbCBhcHBsaWNhYmlsaXR5LCBNSUtFWSBhbmQg aXRzIHJlbGF0ZWQgZXh0ZW5zaW9ucyBoYXZlDQogICBwcmltYXJpbHkgZm9jdXNlZCBvbiB0aGUg c3VwcG9ydCBvZiB0aGUgU2VjdXJlIFJlYWwtdGltZSBUcmFuc3BvcnQNCiAgIFByb3RvY29sIChT UlRQKS4NCg0KICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBzaW1wbGUgYWRhcHRhdGlvbiBv ZiB0aGUgTUlLRVkNCiAgIHNwZWNpZmljYXRpb24gdG8gYWxsb3cgdGhlIGJhc2UgcHJvdG9jb2wg YW5kIGl0cyB2YXJpb3VzIGtleQ0KICAgbWFuYWdlbWVudCBtb2RlIGV4dGVuc2lvbnMgdG8gYmUg cmVhZGlseSBhcHBsaWVkIGluIG1vcmUgZ2VuZXJhbA0KICAgZW52aXJvbm1lbnRzIGJleW9uZCB0 aGUgbXVsdGltZWRpYSBTUlRQIGRvbWFpbi4gIEluIHBhcnRpY3VsYXIsIHRoZQ0KICAgZG9jdW1l bnQgZGVmaW5lcyBhIHJlcHVycG9zaW5nIG9mIHRoZSBNSUtFWSBtdWx0aW1lZGlhIGNyeXB0bw0K ICAgc2Vzc2lvbnMgc3RydWN0dXJlIGFuZCBpbnRyb2R1Y2VzIGEgc2V0IG9mIG1lc3NhZ2UgZXh0 ZW5zaW9ucyB0byB0aGUNCiAgIGJhc2Ugc3BlY2lmaWNhdGlvbiB0byBhbGxvdyB0aGUgTUlLRVkg a2V5IG1hbmFnZW1lbnQgbWV0aG9kcyB0byBiZQ0KICAgYXBwbGllZCB3aXRoaW4gTG93LXBvd2Vy IGFuZCBMb3NzeSBuZXR3b3JrcyAoTExOcykgYW5kIG90aGVyIGdlbmVyYWwNCiAgIGNvbnN0cmFp bmVkLWRldmljZSBuZXR3b3Jrcy4NCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQpBIFVS TCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWFsZXhhbmRlci1yb2xsLW1pa2V5LWxsbi1rZXktbWdtdC0wMQ0KDQoNCg0K From jpv@cisco.com Wed Jul 13 07:51: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 4BEFC11E80FE for ; Wed, 13 Jul 2011 07:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 G7jhox7Nkm00 for ; Wed, 13 Jul 2011 07:51:10 -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 C5A4711E8082 for ; Wed, 13 Jul 2011 07:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=4074; q=dns/txt; s=iport; t=1310568670; x=1311778270; h=from:subject:date:message-id:cc:to:mime-version; bh=E64rgKiMbc/wiu22EYNdaHlNGLrpMUFTvA50xlfvsHA=; b=Qdpr7UwoFL6lzJbmcOISTJB3l9jUnA4o6XQ5SNOIAfrYmmRBSTxsWdVO WeQ/Oah4wuebIDSDDGmgdQXm23fUdr1zNpNNSDeyJv0cyRZyce5Y3f7x2 4sKTMthRVrcmZmj0cqEbHiH77XGQZcG4Ni2qjIe47ywkGtyKeDIjhNyc3 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABSwHU5Io8UQ/2dsb2JhbABTpzx3rjSeJ4VbXwSSYYR/CYtG X-IronPort-AV: E=Sophos;i="4.65,525,1304294400"; d="scan'208,217";a="101856040" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 13 Jul 2011 14:50:10 +0000 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6DEo9nh009024; Wed, 13 Jul 2011 14:50:09 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); Wed, 13 Jul 2011 22:50:09 +0800 Received: from [10.60.114.232] ([10.60.114.232]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jul 2011 22:50:07 +0800 From: JP Vasseur Content-Type: multipart/alternative; boundary=Apple-Mail-73--598560593 Date: Wed, 13 Jul 2011 16:50:04 +0200 Message-Id: <97A1BFC4-BFAB-4B7A-AE34-B99AB60B1AA5@cisco.com> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 13 Jul 2011 14:50:07.0981 (UTC) FILETIME=[2891A9D0:01CC416C] Cc: Julien Meuric Subject: [Roll] Proposed Text to ROLL 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, 13 Jul 2011 14:51:14 -0000 --Apple-Mail-73--598560593 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, Julien and I have been having a discussion on how to better manage our = WG meeting time. As a matter of fact, a number of requested slots are related to IDs that = were already "presented" during previous=20 IETF meetings, refreshed just before the cut-off submission date without = discussion on the mailing list ... As a gentle reminder, the aim of WG meetings is to discuss open issues = that could not be resolved by email=20 attempting to reach a consensus, to be confirmed on the mailing list. You may want to also refer to a similar discussion that we had during = the Routing Area meeting at the last IETF. Few points here: 1) If your ID falls into the WG charter, it is perfectly fine to get a = "presentation" slot when first posted (rev -00) if time permits (priority will be given to slots allocated to resolve = technical issues discussed on the mailing list). Although people attending the WG meeting are supposed to have read each = document, you may want to explain the issue that you are trying to solve, and how. 2) Before requesting a slot, please make sure that your intent is to = discuss specific technical issues related to=20 the document that could not be resolved on the mailing list. In other = words, please do not request slots for IDs=20 for which no discussion took place on the mailing list. With that in mind, could you please send us your slot request no later = than Monday July 18 at noon ET? =20 Julien and I will publish the WG meeting agenda the day after, with some = delays but hopefully an improved agenda. Many Thanks. JP and Julien.= --Apple-Mail-73--598560593 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = all,

Julien and I have been having a discussion on = how to better manage our WG meeting time.

As a = matter of fact, a number of requested slots are related to IDs that were = already "presented" during previous 
IETF meetings, = refreshed just before the cut-off submission date without discussion on = the mailing list ...

As a gentle reminder, = the aim of WG meetings is to discuss open issues that = could not be resolved by email 
attempting to reach a = consensus, to be confirmed on the mailing = list.

You may want to also refer to a similar = discussion that we had during the Routing Area meeting at the last = IETF.

Few points here:
1) If = your ID falls into the WG charter, it is perfectly fine to get a = "presentation" slot when first posted (rev -00) if
time = permits (priority will be given to slots allocated to resolve technical = issues discussed on the mailing list).
Although people = attending the WG meeting are supposed to have read each document, you = may want to explain
the issue that you are trying to solve, = and how.
2) Before requesting a slot, please make sure = that your intent is to discuss specific technical issues related = to 
the document that could not be resolved on the = mailing list. In other words, please do not request slots for = IDs 
for which no discussion took place on the mailing = list.

With that in mind, could you please send = us your slot request no later than Monday July 18 at noon ET? =  
Julien and I will publish the WG meeting agenda the day = after, with some delays but hopefully an = improved
agenda.

Many = Thanks.

JP and Julien.
= --Apple-Mail-73--598560593-- From jpv@cisco.com Wed Jul 13 07:51: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 EF7B211E8101 for ; Wed, 13 Jul 2011 07:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 EujwtmpKHOc3 for ; Wed, 13 Jul 2011 07:51:19 -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 70D4311E8105 for ; Wed, 13 Jul 2011 07:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=4085; q=dns/txt; s=iport; t=1310568678; x=1311778278; h=from:subject:date:message-id:cc:to:mime-version; bh=SdU7YdpSpZa8SRJ6jcOu8pwIrjN3E8EUwNuLTHQj6So=; b=ckdaR4lLko1tjH5GjMkNChA89jHdlzwUxU6HgkcCzJzcdHLew+8nXl8+ CanoohlMrBs/1dRMOrc+dWod++KJ3qpaz+cdaNUk9W2MsIJzIhx74J3Tk q9kA7O5d+J90LsENNAxNsUUF2LDZJICz5LihHc8ehtOC5KPSsi6cmmKUI 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABSwHU5Io8UT/2dsb2JhbABTpzx3rjSeJ4VbXwSSYYR/CYtG X-IronPort-AV: E=Sophos;i="4.65,525,1304294400"; d="scan'208,217";a="101856210" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-1.cisco.com with ESMTP; 13 Jul 2011 14:50:54 +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 p6DEoqHW014017; Wed, 13 Jul 2011 14:50:53 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); Wed, 13 Jul 2011 22:50:53 +0800 Received: from [10.60.114.232] ([10.60.114.232]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jul 2011 22:50:52 +0800 From: JP Vasseur Content-Type: multipart/alternative; boundary=Apple-Mail-74--598514812 Date: Wed, 13 Jul 2011 16:50:50 +0200 Message-Id: <98FFFF13-8EFA-4662-BF64-6B00359E1C0C@cisco.com> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 13 Jul 2011 14:50:52.0464 (UTC) FILETIME=[43153B00:01CC416C] Cc: Julien Meuric Subject: [Roll] Rules to request a "slot" during ROLL WG Meetings 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, 13 Jul 2011 14:51:23 -0000 --Apple-Mail-74--598514812 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, Julien and I have been having a discussion on how to better manage our = WG meeting time. As a matter of fact, a number of requested slots are related to IDs that = were already "presented" during previous=20 IETF meetings, refreshed just before the cut-off submission date without = discussion on the mailing list ... As a gentle reminder, the aim of WG meetings is to discuss open issues = that could not be resolved by email=20 attempting to reach a consensus, to be confirmed on the mailing list. You may want to also refer to a similar discussion that we had during = the Routing Area meeting at the last IETF. Few points here: 1) If your ID falls into the WG charter, it is perfectly fine to get a = "presentation" slot when first posted (rev -00) if time permits (priority will be given to slots allocated to resolve = technical issues discussed on the mailing list). Although people attending the WG meeting are supposed to have read each = document, you may want to explain the issue that you are trying to solve, and how. 2) Before requesting a slot, please make sure that your intent is to = discuss specific technical issues related to=20 the document that could not be resolved on the mailing list. In other = words, please do not request slots for IDs=20 for which no discussion took place on the mailing list. With that in mind, could you please send us your slot request no later = than Monday July 18 at noon ET? =20 Julien and I will publish the WG meeting agenda the day after, with some = delays but hopefully an improved agenda. Many Thanks. JP and Julien.= --Apple-Mail-74--598514812 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = all,

Julien and I have been having a discussion on = how to better manage our WG meeting time.

As a = matter of fact, a number of requested slots are related to IDs that were = already "presented" during previous 
IETF meetings, = refreshed just before the cut-off submission date without discussion on = the mailing list ...

As a gentle reminder, = the aim of WG meetings is to discuss open issues = that could not be resolved by email 
attempting to reach = a consensus, to be confirmed on the mailing = list.

You may want to also refer to a similar = discussion that we had during the Routing Area meeting at the last = IETF.

Few points here:
1) If = your ID falls into the WG charter, it is perfectly fine to get a = "presentation" slot when first posted (rev -00) if
time = permits (priority will be given to slots allocated to resolve technical = issues discussed on the mailing list).
Although people = attending the WG meeting are supposed to have read each document, you = may want to explain
the issue that you are trying to solve, = and how.
2) Before requesting a slot, please make = sure that your intent is to discuss specific technical issues related = to 
the document that could not be resolved on the = mailing list. In other words, please do not request slots for = IDs 
for which no discussion took place on the mailing = list.

With that in mind, could you please send = us your slot request no later than Monday July 18 at noon ET? =  
Julien and I will publish the WG meeting agenda the day = after, with some delays but hopefully an = improved
agenda.

Many = Thanks.

JP and Julien.
= --Apple-Mail-74--598514812-- From jpv@cisco.com Wed Jul 13 07:56: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 C220021F8837 for ; Wed, 13 Jul 2011 07:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 CmEPgrSSY2mi for ; Wed, 13 Jul 2011 07:56:39 -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 87F4C21F8804 for ; Wed, 13 Jul 2011 07:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=5041; q=dns/txt; s=iport; t=1310568998; x=1311778598; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=grLESNh+WvsrqT2SWRXM56cjloW9eywlM0ln2jEt6vk=; b=gGsGOQOpb+At1WFFUgKXC9RuK8ky7mUkRevOTp6T0ZmvYeiJZnuauOIV U5sO5PuzPa49fV31kPIxUvpGSdv3E7c/vfBsJin4/K1blbuIJ9ft0UlBl a/LxT1/5odueslAFDwZKkuXtbl3aIHE47Ig5DAwKzQlaBVxabmnoAMV// M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACmxHU5Io8US/2dsb2JhbABTpzx3iHqlRp4qhVtfBJJhhH8Ji0Y X-IronPort-AV: E=Sophos;i="4.65,525,1304294400"; d="scan'208,217";a="101857510" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 13 Jul 2011 14:56:36 +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 p6DEuaGp011034; Wed, 13 Jul 2011 14:56:36 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, 13 Jul 2011 20:26:36 +0530 Received: from [10.60.114.232] ([10.60.114.232]) by xfe-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jul 2011 20:26:35 +0530 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-78--598172815 From: JP Vasseur In-Reply-To: <98FFFF13-8EFA-4662-BF64-6B00359E1C0C@cisco.com> Date: Wed, 13 Jul 2011 16:56:32 +0200 Message-Id: <5DA9F283-ED2E-40F4-9C3B-936F0527301E@cisco.com> References: <98FFFF13-8EFA-4662-BF64-6B00359E1C0C@cisco.com> To: ROLL WG X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 13 Jul 2011 14:56:35.0203 (UTC) FILETIME=[0F5F0D30:01CC416D] Cc: Julien Meuric Subject: Re: [Roll] Rules to request a "slot" during PCE WG Meetings 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, 13 Jul 2011 14:56:39 -0000 --Apple-Mail-78--598172815 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sorry issues with title ... the tile should of course read: "Rules to = request a "slot" during PCE WG Meetings" On Jul 13, 2011, at 4:50 PM, JP Vasseur wrote: > Dear all, >=20 > Julien and I have been having a discussion on how to better manage our = WG meeting time. >=20 > As a matter of fact, a number of requested slots are related to IDs = that were already "presented" during previous=20 > IETF meetings, refreshed just before the cut-off submission date = without discussion on the mailing list ... >=20 > As a gentle reminder, the aim of WG meetings is to discuss open issues = that could not be resolved by email=20 > attempting to reach a consensus, to be confirmed on the mailing list. >=20 > You may want to also refer to a similar discussion that we had during = the Routing Area meeting at the last IETF. >=20 > Few points here: > 1) If your ID falls into the WG charter, it is perfectly fine to get a = "presentation" slot when first posted (rev -00) if > time permits (priority will be given to slots allocated to resolve = technical issues discussed on the mailing list). > Although people attending the WG meeting are supposed to have read = each document, you may want to explain > the issue that you are trying to solve, and how. > 2) Before requesting a slot, please make sure that your intent is to = discuss specific technical issues related to=20 > the document that could not be resolved on the mailing list. In other = words, please do not request slots for IDs=20 > for which no discussion took place on the mailing list. >=20 > With that in mind, could you please send us your slot request no later = than Monday July 18 at noon ET? =20 > Julien and I will publish the WG meeting agenda the day after, with = some delays but hopefully an improved > agenda. >=20 > Many Thanks. >=20 > JP and Julien. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-78--598172815 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Sorry = issues with title ... the tile should of course read: "Rules to request = a "slot" during PCE WG Meetings"

On Jul 13, 2011, at = 4:50 PM, JP Vasseur wrote:

Dear = all,

Julien and I have been having a discussion on = how to better manage our WG meeting time.

As a = matter of fact, a number of requested slots are related to IDs that were = already "presented" during previous 
IETF meetings, = refreshed just before the cut-off submission date without discussion on = the mailing list ...

As a gentle reminder, = the aim of WG meetings is to discuss open issues = that could not be resolved by email 
attempting to reach = a consensus, to be confirmed on the mailing = list.

You may want to also refer to a similar = discussion that we had during the Routing Area meeting at the last = IETF.

Few points here:
1) If = your ID falls into the WG charter, it is perfectly fine to get a = "presentation" slot when first posted (rev -00) if
time = permits (priority will be given to slots allocated to resolve technical = issues discussed on the mailing list).
Although people = attending the WG meeting are supposed to have read each document, you = may want to explain
the issue that you are trying to solve, = and how.
2) Before requesting a slot, please make = sure that your intent is to discuss specific technical issues related = to 
the document that could not be resolved on the = mailing list. In other words, please do not request slots for = IDs 
for which no discussion took place on the mailing = list.

With that in mind, could you please send = us your slot request no later than Monday July 18 at noon ET? =  
Julien and I will publish the WG meeting agenda the day = after, with some delays but hopefully an = improved
agenda.

Many = Thanks.

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

= --Apple-Mail-78--598172815-- From jpv@cisco.com Wed Jul 13 08:06:09 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 CB12321F8748 for ; Wed, 13 Jul 2011 08:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 h1euqxzqO5qt for ; Wed, 13 Jul 2011 08:06:09 -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 7E1BB21F872F for ; Wed, 13 Jul 2011 08:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=7841; q=dns/txt; s=iport; t=1310569568; x=1311779168; h=from:subject:date:references:to:message-id:mime-version; bh=gW3B2DzSuyKWqAGb9iIzULj8d4CGZgryHtIGrH19kWE=; b=CnaPGvhgEdGaPB0rglfDeVSDjO34MIufAwKQqQdlZFazCL//OTYGd3t4 llchQTKxy92BLIZKsIxhWsEjOBSx6e/zJUsLKv54Pk8jKvaGZOiBxdR2H o1fMtjavmshTLDbVm6x65/dvT4BcuCwN5qnuBJbZx4ifFEhAWXpPwfJJw c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIqzHU5Io8US/2dsb2JhbABTpzx3iHqlTp4rhjoEkmGEfwmLRg X-IronPort-AV: E=Sophos;i="4.65,525,1304294400"; d="scan'208,217";a="101860985" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 13 Jul 2011 15:06:06 +0000 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6DF65gw013028 for ; Wed, 13 Jul 2011 15:06:06 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); Wed, 13 Jul 2011 23:06:05 +0800 Received: from [10.60.114.232] ([10.60.114.232]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jul 2011 23:06:04 +0800 From: JP Vasseur Content-Type: multipart/alternative; boundary=Apple-Mail-79--597603194 Date: Wed, 13 Jul 2011 17:06:02 +0200 References: <5DA9F283-ED2E-40F4-9C3B-936F0527301E@cisco.com> To: ROLL WG Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 13 Jul 2011 15:06:04.0400 (UTC) FILETIME=[62A39F00:01CC416E] Subject: [Roll] PLEASE IGNORE THIS WAS FOR ANOTHER WORKING GROUP - Thanks. 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, 13 Jul 2011 15:06:09 -0000 --Apple-Mail-79--597603194 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Although, it might be worth a read. Begin forwarded message: > From: JP Vasseur > Date: July 13, 2011 4:56:32 PM GMT+02:00 > To: ROLL WG > Cc: Julien Meuric > Subject: Re: [Roll] Rules to request a "slot" during PCE WG Meetings >=20 > Sorry issues with title ... the tile should of course read: "Rules to = request a "slot" during PCE WG Meetings" >=20 > On Jul 13, 2011, at 4:50 PM, JP Vasseur wrote: >=20 >> Dear all, >>=20 >> Julien and I have been having a discussion on how to better manage = our WG meeting time. >>=20 >> As a matter of fact, a number of requested slots are related to IDs = that were already "presented" during previous=20 >> IETF meetings, refreshed just before the cut-off submission date = without discussion on the mailing list ... >>=20 >> As a gentle reminder, the aim of WG meetings is to discuss open = issues that could not be resolved by email=20 >> attempting to reach a consensus, to be confirmed on the mailing list. >>=20 >> You may want to also refer to a similar discussion that we had during = the Routing Area meeting at the last IETF. >>=20 >> Few points here: >> 1) If your ID falls into the WG charter, it is perfectly fine to get = a "presentation" slot when first posted (rev -00) if >> time permits (priority will be given to slots allocated to resolve = technical issues discussed on the mailing list). >> Although people attending the WG meeting are supposed to have read = each document, you may want to explain >> the issue that you are trying to solve, and how. >> 2) Before requesting a slot, please make sure that your intent is to = discuss specific technical issues related to=20 >> the document that could not be resolved on the mailing list. In other = words, please do not request slots for IDs=20 >> for which no discussion took place on the mailing list. >>=20 >> With that in mind, could you please send us your slot request no = later than Monday July 18 at noon ET? =20 >> Julien and I will publish the WG meeting agenda the day after, with = some delays but hopefully an improved >> agenda. >>=20 >> Many Thanks. >>=20 >> JP and Julien. >> _______________________________________________ >> 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 --Apple-Mail-79--597603194 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: JP Vasseur <jpv@cisco.com>
Date: July 13, 2011 = 4:56:32 PM GMT+02:00
To: ROLL WG <roll@ietf.org>
Subject: Re: [Roll] Rules to request a "slot" during PCE WG = Meetings

Sorry = issues with title ... the tile should of course read: "Rules to request = a "slot" during PCE WG Meetings"

On Jul 13, 2011, at = 4:50 PM, JP Vasseur wrote:

Dear = all,

Julien and I have been having a discussion on = how to better manage our WG meeting time.

As a = matter of fact, a number of requested slots are related to IDs that were = already "presented" during previous 
IETF meetings, = refreshed just before the cut-off submission date without discussion on = the mailing list ...

As a gentle reminder, = the aim of WG meetings is to discuss open issues = that could not be resolved by email 
attempting to reach = a consensus, to be confirmed on the mailing = list.

You may want to also refer to a similar = discussion that we had during the Routing Area meeting at the last = IETF.

Few points here:
1) If = your ID falls into the WG charter, it is perfectly fine to get a = "presentation" slot when first posted (rev -00) if
time = permits (priority will be given to slots allocated to resolve technical = issues discussed on the mailing list).
Although people = attending the WG meeting are supposed to have read each document, you = may want to explain
the issue that you are trying to solve, = and how.
2) Before requesting a slot, please make = sure that your intent is to discuss specific technical issues related = to 
the document that could not be resolved on the = mailing list. In other words, please do not request slots for = IDs 
for which no discussion took place on the mailing = list.

With that in mind, could you please send = us your slot request no later than Monday July 18 at noon ET? =  
Julien and I will publish the WG meeting agenda the day = after, with some delays but hopefully an = improved
agenda.

Many = Thanks.

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

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

= --Apple-Mail-79--597603194-- From jpv@cisco.com Fri Jul 15 01:53: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 560A321F8794 for ; Fri, 15 Jul 2011 01:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.591 X-Spam-Level: X-Spam-Status: No, score=-110.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 RngkgThRrU5w for ; Fri, 15 Jul 2011 01:53:50 -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 7A70421F881C for ; Fri, 15 Jul 2011 01:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=216; q=dns/txt; s=iport; t=1310720030; x=1311929630; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=jtYrO1+FFWprEcrUOW4P2iQb6150IsiJ7SwntcFT60A=; b=cw0Nc7DeZ9/JHl2f6mv9QGH8IEGcNyFc4yauIwE8qpyXP9f182ApqAPz DnPd5HS6JZcd9UUYsjgECJTRbyUgvK6Z58uFgas/PZ/gMqALMwvxHbwRw Wuuf7AJFMrU2CjwgR+DTalI8Bptau1X2Gh/luQNM1zVRc6HJ5l3lEFkE1 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAM//H06Q/khM/2dsb2JhbABUp153rDGBI54mhVtfBJJmhQqLSw X-IronPort-AV: E=Sophos;i="4.65,534,1304294400"; d="scan'208";a="102448351" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 15 Jul 2011 08:53:33 +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 p6F8rXaU024423 for ; Fri, 15 Jul 2011 08:53:33 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Jul 2011 10:53:33 +0200 Received: from ams-jvasseur-8917.cisco.com ([10.61.98.174]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Jul 2011 10:53:33 +0200 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Jul 2011 10:53:32 +0200 Message-Id: <4A7D34EA-84A9-4C1F-AF5D-93401DAF2390@cisco.com> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 15 Jul 2011 08:53:33.0222 (UTC) FILETIME=[AD200460:01CC42CC] Subject: [Roll] Temporary Agenda ROLL IETF-81 Meeting 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, 15 Jul 2011 08:53:51 -0000 Dear all, Please find the temporary agenda for our ROLL IETF-81 meeting: = http://www.ietf.org/proceedings/81/agenda/roll.txt Please let me know by July 18 noon ET if you have any comment. Thanks. JP.= From jari.arkko@piuha.net Fri Jul 15 07:02: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 5375321F8767; Fri, 15 Jul 2011 07:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.395 X-Spam-Level: X-Spam-Status: No, score=-102.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Xv954COrPIaP; Fri, 15 Jul 2011 07:02:34 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id C025121F8766; Fri, 15 Jul 2011 07:02:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 0392A2CEFF; Fri, 15 Jul 2011 17:02:33 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVFpHoBU8rEI; Fri, 15 Jul 2011 17:02:32 +0300 (EEST) Received: from [IPv6:::1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 1C17D2CC4B; Fri, 15 Jul 2011 17:02:32 +0300 (EEST) Message-ID: <4E204877.8040108@piuha.net> Date: Fri, 15 Jul 2011 17:02:31 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: core , lwip@ietf.org, roll@ietf.org, 6lowpan@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] Internet of Things Hacking Meet 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, 15 Jul 2011 14:02:34 -0000 We would like to invite interested implementors for an informal session to interop test, play & demo, further develop your Things and for a general chat with other implementors. This is not a working group session or place to run presentations. If you happen to be around at the time and have some gear to bring or software on your laptop, do join us and maybe something interesting will come out of it. The event is intended for people implementing something around the Internet of Things space. For instance, I am personally interested in home networking and automation and will bring some COAP, IPv6, and 1-wire stuff, but other people are probably interested in other areas and protocols as well. We understand that this is a late announcement, and everyone has lots of other things on their agenda as well. For that purpose Hannes and I have reserved two nights to make it a bit more likely that people can drop by. The times are Saturday, July 23rd, 5PM to 8PM and Sunday, July 24th, 7PM to 9PM. Exact location is to be announced later, but it is in the IETF meeting hotel in Quebec City. Jari Arkko Hannes Tschofenig From adrian@olddog.co.uk Sun Jul 17 04:47: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 0EBF221F86E5 for ; Sun, 17 Jul 2011 04:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, 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 mUgKDXKOnD4P for ; Sun, 17 Jul 2011 04:47:55 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 29D1B21F86A4 for ; Sun, 17 Jul 2011 04:47:46 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p6HBlerT006095; Sun, 17 Jul 2011 12:47:40 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p6HBlcHZ006084 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 17 Jul 2011 12:47:38 +0100 From: "Adrian Farrel" To: "'JP Vasseur'" , "'ROLL WG'" References: <97A1BFC4-BFAB-4B7A-AE34-B99AB60B1AA5@cisco.com> In-Reply-To: <97A1BFC4-BFAB-4B7A-AE34-B99AB60B1AA5@cisco.com> Date: Sun, 17 Jul 2011 12:47:38 +0100 Message-ID: <04fe01cc4477$548dadf0$fda909d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04FF_01CC447F.B65E4AF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFg8TtMSSIteJc4RTcF/YJ5l3kUWZXHC/Ig Content-Language: en-gb Cc: 'Julien Meuric' Subject: Re: [Roll] Proposed Text to ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 11:47:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04FF_01CC447F.B65E4AF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I got nicely confused here! ROLL != PCE :-) Anyway, you sent it. Which is fine. It is your WG for you to manage! A From: JP Vasseur [mailto:jpv@cisco.com] Sent: 13 July 2011 15:50 To: ROLL WG Cc: Julien Meuric; Daniel King; Adrian Farrel Subject: Proposed Text to ROLL Dear all, Julien and I have been having a discussion on how to better manage our WG meeting time. As a matter of fact, a number of requested slots are related to IDs that were already "presented" during previous IETF meetings, refreshed just before the cut-off submission date without discussion on the mailing list ... As a gentle reminder, the aim of WG meetings is to discuss open issues that could not be resolved by email attempting to reach a consensus, to be confirmed on the mailing list. You may want to also refer to a similar discussion that we had during the Routing Area meeting at the last IETF. Few points here: 1) If your ID falls into the WG charter, it is perfectly fine to get a "presentation" slot when first posted (rev -00) if time permits (priority will be given to slots allocated to resolve technical issues discussed on the mailing list). Although people attending the WG meeting are supposed to have read each document, you may want to explain the issue that you are trying to solve, and how. 2) Before requesting a slot, please make sure that your intent is to discuss specific technical issues related to the document that could not be resolved on the mailing list. In other words, please do not request slots for IDs for which no discussion took place on the mailing list. With that in mind, could you please send us your slot request no later than Monday July 18 at noon ET? Julien and I will publish the WG meeting agenda the day after, with some delays but hopefully an improved agenda. Many Thanks. JP and Julien. ------=_NextPart_000_04FF_01CC447F.B65E4AF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I got nicely confused = here!

 

ROLL !=3D PCE = :-)

 

Anyway, you sent it. Which is = fine. It is your WG for you to manage!

 

A

 

From: JP Vasseur = [mailto:jpv@cisco.com]
Sent: 13 July 2011 15:50
To: = ROLL WG
Cc: Julien Meuric; Daniel King; Adrian = Farrel
Subject: Proposed Text to = ROLL

 

Dear = all,

 

Julien and I have been having a discussion on how to better = manage our WG meeting time.

 

As a matter of fact, a number of requested slots are related to = IDs that were already "presented" during = previous 

IETF meetings, refreshed just before the cut-off submission date = without discussion on the mailing list = ...

 

As a gentle reminder, the aim of WG meetings is to = discuss open issues that could not be resolved by = email 

attempting to reach = a consensus, to be confirmed on the mailing = list.

 

You may want to also refer to a similar discussion that we had = during the Routing Area meeting at the last = IETF.

 

Few points here:

1) If your ID falls into the WG charter, it is perfectly fine to = get a "presentation" slot when first posted (rev -00) = if

time permits = (priority will be given to slots allocated to resolve technical issues = discussed on the mailing list).

Although people attending the WG meeting are supposed to have = read each document, you may want to = explain

the issue that you = are trying to solve, and how.

2) Before requesting a slot, please make sure that your = intent is to discuss specific technical issues related = to 

the document that = could not be resolved on the mailing list. In other words, please = do not request slots for IDs 

for which no discussion took place on the mailing = list.

 

With that in mind, could you please send us your slot request no = later than Monday July 18 at noon ET? =  

Julien and I will = publish the WG meeting agenda the day after, with some delays but = hopefully an improved

agenda.

 

Many Thanks.

 

JP and = Julien.

------=_NextPart_000_04FF_01CC447F.B65E4AF0-- From azdvir@gmail.com Tue Jul 19 00:42: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 9912121F85EA for ; Tue, 19 Jul 2011 00:42:38 -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 3SVI+8+WGK92 for ; Tue, 19 Jul 2011 00:42:34 -0700 (PDT) Received: from mail-ey0-f176.google.com (mail-ey0-f176.google.com [209.85.215.176]) by ietfa.amsl.com (Postfix) with ESMTP id 1A50F21F85EC for ; Tue, 19 Jul 2011 00:42:33 -0700 (PDT) Received: by eya28 with SMTP id 28so3152568eya.21 for ; Tue, 19 Jul 2011 00:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=ct/U3zLfqxRdKUxTrQ3Yw1CnGEyfmsHbpHDxAsE7dZA=; b=paNCfaHU1bURKBW1Hml8SBJSxpOZ+2FKI5vpHFpj+dxmfEv+fQEHiHzf34fBwzXeMD P4yfVw47FfRckubcHaQMLK3vw6lDcI2PfGzArC16eR1DStIizPfY0Gj4ld6rkK3XoJHh aMkoHMC+PB0OJCodue/wYoKP/VmEHT5JAlavs= Received: by 10.213.20.214 with SMTP id g22mr182643ebb.111.1311061353123; Tue, 19 Jul 2011 00:42:33 -0700 (PDT) Received: from amitPC (catv-89-132-180-157.catv.broadband.hu [89.132.180.157]) by mx.google.com with ESMTPS id a8sm2543961een.47.2011.07.19.00.42.31 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jul 2011 00:42:32 -0700 (PDT) From: "amit dvir" To: Date: Tue, 19 Jul 2011 09:42:26 +0200 Message-ID: <003301cc45e7$68d7d940$3a878bc0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxC8v2IMoIRxJ3CQ9GRwelxyrdRBgC82V0A Content-Language: he Subject: [Roll] FW: New Version Notification for draft-dvir-roll-security-authentication-00.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, 19 Jul 2011 07:42:38 -0000 Dear WG, Regarding the comments of the WG, our security draft has been split.=20 In this draft, new security service is described that prevents any = misbehaving DODAG node from illegitimately increasing the Version Number = or publish illegitimately decreased Rank values. Your feedback and comments are appreciated. Thanks, Dr. Amit Dvir Post Doc Laboratory of Cryptography and System Security (CrySyS)=20 Budapest University of Technology and Economics (BME) www.amitdvir.com -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Friday, July 15, 2011 3:28 PM To: azdvir@gmail.com Cc: azdvir@gmail.com; buttyan@crysys.hu; laszlo.dora@crysys.hu; = tamas.holczer@crysys.hu Subject: New Version Notification for = draft-dvir-roll-security-authentication-00.txt A new version of I-D, draft-dvir-roll-security-authentication-00.txt has = been successfully submitted by Amit Dvir and posted to the IETF = repository. Filename: draft-dvir-roll-security-authentication Revision: 00 Title: Version Number and Rank Authentication for RPL Creation date: 2011-07-13 WG ID: Individual Submission Number of pages: 23 Abstract: Designing a routing protocol for large low-power and lossy networks (LLNs), consisting of thousands of constrained nodes and unreliable links, presents new challenges. The IPv6 Routing Protocol for Low- power and Lossy Networks (RPL), have been developed by the IETF ROLL Working Group as a preferred routing protocol to provide IPv6 routing functionality in LLNs. Unfortunately, the currently available security services in RPL will not protect against a compromised internal node that can construct and disseminate fake messages. Therefore, in RPL special security care must be taken when the Destination Oriented Directed Acyclic Graph (DODAG) root is updating the Version Number by which reconstruction of the routing topology can be initiated. The same care also must be taken to prevent an internal attacker (compromised DODAG node) to publish decreased Rank value, which causes a large part of the DODAG to connect to the DODAG root via the attacker and give it the ability to eavesdrop or manipulate a large part of the network traffic. In this document, a new security service is described that prevents any misbehaving DODAG node from illegitimately increasing the Version Number or publish illegitimately decreased Rank values. = =20 The IETF Secretariat From jpv@cisco.com Wed Jul 20 01:11: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 1CF3921F8438 for ; Wed, 20 Jul 2011 01:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.073 X-Spam-Level: X-Spam-Status: No, score=-110.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 naDaHfLNQgAR for ; Wed, 20 Jul 2011 01:11:27 -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 0D63321F842E for ; Wed, 20 Jul 2011 01:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=178; q=dns/txt; s=iport; t=1311149487; x=1312359087; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=Hv6c6mSzBtLe01dZRxMVSGVsFgZtHAVE7ZnaMQOCSP8=; b=jBWDy1AmckVjZOG7cvDwOIMOQSps2HCvwvoXGrsACowmkB/Akk2yS+U9 dZSqvO/tp1fee4IX6DuF3DYWQOQMHI3p+YgfKFhb4Exj8FoNj+g5iDYr0 DRoGm9FDaD6hC78SEPSZp5kr7yQnLeKMr9kJzURSGESyFBrLA2IWoY4yQ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPmMJk6Q/khM/2dsb2JhbABUp2J3rCiBI55DhV5fBJJuhRCLTw X-IronPort-AV: E=Sophos;i="4.67,233,1309737600"; d="scan'208";a="103406338" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 20 Jul 2011 08:11:25 +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 p6K8BPOE032363 for ; Wed, 20 Jul 2011 08:11:25 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jul 2011 10:11:25 +0200 Received: from ams-jvasseur-8912.cisco.com ([10.55.82.148]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jul 2011 10:11:25 +0200 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Jul 2011 10:11:24 +0200 Message-Id: <9ED1FBCA-2ADA-4190-9AE4-310A5339BE7C@cisco.com> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 20 Jul 2011 08:11:25.0433 (UTC) FILETIME=[9E82C690:01CC46B4] Subject: [Roll] Slides IETF-81 ROLL WG Meeting 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, 20 Jul 2011 08:11:28 -0000 Dear all, If you have a "presentation" slot for the ROLL WG IETF-81 next week, = please send your slides NO LATER than Monday - July 25 at noon ET. Many Thanks. JP.= From jpv@cisco.com Wed Jul 20 03:55: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 3E3D021F8752 for ; Wed, 20 Jul 2011 03:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.139 X-Spam-Level: X-Spam-Status: No, score=-110.139 tagged_above=-999 required=5 tests=[AWL=0.459, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 uoypsmi5qn3P for ; Wed, 20 Jul 2011 03:55:35 -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 17D2321F86FA for ; Wed, 20 Jul 2011 03:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=3655; q=dns/txt; s=iport; t=1311159335; x=1312368935; h=from:mime-version:subject:date:in-reply-to:to:references: message-id; bh=cOXeHHaTB3rX4zHGqsIStCVELJV76HkzYbenKFT75PQ=; b=d7Lt0UM3S2zvms22vFSEg7OGRWslkfC9igBIiGXgxJBqg4Jxfv3dzvlX ZSTBla5EuNh/5zuhmaWwBRWVUOLl5ZcM5dSBV3rHUVFytsZ75DNrj/mLG akbLT+MdE7zAUDDO/XFy56sNpOSCyg1VPSxRyy9IXNONnK4ppIokoZLeM g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOezJk6Q/khM/2dsb2JhbABGDRCnUneIfKQBnj6DJII6XwSSboUQixY5 Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 20 Jul 2011 10:55:27 +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 p6KAtRlL008886; Wed, 20 Jul 2011 10:55:27 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jul 2011 12:55:27 +0200 Received: from ams-jvasseur-8912.cisco.com ([10.55.82.148]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jul 2011 12:55:26 +0200 From: JP Vasseur Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-63--7839705 Date: Wed, 20 Jul 2011 12:55:25 +0200 In-Reply-To: To: Omprakash Gnawali , ROLL WG , Richard Kelsey , "Pascal Thubert (pthubert)" References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com><6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com><6A2A459175DABE4BB11DE2026AA50A5D044F832E@XMB-AMS-107.cisco.com><6A2A459175DABE4BB11DE2026AA50A5D0459F454@XMB-AMS-107.cisco.com><878vvav5jt.fsf@kelsey-ws.hq.ember.com><0C0EDF1F-114A-4D0C-A680-25A379A8012A@cs.stanford.edu><87writrh3z.fsf@kelsey-ws.hq.ember.com><87oc43q0rt.fsf@kelsey-ws.hq.ember.com><87y6353dxc.fsf@kelsey-ws.hq.ember.com> Message-Id: X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 20 Jul 2011 10:55:26.0831 (UTC) FILETIME=[8870EFF0:01CC46CB] Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 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, 20 Jul 2011 10:55:39 -0000 --Apple-Mail-63--7839705 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I think that all comments have been addressed, and the document is ready = for publication. If any of you think otherwise, please chime in on the mailing list = before July 26th noon ET. Thanks. JP. On Apr 20, 2011, at 4:19 AM, Omprakash Gnawali wrote: > On Tue, Apr 19, 2011 at 6:32 PM, Richard Kelsey > wrote: > >> From: Omprakash Gnawali > >> Date: Tue, 19 Apr 2011 12:33:42 -0700 > >> > >> I am fine with doing routing based on ETX if there are no metric > >> containers. The way it would work is - you compute the Rank based = on > >> ETX, which is an identity function. Then you just advertise that = Rank. > >> The receiving nodes, in the absence of metric container, can = convert > >> the Rank to ETX, which is an identity function, and compute their = path > >> cost, convert that to Rank and advertise that. This mechanism will > >> allow simple and efficient implementation for the most likely use > >> case. > >> > >> Richard - is this what you had in mind? > > > > Yes, that is exactly what I was thinking of. >=20 > Perfect. I will update the draft accordingly. >=20 > - om_p > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 --Apple-Mail-63--7839705 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi,

I think that all comments have been addressed, and the document is ready for publication.

If any of you think otherwise, please chime in on the mailing list before July 26th noon ET.

Thanks.

JP.

On Apr 20, 2011, at 4:19 AM, Omprakash Gnawali wrote:

On Tue, Apr 19, 2011 at 6:32 PM, Richard Kelsey
<richard.kelsey@ember.com> wrote:
>> From: Omprakash Gnawali <gnawali@cs.stanford.edu>
>> Date: Tue, 19 Apr 2011 12:33:42 -0700
>>
>> I am fine with doing routing based on ETX if there are no metric
>> containers. The way it would work is - you compute the Rank based on
>> ETX, which is an identity function. Then you just advertise that Rank.
>> The receiving nodes, in the absence of metric container, can convert
>> the Rank to ETX, which is an identity function, and compute their path
>> cost, convert that to Rank and advertise that. This mechanism will
>> allow simple and efficient implementation for the most likely use
>> case.
>>
>> Richard - is this what you had in mind?
>
> Yes, that is exactly what I was thinking of.

Perfect. I will update the draft accordingly.

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


--Apple-Mail-63--7839705-- From daniel@olddog.co.uk Thu Jul 21 00:08: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 0149321F8B46 for ; Thu, 21 Jul 2011 00:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.299 X-Spam-Level: X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 vTZLT6euX7bI for ; Thu, 21 Jul 2011 00:08:53 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 460D321F8AC3 for ; Thu, 21 Jul 2011 00:08:53 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p6L759K5012002 for ; Thu, 21 Jul 2011 08:05:09 +0100 Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p6L758uS011995 for ; Thu, 21 Jul 2011 08:05:08 +0100 From: "Daniel King" To: Date: Thu, 21 Jul 2011 08:08:42 +0100 Message-ID: <009201cc4775$065b1540$13113fc0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcxHdQSTpzio1HZCSH6H4qMRC4Zlvw== Content-language: en-gb Subject: [Roll] Scribe Volunteer needed for ROLL session @ IETF 81 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, 21 Jul 2011 07:08:54 -0000 Hi All, Alas, I am not able to attend IETF 81 so the working group will need a scribe to take the minutes during our ROLL session. Please let me and the co-chairs know if you would like to volunteer. Your assistance would be very much appreciated! Br, Dan. From jari.arkko@piuha.net Sat Jul 23 03:26: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 6277721F85C0; Sat, 23 Jul 2011 03:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.419 X-Spam-Level: X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 HrVSn5F-vFIB; Sat, 23 Jul 2011 03:26:21 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id B598521F84FE; Sat, 23 Jul 2011 03:26:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id AB5142CEFF; Sat, 23 Jul 2011 13:26:15 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JL0FqmC9ocxr; Sat, 23 Jul 2011 13:26:14 +0300 (EEST) Received: from [IPv6:::1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id A89E62CC4B; Sat, 23 Jul 2011 13:26:13 +0300 (EEST) Message-ID: <4E2AA1C3.80309@piuha.net> Date: Sat, 23 Jul 2011 06:26:11 -0400 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: core , lwip@ietf.org, roll@ietf.org, 6lowpan@ietf.org References: <4E204877.8040108@piuha.net> In-Reply-To: <4E204877.8040108@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hannes Tschofenig Subject: Re: [Roll] Internet of Things Hacking Meet 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, 23 Jul 2011 10:26:22 -0000 Today Saturday we will be at room 301 A from 5PM to 8PM. Note that there will be another meeting finishing at 5PM in the same room. Tomorrow Sunday we will be at 304 B from 7PM to 9PM. This is the IESG meeting room. Jari From jpv@cisco.com Sun Jul 24 05:33: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 A9C3821F8665 for ; Sun, 24 Jul 2011 05:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.989 X-Spam-Level: X-Spam-Status: No, score=-101.989 tagged_above=-999 required=5 tests=[AWL=0.610, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 buaWsDLLUCCb for ; Sun, 24 Jul 2011 05:33:25 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC8A21F87FA for ; Sun, 24 Jul 2011 05:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=98; q=dns/txt; s=iport; t=1311510805; x=1312720405; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=gaC4K2HnZZ7A+yjfwOF3+QDePFyUSZla0eNyxNT8Oc4=; b=Rj8Ah2DPIqwdIDOUj0cEznNw99Rue0UJK31PPcHEyS8vDRzNsB+sQwgs kooqAiMdygO4G9lmzhtWpA6R6PY+l5WTog8bJWnzicygZLvGMTHBIieMl Dfw2eqak+D1fOqHV7mInpt3UzTfMwCuDkxAGM0elNuo7+bjJC0gz5XerP o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEALYQLE6rRDoH/2dsb2JhbAAxHwErgUhYPqcsd4h2nGyBI50rhWBfBJJwhQcJi2w X-IronPort-AV: E=Sophos;i="4.67,256,1309737600"; d="scan'208";a="5890175" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-5.cisco.com with ESMTP; 24 Jul 2011 12:33:24 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6OCXOh2009537 for ; Sun, 24 Jul 2011 12:33:24 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 24 Jul 2011 05:33:24 -0700 Received: from [10.255.254.166] ([10.21.78.166]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 24 Jul 2011 05:33:23 -0700 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Jul 2011 08:33:22 -0400 Message-Id: <35471887-6755-4962-B905-1EA3F01A0010@cisco.com> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 24 Jul 2011 12:33:23.0845 (UTC) FILETIME=[E1111B50:01CC49FD] Subject: [Roll] Agenda Updated 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, 24 Jul 2011 12:33:25 -0000 The slot about "KEMP" has been removed since the presenter cannot attend = the meeting. JP.= From prvs=179b88ba1=mukul@uwm.edu Sun Jul 24 06:39: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 8A07421F8A69 for ; Sun, 24 Jul 2011 06:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 4KpsfmuAKnFz for ; Sun, 24 Jul 2011 06:39:58 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 072E321F8A67 for ; Sun, 24 Jul 2011 06:39:57 -0700 (PDT) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip2mta.uwm.edu with ESMTP; 24 Jul 2011 08:39:58 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 824D92B3F0B for ; Sun, 24 Jul 2011 08:39: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 FT4Omn3LxyeW for ; Sun, 24 Jul 2011 08:39:50 -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 5DD292B3EF0 for ; Sun, 24 Jul 2011 08:39:50 -0500 (CDT) Date: Sun, 24 Jul 2011 08:39:57 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <1847661152.98837.1311514797292.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.91] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - IE8 (Win)/6.0.9_GA_2686) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] Compression format for RPL Control messages 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, 24 Jul 2011 13:39:58 -0000 Hi all I wanted to bring your attention to draft-goyal-roll-rpl-compression-00 that I had submitted a couple of months ago. With IEEE 802.15.4 as the link layer, the maximum link layer payload could be as small as 81 bytes. When one adds a couple of options to a DIO, it approaches that size. The draft has two representative examples of DIO fragmentation. DIO fragmentation is a real issue for P2P-RPL route discovery because a DIO needs to accumulate a route as well. This draft provides a mechanism to compress the DIO base object and some of its options in the desired fashion. The mechanism can be extended to other RPL messages/options as well if desired. Please take a look at this draft and share your views. I will be presenting this draft at the ROLL meeting. Thanks Mukul From jari.arkko@piuha.net Sun Jul 24 13:48: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 54FA921F8562; Sun, 24 Jul 2011 13:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.434 X-Spam-Level: X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 z6tKEhxO1ovx; Sun, 24 Jul 2011 13:48:31 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id B0DEF21F8506; Sun, 24 Jul 2011 13:48:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9A1122CE66; Sun, 24 Jul 2011 23:48:29 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttnf3Y2Ymku9; Sun, 24 Jul 2011 23:48:28 +0300 (EEST) Received: from [IPv6:::1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 9BE4D2CC4B; Sun, 24 Jul 2011 23:48:27 +0300 (EEST) Message-ID: <4E2C851A.9000909@piuha.net> Date: Sun, 24 Jul 2011 16:48:26 -0400 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: core , lwip@ietf.org, roll@ietf.org, 6lowpan@ietf.org References: <4E204877.8040108@piuha.net> <4E2AA1C3.80309@piuha.net> In-Reply-To: <4E2AA1C3.80309@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hannes Tschofenig Subject: Re: [Roll] Internet of Things Hacking Meet 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, 24 Jul 2011 20:48:32 -0000 An update: We are also today at the same room as yesterday: 301A. Welcome! Jari Jari Arkko kirjoitti: > Today Saturday we will be at room 301 A from 5PM to 8PM. Note that > there will be another meeting finishing at 5PM in the same room. > Tomorrow Sunday we will be at 304 B from 7PM to 9PM. This is the IESG > meeting room. > > Jari > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From Daniel.Popa@itron.com Mon Jul 25 09:17: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 94BFF21F8D2A for ; Mon, 25 Jul 2011 09:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] 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 6f1ElvZmFS96 for ; Mon, 25 Jul 2011 09:17:06 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.116]) by ietfa.amsl.com (Postfix) with ESMTP id 2D15C21F8B97 for ; Mon, 25 Jul 2011 08:34:27 -0700 (PDT) Received: from ITR-EXMBXVS-1.itron.com ([192.168.9.112]) by spo-exchcn-2.itron.com ([192.168.9.116]) with mapi; Mon, 25 Jul 2011 08:34:26 -0700 From: "Popa, Daniel" To: "roll@ietf.org" Date: Mon, 25 Jul 2011 08:34:27 -0700 Thread-Topic: [ROLL] RPL applicability statement for AMI networks Thread-Index: AcxK4FacON9d8COuQL2AcNziZv750g== Message-ID: <83027ECE5ECDC04E9BA5350B756A88E1599333F876@ITR-EXMBXVS-1.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 Subject: [Roll] [ROLL] RPL applicability statement for AMI networks 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, 25 Jul 2011 16:17:07 -0000 Hi all, I want to bring to your attention the submission of the draft-popa-roll-app= licability-ami-00 describing the applicability statement for the Routing Pr= otocol for Low Power and Lossy Networks (RPL) in Advanced Metering Infrastr= ucture (AMI) networks.=20 Please look at this draft and share your views. We will be presenting the d= raft at the ROLL f2f meeting. Thanks. Daniel =20 From pal@cs.stanford.edu Mon Jul 25 09:32: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 8C92A21F86AF for ; Mon, 25 Jul 2011 09:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARg6vMzmgrUd for ; Mon, 25 Jul 2011 09:32:04 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8B93121F8658 for ; Mon, 25 Jul 2011 09:32:01 -0700 (PDT) Received: from dn0a2100ef.sunet ([10.33.0.239]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1QlO4W-00030o-IG; Mon, 25 Jul 2011 09:32:00 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <83027ECE5ECDC04E9BA5350B756A88E1599333F876@ITR-EXMBXVS-1.itron.com> Date: Mon, 25 Jul 2011 09:32:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <823F1D1D-3FF9-4907-B58C-5487644A6588@cs.stanford.edu> References: <83027ECE5ECDC04E9BA5350B756A88E1599333F876@ITR-EXMBXVS-1.itron.com> To: "Popa, Daniel" X-Mailer: Apple Mail (2.1084) X-Scan-Signature: 6bee508a35d8245455fa42c2dd36c733 Cc: "roll@ietf.org" Subject: Re: [Roll] [ROLL] RPL applicability statement for AMI networks 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, 25 Jul 2011 16:32:05 -0000 On Jul 25, 2011, at 8:34 AM, Popa, Daniel wrote: > draft-popa-roll-applicability-ami-00 Daniel, Can you explain the reasoning for this statement: o AMI deployments SHOULD set DIORedundancyConstant to a value of 10 or more. This basically gives up one of the very valuable properties of Trickle, = its ability to scale well to high densities while maintaining a low = communication/energy cost. Thanks! Phil= From internet-drafts@ietf.org Mon Jul 25 09:41: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 650D221F8B6C; Mon, 25 Jul 2011 09:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Uat2JH6YIcqE; Mon, 25 Jul 2011 09:41:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0742A21F8B66; Mon, 25 Jul 2011 09:41:30 -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.56 Message-ID: <20110725164130.11058.51738.idtracker@ietfa.amsl.com> Date: Mon, 25 Jul 2011 09:41:30 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-applicability-ami-00.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, 25 Jul 2011 16:41:30 -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 : Applicability Statement for the Routing Protocol for Low= Power and Lossy Networks (RPL) in AMI Networks Author(s) : Daniel Popa Jorjeta Jetcheva Nicolas Dejean Ruben Salazar Jonathan W. Hui Filename : draft-ietf-roll-applicability-ami-00.txt Pages : 13 Date : 2011-07-25 This document discusses the applicability of RPL in Advanced Metering Infrastructure (AMI) networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-applicability-ami-00.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-applicability-ami-00.txt From emmanuel.baccelli@gmail.com Mon Jul 25 09:45: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 EDD6721F89A1 for ; Mon, 25 Jul 2011 09:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 OAoCtEBNkXDb for ; Mon, 25 Jul 2011 09:45:19 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C5C3121F88A0 for ; Mon, 25 Jul 2011 09:45:10 -0700 (PDT) Received: by ywp31 with SMTP id 31so2728129ywp.31 for ; Mon, 25 Jul 2011 09:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=pI74ahgh+KfbHK/GHmsUZ//psrTmi1SkIuQEnmb53oc=; b=fQr914uEQCkWIX9wkqz7h1zjD/Vptxr588UJ9dpEx//DhtCRP96MHqYEGyufmHEtWZ 2Tkv66peFB5GaXlR7wEluakIP2TeXnsSi5DoLOI5NXuYnZdupORk9JHbWM5Bd8YrXcUH k9YW9ridvuMqbXEFD7imzrfdVEjwUgs/e/f3k= Received: by 10.231.113.150 with SMTP id a22mr4883691ibq.96.1311612310133; Mon, 25 Jul 2011 09:45:10 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.231.3.65 with HTTP; Mon, 25 Jul 2011 09:44:50 -0700 (PDT) From: Emmanuel Baccelli Date: Mon, 25 Jul 2011 18:44:50 +0200 X-Google-Sender-Auth: 1hi3OzVnF8HZ5hboEtv8MDAZGe8 Message-ID: To: ROLL WG Content-Type: multipart/alternative; boundary=00163630f5d9d41b0b04a8e78957 Subject: [Roll] P2P implementation (draft-ietf-roll-p2p-rpl) 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, 25 Jul 2011 16:45:21 -0000 --00163630f5d9d41b0b04a8e78957 Content-Type: text/plain; charset=ISO-8859-1 Hi Rollers, here is a link to our open source implementation of the P2P extension ( http://tools.ietf.org/html/draft-ietf-roll-p2p-rpl-04). The implementation builds upon the Contiki OS code base, and is available at the below url: http://www.lix.polytechnique.fr/~mphi/p2p/ We are looking forward to feedback from you testers out there! cheers, Emmanuel --00163630f5d9d41b0b04a8e78957 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Rollers,

here is a link to our open source implementa= tion of the P2P extension (http://tools.ietf.org/html/draft-ietf-r= oll-p2p-rpl-04).

The implementation builds upon the Contiki OS code base= , and is available at the below url:

We are looking forward to feedback from you testers out= there!

cheers,

Emmanuel<= /div>


--00163630f5d9d41b0b04a8e78957-- From c.chauvenet@watteco.com Mon Jul 25 09:56:09 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 C741E21F887C for ; Mon, 25 Jul 2011 09:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 Ic5u9nMl1J5N for ; Mon, 25 Jul 2011 09:56:09 -0700 (PDT) Received: from TX2EHSOBE007.bigfish.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB7321F87AF for ; Mon, 25 Jul 2011 09:56:05 -0700 (PDT) Received: from mail148-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.22; Mon, 25 Jul 2011 16:56:05 +0000 Received: from mail148-tx2 (localhost.localdomain [127.0.0.1]) by mail148-tx2-R.bigfish.com (Postfix) with ESMTP id 235683A03FF; Mon, 25 Jul 2011 16:56:05 +0000 (UTC) X-SpamScore: -20 X-BigFish: VPS-20(zzc89bhc85dhzz1202hzz1033IL8275dhz2dh2a8h668h839h8aah61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:213.199.187.153; KIP:(null); UIP:(null); IPVD:NLI; SRV:BULK; H:IE2RD2HUB007.red002.local; RD:none; EFVD:NLI Received: from mail148-tx2 (localhost.localdomain [127.0.0.1]) by mail148-tx2 (MessageSwitch) id 1311612964699730_21002; Mon, 25 Jul 2011 16:56:04 +0000 (UTC) Received: from TX2EHSMHS043.bigfish.com (unknown [10.9.14.254]) by mail148-tx2.bigfish.com (Postfix) with ESMTP id 99DA2A48050; Mon, 25 Jul 2011 16:56:04 +0000 (UTC) Received: from IE2RD2HUB007.red002.local (213.199.187.153) by TX2EHSMHS043.bigfish.com (10.9.99.143) with Microsoft SMTP Server (TLS) id 14.1.225.22; Mon, 25 Jul 2011 16:56:04 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.55]) by IE2RD2HUB007.red002.local ([10.33.16.155]) with mapi; Mon, 25 Jul 2011 09:55:28 -0700 From: C Chauvenet To: Emmanuel Baccelli , "Matthias.Philipp@inria.fr" Date: Mon, 25 Jul 2011 09:55:25 -0700 Thread-Topic: [Roll] P2P implementation (draft-ietf-roll-p2p-rpl) Thread-Index: AcxK66cSnuHuXG4fTVq/tBj9zN8dCw== Message-ID: <42B54ABB-9B22-485F-BB11-887CBA815105@watteco.com> References: In-Reply-To: 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_42B54ABB9B22485FBB11887CBA815105wattecocom_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: ROLL WG Subject: Re: [Roll] P2P implementation (draft-ietf-roll-p2p-rpl) 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, 25 Jul 2011 16:56:09 -0000 --_000_42B54ABB9B22485FBB11887CBA815105wattecocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Emmanuel, This looks gorgeous. >From what Contiki version did you start the implementation ? I've CCed the implementer. C=E9dric. Le 25 juil. 2011 =E0 18:44, Emmanuel Baccelli a =E9crit : Hi Rollers, here is a link to our open source implementation of the P2P extension (http= ://tools.ietf.org/html/draft-ietf-roll-p2p-rpl-04). The implementation builds upon the Contiki OS code base, and is available a= t the below url: http://www.lix.polytechnique.fr/~mphi/p2p/ We are looking forward to feedback from you testers out there! cheers, Emmanuel --_000_42B54ABB9B22485FBB11887CBA815105wattecocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Emmanuel, 
This looks gorgeous.

From what Contiki= version did you start the implementation ?
I've CCed the impleme= nter.

C=E9dric.

Le 25 juil= . 2011 =E0 18:44, Emmanuel Baccelli a =E9crit :

Hi Rollers,

here is a link to our open source implementation of the P2P extension = (http://tools.ietf.org/html/draft-ietf-roll-p2p-rpl-04).

The implementation builds upon the Contiki OS code base, and is availa= ble at the below url:

We are looking forward to feedback from you testers out there!

cheers,

Emmanuel



= --_000_42B54ABB9B22485FBB11887CBA815105wattecocom_-- From jpv@cisco.com Mon Jul 25 10:10: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 D7F4E21F8640 for ; Mon, 25 Jul 2011 10:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.19 X-Spam-Level: X-Spam-Status: No, score=-110.19 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 n2GOuk1JJcBE for ; Mon, 25 Jul 2011 10:10:38 -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 57E4B21F861A for ; Mon, 25 Jul 2011 10:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=8570; q=dns/txt; s=iport; t=1311613755; x=1312823355; h=from:subject:date:references:to:message-id:mime-version; bh=/qq2xWgmM9WBII2N2YOMt2jLvC7nJZhSKUaYeRd0pKo=; b=KtcgOfeL/2lg2PIz2vO3qJk1yCu5Cy4bJiaeMmeos3p2r2vJdZCaFUQH j3e80d5BXdYh+nyRXKcL5KC5uUv+U+ee1Qbc0YXeoCSWBsdDahHRPn7N+ D4sNJ0e4WthDjBT7WIKMOFbP3CFbergoG5wQ9ZZ01z1QZ1J57eet705IP I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGaiLU6Q/khL/2dsb2JhbAA0AQEBAQIBAQEBEQEeRxAMHQMBAjsUGC8CCAcXDRqnMneIfASiAZ4UhWBfBJJwhQcJi2w X-IronPort-AV: E=Sophos;i="4.67,263,1309737600"; d="scan'208,217";a="44222302" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 25 Jul 2011 17:09:14 +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 p6PH9EuP019954 for ; Mon, 25 Jul 2011 17:09:14 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jul 2011 19:09:14 +0200 Received: from [10.255.254.166] ([10.61.66.233]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jul 2011 19:09:13 +0200 From: JP Vasseur Content-Type: multipart/alternative; boundary="Apple-Mail=_0EAF55A8-70CC-4E23-8D39-9F027D694742" Date: Mon, 25 Jul 2011 13:09:12 -0400 References: <20110725164130.11058.51738.idtracker@ietfa.amsl.com> To: ROLL WG Message-Id: Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 25 Jul 2011 17:09:13.0586 (UTC) FILETIME=[93E4ED20:01CC4AED] Subject: [Roll] Fwd: I-D Action: draft-ietf-roll-applicability-ami-00.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, 25 Jul 2011 17:10:40 -0000 --Apple-Mail=_0EAF55A8-70CC-4E23-8D39-9F027D694742 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Dear all, As discussed during the last IETF meeting, we have several important WG = items in our charter, and in particular the "applicability statement". = draft-ietf-roll-applicability-ami-00.txt is the first one, please comment on the mailing list. Needless to say that the document is = now under the control=20 of the WG and additions/changes can be made through dicussion on the = mailing list. Thanks. JP. Begin forwarded message: > From: > Subject: [Roll] I-D Action: draft-ietf-roll-applicability-ami-00.txt > Date: July 25, 2011 12:41:30 PM EDT > To: > Cc: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Routing Over Low power and = Lossy networks Working Group of the IETF. >=20 > Title : Applicability Statement for the Routing = Protocol for Low Power and Lossy Networks (RPL) in AMI Networks > Author(s) : Daniel Popa > Jorjeta Jetcheva > Nicolas Dejean > Ruben Salazar > Jonathan W. Hui > Filename : draft-ietf-roll-applicability-ami-00.txt > Pages : 13 > Date : 2011-07-25 >=20 > This document discusses the applicability of RPL in Advanced = Metering > Infrastructure (AMI) networks. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-roll-applicability-ami-00.t= xt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-applicability-ami-00.tx= t > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 --Apple-Mail=_0EAF55A8-70CC-4E23-8D39-9F027D694742 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Dear = all,

As discussed during the last IETF meeting, we = have several important WG items in our charter,
and in = particular the "applicability = statement". draft-ietf-roll-applicability-ami-00.txt is the first = one,
please comment on the mailing list. Needless to say that = the document is now under the = control 
of the WG and = additions/changes can be made through dicussion on the mailing = list.

Thanks.
Subject: [Roll] I-D Action: = draft-ietf-roll-applicability-ami-00.txt
Date: July 25, 2011 = 12:41:30 PM EDT

[Roll] I-D Action: = draft-ietf-roll-applicability-ami-00.txt

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

        = Title           : = Applicability Statement for the Routing Protocol for Low Power and Lossy = Networks (RPL) in AMI Networks
        = Author(s)       : Daniel Popa
=             &n= bsp;           &nbs= p; Jorjeta Jetcheva
=             &n= bsp;           &nbs= p; Nicolas Dejean
=             &n= bsp;           &nbs= p; Ruben Salazar
=             &n= bsp;           &nbs= p; Jonathan W. Hui
        = Filename        : = draft-ietf-roll-applicability-ami-00.txt
        = Pages           : = 13
        = Date            : = 2011-07-25

   This document discusses the applicability of RPL in = Advanced Metering
   Infrastructure (AMI) networks.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-applicabil= ity-ami-00.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-applicabilit= y-ami-00.txt
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll


= --Apple-Mail=_0EAF55A8-70CC-4E23-8D39-9F027D694742-- From internet-drafts@ietf.org Mon Jul 25 11:28: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 2008C21F8B2F; Mon, 25 Jul 2011 11:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 ZmmYRX4dcty8; Mon, 25 Jul 2011 11:28:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95BB321F8B18; Mon, 25 Jul 2011 11:28:37 -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.56 Message-ID: <20110725182837.19651.12235.idtracker@ietfa.amsl.com> Date: Mon, 25 Jul 2011 11:28:37 -0700 Cc: roll@ietf.org Subject: [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: Mon, 25 Jul 2011 18:28:38 -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 : Applicability Statement for the Routing Protocol for Low= Power and Lossy Networks (RPL) in AMI Networks Author(s) : Daniel Popa Jorjeta Jetcheva Nicolas Dejean Ruben Salazar Jonathan W. Hui Filename : draft-ietf-roll-applicability-ami-01.txt Pages : 14 Date : 2011-07-25 This document discusses the applicability of RPL in Advanced Metering Infrastructure (AMI) networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-applicability-ami-01.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-applicability-ami-01.txt From ulrich@herberg.name Mon Jul 25 11:45: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 8A16421F8B74 for ; Mon, 25 Jul 2011 11:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 wKQqC+gevRnz for ; Mon, 25 Jul 2011 11:45:48 -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 DDE3221F8C23 for ; Mon, 25 Jul 2011 11:45:35 -0700 (PDT) Received: by vxi40 with SMTP id 40so3977189vxi.31 for ; Mon, 25 Jul 2011 11:45:35 -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=qL4GGsv2ljcL3f2UEquBlFKjsE3L17hsr1dqNyzg00k=; b=ti0ZAWXlnc1QGahFERylZ152xEkOyqeRXO8CAks9uExIVhVn8IXH2fwumGQUQcBm33 +3WeQR/uDhkL3xPWFGRt3iJnYud2vEvbtKtwQM9vNKq1aKkgWdJ25hQ2YTaH9WH1rqnK 8Qc4eEekWPsOcTU01XqVZMfj4Sk6zRmKHzhZw= MIME-Version: 1.0 Received: by 10.52.97.33 with SMTP id dx1mr4872960vdb.34.1311619535329; Mon, 25 Jul 2011 11:45:35 -0700 (PDT) Received: by 10.220.2.15 with HTTP; Mon, 25 Jul 2011 11:45:34 -0700 (PDT) In-Reply-To: References: <20110725164130.11058.51738.idtracker@ietfa.amsl.com> Date: Mon, 25 Jul 2011 14:45:34 -0400 Message-ID: From: Ulrich Herberg To: JP Vasseur Content-Type: multipart/alternative; boundary=20cf307f30ee7bd81104a8e938ff Cc: ROLL WG Subject: Re: [Roll] Fwd: I-D Action: draft-ietf-roll-applicability-ami-00.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, 25 Jul 2011 18:45:49 -0000 --20cf307f30ee7bd81104a8e938ff Content-Type: text/plain; charset=ISO-8859-1 Hi, I must have missed the decision of the WG to adopt draft-popa-roll-applicability-ami-00 as a WG document, at least I did not see any discussion about it on the mailing list. Could you please point me to that discussion in the archives? Thanks Ulrich On Mon, Jul 25, 2011 at 1:09 PM, JP Vasseur wrote: > Dear all, > > As discussed during the last IETF meeting, we have several important WG > items in our charter, > and in particular the "applicability > statement". draft-ietf-roll-applicability-ami-00.txt is the first one, > please comment on the mailing list. Needless to say that the document is now > under the control > of the WG and additions/changes can be made through dicussion on the > mailing list. > > Thanks. > > JP. > > Begin forwarded message: > > *From: * > *Subject: **[Roll] I-D Action: draft-ietf-roll-applicability-ami-00.txt* > *Date: *July 25, 2011 12:41:30 PM EDT > *To: * > *Cc: * > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Routing Over Low power and > Lossy networks Working Group of the IETF. > > Title : Applicability Statement for the Routing Protocol > for Low Power and Lossy Networks (RPL) in AMI Networks > Author(s) : Daniel Popa > Jorjeta Jetcheva > Nicolas Dejean > Ruben Salazar > Jonathan W. Hui > Filename : draft-ietf-roll-applicability-ami-00.txt > Pages : 13 > Date : 2011-07-25 > > This document discusses the applicability of RPL in Advanced Metering > Infrastructure (AMI) networks. > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-roll-applicability-ami-00.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-applicability-ami-00.txt > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --20cf307f30ee7bd81104a8e938ff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I must have missed the decision of the WG to adopt draft-popa-ro= ll-applicability-ami-00 as a WG document, at least I did not see any discus= sion about it on the mailing list. Could you please point me to that discus= sion in the archives?

Thanks
Ulrich

On Mon, Jul 25, 2011= at 1:09 PM, JP Vasseur <jpv@cisco.com> wrote:
Dear all,

As discuss= ed during the last IETF meeting, we have several important WG items in our = charter,
and in particular the "applicability statement"= ;.=A0draft-ietf-roll-applicability-ami-00.txt is the first one,
please comment on the mailing list. Needless to say that the document = is=A0now under the c= ontrol=A0
of the WG and additions/changes can be made through dicussion on the= mailing list.

Thanks.

JP.

Begin forwarded message:

From: <= /b>= <internet-= drafts@ietf.org>
Subject: [Roll] I-D Action: draft-ietf-roll-applicability-a= mi-00.txt
Date: July 25, 2011 12:41:30 PM EDT

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

=A0=A0=A0=A0=A0=A0=A0 Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : Applicability S= tatement for the Routing Protocol for Low Power and Lossy Networks (RPL) in= AMI Networks
=A0=A0=A0=A0=A0=A0=A0 Author(s)=A0=A0=A0=A0=A0=A0 : Daniel Popa
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= Jorjeta Jetcheva
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= Nicolas Dejean
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= Ruben Salazar
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= Jonathan W. Hui
=A0=A0=A0=A0=A0=A0=A0 Filename=A0=A0=A0=A0=A0=A0=A0 : draft-ietf-roll-appli= cability-ami-00.txt
=A0=A0=A0=A0=A0=A0=A0 Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 13
=A0=A0=A0=A0=A0=A0=A0 Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 2011-07-25
=A0=A0 This document discusses the applicability of RPL in Advanced Meterin= g
=A0=A0 Infrastructure (AMI) networks.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-i= etf-roll-applicability-ami-00.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-iet= f-roll-applicability-ami-00.txt
_______________________________________________
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


--20cf307f30ee7bd81104a8e938ff-- From alexandru.petrescu@gmail.com Mon Jul 25 11:52: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 A251A21F8BB3 for ; Mon, 25 Jul 2011 11:52:44 -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 wRFwwpsjZWG4 for ; Mon, 25 Jul 2011 11:52:43 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B90E021F8BAC for ; Mon, 25 Jul 2011 11:52:43 -0700 (PDT) Received: by yxp4 with SMTP id 4so3005984yxp.31 for ; Mon, 25 Jul 2011 11:52:43 -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=YSLO+jPZU0tAmnYvmwdTl52LpAw/TAB90bVboyWqQXY=; b=gVbSf4+OBgxncSGgOsOwBXFllW4GIbJygc9a4dl/qFZfI8aFNgten3PAbxsPnoWPtY 8VHFwZ66vssoNtt/0xZC57D5D6DVUke8gZrwP0fct+g4/IplubMEdlFgKL/rrPfwQexi N6dAyvzwmjiLDeSm7QDxtXlRW+4BbRnSo6Bho= Received: by 10.142.49.10 with SMTP id w10mr3019675wfw.85.1311619962726; Mon, 25 Jul 2011 11:52:42 -0700 (PDT) Received: from [127.0.0.1] (dhcp-150a.meeting.ietf.org [130.129.21.10]) by mx.google.com with ESMTPS id s6sm191672wff.15.2011.07.25.11.52.41 (version=SSLv3 cipher=OTHER); Mon, 25 Jul 2011 11:52:42 -0700 (PDT) Message-ID: <4E2DBB77.3060304@gmail.com> Date: Mon, 25 Jul 2011 20:52:39 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: roll@ietf.org References: <20110725164130.11058.51738.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] Fwd: I-D Action: draft-ietf-roll-applicability-ami-00.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, 25 Jul 2011 18:52:44 -0000 I have precisely the same concern. It seems the Chairs are confident this WG accepts that item without asking. Alex Le 25/07/2011 20:45, Ulrich Herberg a écrit : > Hi, > > I must have missed the decision of the WG to adopt > draft-popa-roll-applicability-ami-00 as a WG document, at least I did > not see any discussion about it on the mailing list. Could you please > point me to that discussion in the archives? > > Thanks > Ulrich > > On Mon, Jul 25, 2011 at 1:09 PM, JP Vasseur > wrote: > > Dear all, > > As discussed during the last IETF meeting, we have several important > WG items in our charter, > and in particular the "applicability > statement". draft-ietf-roll-applicability-ami-00.txt is the first one, > please comment on the mailing list. Needless to say that the > document is now under the control > of the WG and additions/changes can be made through dicussion on the > mailing list. > > Thanks. > > JP. > > Begin forwarded message: > >> *From: *> >> *Subject: **[Roll] I-D Action: >> draft-ietf-roll-applicability-ami-00.txt* >> *Date: *July 25, 2011 12:41:30 PM EDT >> *To: *> >> *Cc: *> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Routing Over Low >> power and Lossy networks Working Group of the IETF. >> >> Title : Applicability Statement for the Routing >> Protocol for Low Power and Lossy Networks (RPL) in AMI Networks >> Author(s) : Daniel Popa >> Jorjeta Jetcheva >> Nicolas Dejean >> Ruben Salazar >> Jonathan W. Hui >> Filename : draft-ietf-roll-applicability-ami-00.txt >> Pages : 13 >> Date : 2011-07-25 >> >> This document discusses the applicability of RPL in Advanced >> Metering >> Infrastructure (AMI) networks. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-roll-applicability-ami-00.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-applicability-ami-00.txt >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From emmanuel.baccelli@gmail.com Mon Jul 25 11:53: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 2207111E8091 for ; Mon, 25 Jul 2011 11:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 cJ8D2U2vH4nJ for ; Mon, 25 Jul 2011 11:53:50 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 279C411E8092 for ; Mon, 25 Jul 2011 11:53:50 -0700 (PDT) Received: by gwb20 with SMTP id 20so3215194gwb.31 for ; Mon, 25 Jul 2011 11:53:49 -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=PX8TcxzaMPQLReWkI9sVf1WKh9zg+OcnGLVC2VG9+Us=; b=uddZh77HgtGzkYuvdf3X9NRQYMCSCn0fBzL0qYRZp5evKBVOPj4A7jebtyjND6S0Ne aFyQgjVcixJWdLz6Jzi1lTMyXsvQyRIb7ghX+ZVejmG8tSTDol6tqudTAbk1QYRHyAVX kbWCwE77H+xD9vKmeLF95VDVTGawA1JxfS5aU= Received: by 10.231.113.150 with SMTP id a22mr4984009ibq.96.1311620029133; Mon, 25 Jul 2011 11:53:49 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.231.3.65 with HTTP; Mon, 25 Jul 2011 11:53:29 -0700 (PDT) In-Reply-To: <42B54ABB-9B22-485F-BB11-887CBA815105@watteco.com> References: <42B54ABB-9B22-485F-BB11-887CBA815105@watteco.com> From: Emmanuel Baccelli Date: Mon, 25 Jul 2011 20:53:29 +0200 X-Google-Sender-Auth: fHF7tW9IqMUQh1u6XlMF4NsD2Bk Message-ID: To: ROLL WG Content-Type: multipart/alternative; boundary=00163630f5d9eab30d04a8e955f3 Subject: Re: [Roll] P2P implementation (draft-ietf-roll-p2p-rpl) 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, 25 Jul 2011 18:53:51 -0000 --00163630f5d9eab30d04a8e955f3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Cedric, the code is based on Contiki 2.5-rc1 Cheers Emmanuel On Mon, Jul 25, 2011 at 6:55 PM, C Chauvenet wrote= : > Hi Emmanuel, > > This looks gorgeous. > > From what Contiki version did you start the implementation ? > I've CCed the implementer. > > C=E9dric. > > Le 25 juil. 2011 =E0 18:44, Emmanuel Baccelli a =E9crit : > > Hi Rollers, > > here is a link to our open source implementation of the P2P extension ( > http://tools.ietf.org/html/draft-ietf-roll-p2p-rpl-04). > > The implementation builds upon the Contiki OS code base, and is availabl= e > at the below url: > http://www.lix.polytechnique.fr/~mphi/p2p/ > > We are looking forward to feedback from you testers out there! > > cheers, > > Emmanuel > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --00163630f5d9eab30d04a8e955f3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Cedric,
the code is based on Contiki=A02.5-rc1
Cheers
Emmanuel

On Mon, Jul 25, 2011 at 6:= 55 PM, C Chauvenet <c.chauvenet@watteco.com> wrote:
Hi Emmanuel,=A0

This looks gorgeous.

From what Contiki version did you start the implementation ?
I've CCed the implementer.

C=E9dric.

Le 25 juil. 2011 =E0 18:44, E= mmanuel Baccelli a =E9crit :

Hi Rollers,

here is a link to our open source implementation of the P2P extension = (http://tools.ietf.org/html/draft-ietf-roll-p2p-rpl-04).

The implementation builds upon the Contiki OS code base, and is availa= ble at the below url:

We are looking forward to feedback from you testers out there!

cheers,

Emmanuel




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


--00163630f5d9eab30d04a8e955f3-- From jpv@cisco.com Mon Jul 25 12:10:11 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 7DED821F8BE0 for ; Mon, 25 Jul 2011 12:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.806 X-Spam-Level: X-Spam-Status: No, score=-108.806 tagged_above=-999 required=5 tests=[AWL=1.792, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 69DccZl2jjJ4 for ; Mon, 25 Jul 2011 12:10:10 -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 3DEA721F8BC6 for ; Mon, 25 Jul 2011 12:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=10938; q=dns/txt; s=iport; t=1311621008; x=1312830608; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=//ju4obzTDmR7J3zvzo83i197hszw8/QHqqapdwHk2I=; b=TNTqEHp4tpzYneeOMmO4jmoinPegPvo/ib4J84Y5EaFyrdGI8uytApzq tz3BBlxyNj0JsUyD1fjGMKV+zRKgrW5JSSDyz7xu+gVgXtthJCZWL0jA6 hmDsyZ9eOyldjh8N6R9qVUq2Ten3WhzKD/7w6EBUjcsAtaYjj7/pDGJE7 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADW/LU5Io8UT/2dsb2JhbAA0AQEBAQIBAQEBEQFlCwUMDBEDAQIBGx8UGDEIBxcNGqczd4h8BKFsnieDLoIyXwSScIUHCYts X-IronPort-AV: E=Sophos;i="4.67,264,1309737600"; d="scan'208,217";a="104226303" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-1.cisco.com with ESMTP; 25 Jul 2011 19:10:03 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6PJA2UE030663; Mon, 25 Jul 2011 19:10:02 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); Tue, 26 Jul 2011 00:40:03 +0530 Received: from [10.255.254.166] ([10.66.255.77]) by xfe-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 00:39:56 +0530 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_4E9E8030-018B-41AE-A509-3DF251C86433" From: JP Vasseur In-Reply-To: Date: Mon, 25 Jul 2011 15:09:49 -0400 Message-Id: <4B6BCE24-0855-43EA-8FF3-AB4BE9E2D88B@cisco.com> References: <20110725164130.11058.51738.idtracker@ietfa.amsl.com> To: Ulrich Herberg X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 25 Jul 2011 19:09:57.0295 (UTC) FILETIME=[717B33F0:01CC4AFE] Cc: ROLL WG Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-00.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, 25 Jul 2011 19:10:12 -0000 --Apple-Mail=_4E9E8030-018B-41AE-A509-3DF251C86433 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, As you may know, there is nothing unusual in making an ID a WG document. = Please see a good=20 presentation from Adrian Farrel Routing AD IETF-78 on the WG adoption = process. In this case,=20 this fits one of our WG item. OF COURSE, this is the document of the WG = and your comments are very much welcome; more work is of course needed. You may want to = refer to RFC4677 and other presentations on the process. I'm happy to provide you more = information if needed. Thanks. JP. On Jul 25, 2011, at 2:45 PM, Ulrich Herberg wrote: > Hi, >=20 > I must have missed the decision of the WG to adopt = draft-popa-roll-applicability-ami-00 as a WG document, at least I did = not see any discussion about it on the mailing list. Could you please = point me to that discussion in the archives? >=20 > Thanks > Ulrich >=20 > On Mon, Jul 25, 2011 at 1:09 PM, JP Vasseur wrote: > Dear all, >=20 > As discussed during the last IETF meeting, we have several important = WG items in our charter, > and in particular the "applicability statement". = draft-ietf-roll-applicability-ami-00.txt is the first one, > please comment on the mailing list. Needless to say that the document = is now under the control=20 > of the WG and additions/changes can be made through dicussion on the = mailing list. >=20 > Thanks. >=20 > JP. >=20 > Begin forwarded message: >=20 >> From: >> Subject: [Roll] I-D Action: draft-ietf-roll-applicability-ami-00.txt >> Date: July 25, 2011 12:41:30 PM EDT >> To: >> Cc: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Routing Over Low power and = Lossy networks Working Group of the IETF. >>=20 >> Title : Applicability Statement for the Routing = Protocol for Low Power and Lossy Networks (RPL) in AMI Networks >> Author(s) : Daniel Popa >> Jorjeta Jetcheva >> Nicolas Dejean >> Ruben Salazar >> Jonathan W. Hui >> Filename : draft-ietf-roll-applicability-ami-00.txt >> Pages : 13 >> Date : 2011-07-25 >>=20 >> This document discusses the applicability of RPL in Advanced = Metering >> Infrastructure (AMI) networks. >>=20 >>=20 >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-ietf-roll-applicability-ami-00.t= xt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-applicability-ami-00.tx= t >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >>=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 >=20 --Apple-Mail=_4E9E8030-018B-41AE-A509-3DF251C86433 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Hi,

I must have missed the decision of the WG to = adopt draft-popa-roll-applicability-ami-00 as a WG document, at least I = did not see any discussion about it on the mailing list. Could you = please point me to that discussion in the archives?

Thanks
Ulrich

On Mon, Jul 25, = 2011 at 1:09 PM, JP Vasseur <jpv@cisco.com> = wrote:
Dear all,

As = discussed during the last IETF meeting, we have several important WG = items in our charter,
and in particular the "applicability = statement". draft-ietf-roll-applicability-ami-00.txt is the first = one,
please comment on the mailing list. Needless to say that the = document is now under the control 
of the WG and = additions/changes can be made through dicussion on the mailing = list.

Thanks.

JP.

Begin forwarded = message:

From: = <internet-drafts@ietf.org>
Subject: = [Roll] I-D Action: = draft-ietf-roll-applicability-ami-00.txt
Date: = July = 25, 2011 12:41:30 PM EDT
To: = <i-d-announce@ietf.org>
Cc: = <roll@ietf.org>
=

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

        = Title           : = Applicability Statement for the Routing Protocol for Low Power and Lossy = Networks (RPL) in AMI Networks
        = Author(s)       : Daniel Popa
=             &n= bsp;           &nbs= p; Jorjeta Jetcheva
=             &n= bsp;           &nbs= p; Nicolas Dejean
=             &n= bsp;           &nbs= p; Ruben Salazar
=             &n= bsp;           &nbs= p; Jonathan W. Hui
        = Filename        : = draft-ietf-roll-applicability-ami-00.txt
        = Pages           : = 13
        = Date            : = 2011-07-25

   This document discusses the applicability of RPL in = Advanced Metering
   Infrastructure (AMI) networks.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-appl= icability-ami-00.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-appli= cability-ami-00.txt
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

=


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



= --Apple-Mail=_4E9E8030-018B-41AE-A509-3DF251C86433-- From alexandru.petrescu@gmail.com Mon Jul 25 15:25: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 78CAA21F8561 for ; Mon, 25 Jul 2011 15:25:12 -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 EufbP42RY5yd for ; Mon, 25 Jul 2011 15:25:11 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1D22221F859C for ; Mon, 25 Jul 2011 15:25:11 -0700 (PDT) Received: by gwb20 with SMTP id 20so3344700gwb.31 for ; Mon, 25 Jul 2011 15:25:10 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=9rpClYtkE+YvenuZSYw2w7t8BlG7BwSQtw+Y6I80xD4=; b=TDdOm/7FCbPFf2PMkfSP1iGbgyF0e+ykDvt288z1103oKksgMP7P7qx2ndz6YLow7H Ly33b0RcKK5qRKmTGrFO5BgNi0CjOa7z9UT4uD4tV/zQhRdYLsJGGIro3Bk5F6qvv+wn 0ukllUItZ5h52CV5lex0KCKMx2RvvUVUQwbKA= Received: by 10.142.234.8 with SMTP id g8mr3413933wfh.180.1311632709974; Mon, 25 Jul 2011 15:25:09 -0700 (PDT) Received: from [127.0.0.1] (dhcp-150a.meeting.ietf.org [130.129.21.10]) by mx.google.com with ESMTPS id o3sm2118988wfd.21.2011.07.25.15.25.08 (version=SSLv3 cipher=OTHER); Mon, 25 Jul 2011 15:25:09 -0700 (PDT) Message-ID: <4E2DED42.2090902@gmail.com> Date: Tue, 26 Jul 2011 00:25:06 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: JP Vasseur References: <20110725164130.11058.51738.idtracker@ietfa.amsl.com> <4E2DBB77.3060304@gmail.com> <04A37653-9900-478B-A083-60498A3E93B7@cisco.com> In-Reply-To: <04A37653-9900-478B-A083-60498A3E93B7@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] Fwd: I-D Action: draft-ietf-roll-applicability-ami-00.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, 25 Jul 2011 22:25:13 -0000 JP - I CC the group, I hope you dont mind. I checked the slides you sent below, and in its slide 8 the process [supposedly a Chair to follow] is: - notify the wg - tell Secretariat - tell authors do 00 A number of other things in that set of slides make me think WG should somehow approve prior to do 00. It is strange to see a draft-ietf without having been individual submission first. I wish I were that lucky Author to get a wg item that easily - practically an rfc :-) Maybe there is a misunderstanding somewhere - has this draft been an individual proposal first, and I missed it? Alex Le 25/07/2011 21:22, JP Vasseur a écrit : > Alex, please read: > http://wiki.tools.ietf.org/group/edu/attachment/wiki/IETF78/IETF78-WGchairs-Adrian-Farrel.ppt?format=raw > > On Jul 25, 2011, at 2:52 PM, Alexandru Petrescu wrote: > >> I have precisely the same concern. >> >> It seems the Chairs are confident this WG accepts that item without >> asking. >> >> Alex >> >> Le 25/07/2011 20:45, Ulrich Herberg a écrit : >> > Hi, >> > >> > I must have missed the decision of the WG to adopt >> > draft-popa-roll-applicability-ami-00 as a WG document, at least I did >> > not see any discussion about it on the mailing list. Could you please >> > point me to that discussion in the archives? >> > >> > Thanks >> > Ulrich >> > >> > On Mon, Jul 25, 2011 at 1:09 PM, JP Vasseur > >> > > wrote: >> > >> > Dear all, >> > >> > As discussed during the last IETF meeting, we have several important >> > WG items in our charter, >> > and in particular the "applicability >> > statement". draft-ietf-roll-applicability-ami-00.txt is the first one, >> > please comment on the mailing list. Needless to say that the >> > document is now under the control >> > of the WG and additions/changes can be made through dicussion on the >> > mailing list. >> > >> > Thanks. >> > >> > JP. >> > >> > Begin forwarded message: >> > >> >> *From: * >> > >> >> *Subject: **[Roll] I-D Action: >> >> draft-ietf-roll-applicability-ami-00.txt* >> >> *Date: *July 25, 2011 12:41:30 PM EDT >> >> *To: * >> > >> >> *Cc: * > >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> >> directories. This draft is a work item of the Routing Over Low >> >> power and Lossy networks Working Group of the IETF. >> >> >> >> Title : Applicability Statement for the Routing >> >> Protocol for Low Power and Lossy Networks (RPL) in AMI Networks >> >> Author(s) : Daniel Popa >> >> Jorjeta Jetcheva >> >> Nicolas Dejean >> >> Ruben Salazar >> >> Jonathan W. Hui >> >> Filename : draft-ietf-roll-applicability-ami-00.txt >> >> Pages : 13 >> >> Date : 2011-07-25 >> >> >> >> This document discusses the applicability of RPL in Advanced >> >> Metering >> >> Infrastructure (AMI) networks. >> >> >> >> >> >> A URL for this Internet-Draft is: >> >> >> http://www.ietf.org/internet-drafts/draft-ietf-roll-applicability-ami-00.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-applicability-ami-00.txt >> >> _______________________________________________ >> >> Roll mailing list >> >> Roll@ietf.org >> >> https://www.ietf.org/mailman/listinfo/roll >> >> >> > >> > >> > _______________________________________________ >> > Roll mailing list >> > Roll@ietf.org >> > https://www.ietf.org/mailman/listinfo/roll >> > >> > >> > >> > >> > _______________________________________________ >> > Roll mailing list >> > Roll@ietf.org >> > https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > From alexandru.petrescu@gmail.com Mon Jul 25 15:48: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 7F60311E80D7 for ; Mon, 25 Jul 2011 15:48:15 -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 mvFQ9quuWl0P for ; Mon, 25 Jul 2011 15:48:14 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id B1F6E11E80CF for ; Mon, 25 Jul 2011 15:48:14 -0700 (PDT) Received: by yie30 with SMTP id 30so2956308yie.31 for ; Mon, 25 Jul 2011 15:48:14 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=aqek9ah2/9fZhTI7Bo+508ZN+jCLLcxFdFEgUFccz9w=; b=OwnRV4vlrKzXNXBOnfLZgHdJ/mF5P6DzX0SF87bMI37DJ69KNT9Pps3yciOplZ0yKw ySr42wsZbYoC2Zx9qxBsRGgFBWFI2F1XDRR7EnCr0BFOro9Jg+4BsKrU7XFJsCUsPoNy 3iVaDIA65ZzEgDXdDPsk9MrbJAE3f3NxUEwJE= Received: by 10.143.6.18 with SMTP id j18mr3312704wfi.348.1311634092607; Mon, 25 Jul 2011 15:48:12 -0700 (PDT) Received: from [127.0.0.1] (dhcp-150a.meeting.ietf.org [130.129.21.10]) by mx.google.com with ESMTPS id a14sm1106261wfg.19.2011.07.25.15.48.10 (version=SSLv3 cipher=OTHER); Mon, 25 Jul 2011 15:48:11 -0700 (PDT) Message-ID: <4E2DF2A8.9000500@gmail.com> Date: Tue, 26 Jul 2011 00:48:08 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: JP Vasseur References: <20110725164130.11058.51738.idtracker@ietfa.amsl.com> <4E2DBB77.3060304@gmail.com> <04A37653-9900-478B-A083-60498A3E93B7@cisco.com> In-Reply-To: <04A37653-9900-478B-A083-60498A3E93B7@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] Fwd: I-D Action: draft-ietf-roll-applicability-ami-00.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, 25 Jul 2011 22:48:15 -0000 Le 25/07/2011 21:22, JP Vasseur a écrit : > Alex, please read: > http://wiki.tools.ietf.org/group/edu/attachment/wiki/IETF78/IETF78-WGchairs-Adrian-Farrel.ppt?format=raw Its slide 10 "Going straight to wg id" has a bullet saying important to keep this open. I believe this was not open, because I have only seen this wg id 0 announcement. Moreover I thought the applicability drafts (already 4) were done. You have to be aware - please be aware - that this kind of work is sometimes over-advertised outside ietf, with negative effects. Alex > > On Jul 25, 2011, at 2:52 PM, Alexandru Petrescu wrote: > >> I have precisely the same concern. >> >> It seems the Chairs are confident this WG accepts that item without >> asking. >> >> Alex >> >> Le 25/07/2011 20:45, Ulrich Herberg a écrit : >> > Hi, >> > >> > I must have missed the decision of the WG to adopt >> > draft-popa-roll-applicability-ami-00 as a WG document, at least I did >> > not see any discussion about it on the mailing list. Could you please >> > point me to that discussion in the archives? >> > >> > Thanks >> > Ulrich >> > >> > On Mon, Jul 25, 2011 at 1:09 PM, JP Vasseur > >> > > wrote: >> > >> > Dear all, >> > >> > As discussed during the last IETF meeting, we have several important >> > WG items in our charter, >> > and in particular the "applicability >> > statement". draft-ietf-roll-applicability-ami-00.txt is the first one, >> > please comment on the mailing list. Needless to say that the >> > document is now under the control >> > of the WG and additions/changes can be made through dicussion on the >> > mailing list. >> > >> > Thanks. >> > >> > JP. >> > >> > Begin forwarded message: >> > >> >> *From: * >> > >> >> *Subject: **[Roll] I-D Action: >> >> draft-ietf-roll-applicability-ami-00.txt* >> >> *Date: *July 25, 2011 12:41:30 PM EDT >> >> *To: * >> > >> >> *Cc: * > >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> >> directories. This draft is a work item of the Routing Over Low >> >> power and Lossy networks Working Group of the IETF. >> >> >> >> Title : Applicability Statement for the Routing >> >> Protocol for Low Power and Lossy Networks (RPL) in AMI Networks >> >> Author(s) : Daniel Popa >> >> Jorjeta Jetcheva >> >> Nicolas Dejean >> >> Ruben Salazar >> >> Jonathan W. Hui >> >> Filename : draft-ietf-roll-applicability-ami-00.txt >> >> Pages : 13 >> >> Date : 2011-07-25 >> >> >> >> This document discusses the applicability of RPL in Advanced >> >> Metering >> >> Infrastructure (AMI) networks. >> >> >> >> >> >> A URL for this Internet-Draft is: >> >> >> http://www.ietf.org/internet-drafts/draft-ietf-roll-applicability-ami-00.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-applicability-ami-00.txt >> >> _______________________________________________ >> >> Roll mailing list >> >> Roll@ietf.org >> >> https://www.ietf.org/mailman/listinfo/roll >> >> >> > >> > >> > _______________________________________________ >> > Roll mailing list >> > Roll@ietf.org >> > https://www.ietf.org/mailman/listinfo/roll >> > >> > >> > >> > >> > _______________________________________________ >> > 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 Mon Jul 25 16:55: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 DB30411E80DE for ; Mon, 25 Jul 2011 16:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.293 X-Spam-Level: X-Spam-Status: No, score=-102.293 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 Itvr+LgEQXyc for ; Mon, 25 Jul 2011 16:55:14 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id F00BA11E80DB for ; Mon, 25 Jul 2011 16:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=15280; q=dns/txt; s=iport; t=1311638114; x=1312847714; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=RzytWvuNpr8r4Qm/HA6rKm3RHJr5ulhepag++deQWyk=; b=d1dlQsrWK8BNyISV39hk3ZktekOewOcnuCEjv93UpkSr5qts5XnShAIk q2kyQasAKSOn16mHxxfyJ3Y4scGTOHnQCJdfWCOJxgNWZJ+ciIiyl01cp xVHSqE/AxcILggISjE6/NaEeA2GzkrOr4J8cvN24DenlU+OebJVvQeEw8 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAGsBLk6rRDoG/2dsb2JhbAA0AQEBAQIBAQEBEQEeRwsFDAwRAwECATMHFBgjDggHFw0MDp8IiC13iHwEokqeQoVgXwSScoUHCYts X-IronPort-AV: E=Sophos;i="4.67,265,1309737600"; d="scan'208,217";a="6300546" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-5.cisco.com with ESMTP; 25 Jul 2011 23:55:13 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6PNshBY030122; Mon, 25 Jul 2011 23:55:12 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jul 2011 16:54:46 -0700 Received: from [10.255.254.166] ([10.82.214.238]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jul 2011 16:52:40 -0700 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_2FBEF38D-3CD9-4032-9FE5-15498D6B88A3" From: JP Vasseur In-Reply-To: <4E2DF2A8.9000500@gmail.com> Date: Mon, 25 Jul 2011 19:52:37 -0400 Message-Id: <9F3DB5EB-8417-4B3A-8E80-03E93C6AF00F@cisco.com> References: <20110725164130.11058.51738.idtracker@ietfa.amsl.com> <4E2DBB77.3060304@gmail.com> <04A37653-9900-478B-A083-60498A3E93B7@cisco.com> <4E2DF2A8.9000500@gmail.com> To: "Alexandru Petrescu" X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 25 Jul 2011 23:52:45.0723 (UTC) FILETIME=[F373D6B0:01CC4B25] Cc: roll@ietf.org Subject: Re: [Roll] Fwd: I-D Action: draft-ietf-roll-applicability-ami-00.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, 25 Jul 2011 23:55:16 -0000 --Apple-Mail=_2FBEF38D-3CD9-4032-9FE5-15498D6B88A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 25, 2011, at 6:48 PM, Alexandru Petrescu wrote: > Le 25/07/2011 21:22, JP Vasseur a =E9crit : > > Alex, please read: > > = http://wiki.tools.ietf.org/group/edu/attachment/wiki/IETF78/IETF78-WGchair= s-Adrian-Farrel.ppt?format=3Draw >=20 > Its slide 10 "Going straight to wg id" has a bullet saying important = to > keep this open. I believe this was not open, because I have only seen > this wg id 0 announcement. >=20 Answer two of your questions: you missed it but there was an individual = submission. And yes this is *open*, as I said just the base work =85=20 >=20 > Moreover I thought the applicability drafts (already 4) were done. >=20 >=20 Ah ? No =85=20 > You have to be aware - please be aware - that this kind of work is > sometimes over-advertised outside ietf, with negative effects. >=20 >=20 Let me clarify a bit more.=20 1) As you know, producing applicability statements is on our charter: 2) There was no alternative draft for this WG item, 3) To answer your question, yes you missed it, but there was an = individual submission and make it a WG document does not violate any process, 4) The IESG asked the chairs to deliver on that particular milestone Note also that this was not a contentious protocol work with several = documents being discussed by the WG, simply the base for further work on an applicability = statement addressing a WG item. Now, this document is also yours (this is a WG document), feel free to = provide comments. The more comments we have the better to make this document as relevant as = possible for our community. Thanks. JP. > Alex >=20 > > > > On Jul 25, 2011, at 2:52 PM, Alexandru Petrescu wrote: > > > >> I have precisely the same concern. > >> > >> It seems the Chairs are confident this WG accepts that item without > >> asking. > >> > >> Alex > >> > >> Le 25/07/2011 20:45, Ulrich Herberg a =E9crit : > >> > Hi, > >> > > >> > I must have missed the decision of the WG to adopt > >> > draft-popa-roll-applicability-ami-00 as a WG document, at least I = did > >> > not see any discussion about it on the mailing list. Could you = please > >> > point me to that discussion in the archives? > >> > > >> > Thanks > >> > Ulrich > >> > > >> > On Mon, Jul 25, 2011 at 1:09 PM, JP Vasseur >> > >> > > wrote: > >> > > >> > Dear all, > >> > > >> > As discussed during the last IETF meeting, we have several = important > >> > WG items in our charter, > >> > and in particular the "applicability > >> > statement". draft-ietf-roll-applicability-ami-00.txt is the first = one, > >> > please comment on the mailing list. Needless to say that the > >> > document is now under the control > >> > of the WG and additions/changes can be made through dicussion on = the > >> > mailing list. > >> > > >> > Thanks. > >> > > >> > JP. > >> > > >> > Begin forwarded message: > >> > > >> >> *From: * > >> > > >> >> *Subject: **[Roll] I-D Action: > >> >> draft-ietf-roll-applicability-ami-00.txt* > >> >> *Date: *July 25, 2011 12:41:30 PM EDT > >> >> *To: * > >> > > >> >> *Cc: * = > > >> >> > >> >> A New Internet-Draft is available from the on-line = Internet-Drafts > >> >> directories. This draft is a work item of the Routing Over Low > >> >> power and Lossy networks Working Group of the IETF. > >> >> > >> >> Title : Applicability Statement for the Routing > >> >> Protocol for Low Power and Lossy Networks (RPL) in AMI Networks > >> >> Author(s) : Daniel Popa > >> >> Jorjeta Jetcheva > >> >> Nicolas Dejean > >> >> Ruben Salazar > >> >> Jonathan W. Hui > >> >> Filename : draft-ietf-roll-applicability-ami-00.txt > >> >> Pages : 13 > >> >> Date : 2011-07-25 > >> >> > >> >> This document discusses the applicability of RPL in Advanced > >> >> Metering > >> >> Infrastructure (AMI) networks. > >> >> > >> >> > >> >> A URL for this Internet-Draft is: > >> >> > >> = http://www.ietf.org/internet-drafts/draft-ietf-roll-applicability-ami-00.t= xt > >> >> > >> >> 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-applicability-ami-00.tx= t > >> >> _______________________________________________ > >> >> 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 > >> > > >=20 >=20 --Apple-Mail=_2FBEF38D-3CD9-4032-9FE5-15498D6B88A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Re: [Roll] Fwd: I-D Action: = draft-ietf-roll-applicability-ami-00.txt

Le = 25/07/2011 21:22, JP Vasseur a =E9crit :
> Alex, please read:
> http://wiki.tools.ietf.org/group= /edu/attachment/wiki/IETF78/IETF78-WGchairs-Adrian-Farrel.ppt?format=3Draw=

Its slide 10 "Going straight to wg id" has a bullet saying important = to
keep this open.  I believe this was not open, because I have only = seen
this wg id 0 announcement.

Answer two = of your questions: you missed it but there was an individual = submission.
And yes this is *open*, as I said just the base = work =85 


Moreover I thought the applicability drafts (already 4) were done.

Ah ? No =85 

You have to be aware - please be aware - that this kind of work is
sometimes over-advertised outside ietf, with negative effects.

Let me clarify a bit = more. 
1) As you know, producing applicability statements = is on our charter:
2) There was no alternative draft for this = WG item,
3) To answer your question, yes you missed it, but = there was an individual submission
and make it a WG document = does not violate any process,
4) The IESG asked the = chairs to deliver on that particular = milestone

Note also that this was not a = contentious protocol work with several documents being = discussed
by the WG, simply the base for further work on an = applicability statement addressing a WG = item.

Now, this document is also yours (this is = a WG document), feel free to provide comments. The = more
comments we have the better to make this document as = relevant as possible for our = community.

Thanks.

JP.

Alex

>
> On Jul 25, 2011, at 2:52 PM, Alexandru Petrescu wrote:
>
>> I have precisely the same concern.
>>
>> It seems the Chairs are confident this WG accepts that item = without
>> asking.
>>
>> Alex
>>
>> Le 25/07/2011 20:45, Ulrich Herberg a =E9crit :
>> > Hi,
>> >
>> > I must have missed the decision of the WG to adopt
>> > draft-popa-roll-applicability-ami-00 as a WG document, at = least I did
>> > not see any discussion about it on the mailing list. Could = you please
>> > point me to that discussion in the archives?
>> >
>> > Thanks
>> > Ulrich
>> >
>> > On Mon, Jul 25, 2011 at 1:09 PM, JP Vasseur <jpv@cisco.com
>> <mailto:jpv@cisco.com>
>> > <mailto:jpv@cisco.com>> = wrote:
>> >
>> > Dear all,
>> >
>> > As discussed during the last IETF meeting, we have several = important
>> > WG items in our charter,
>> > and in particular the "applicability
>> > statement". draft-ietf-roll-applicability-ami-00.txt is = the first one,
>> > please comment on the mailing list. Needless to say that = the
>> > document is now under the control
>> > of the WG and additions/changes can be made through = dicussion on the
>> > mailing list.
>> >
>> > Thanks.
>> >
>> > JP.
>> >
>> > Begin forwarded message:
>> >
>> >> *From: *<internet-drafts@ietf.org = <mailto:internet-drafts@ietf.org>
>> <
mailto:internet-drafts@ietf.org>>
>> >> *Subject: **[Roll] I-D Action:
>> >> draft-ietf-roll-applicability-ami-00.txt*
>> >> *Date: *July 25, 2011 12:41:30 PM EDT
>> >> *To: *<
i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>=
>> <mailto:i-d-announce@ietf.org>= >
>> >> *Cc: *<roll@ietf.org <mailto:roll@ietf.org> <mailto:roll@ietf.org>>
>> >>
>> >> A New Internet-Draft is available from the on-line = Internet-Drafts
>> >> directories. This draft is a work item of the Routing = Over Low
>> >> power and Lossy networks Working Group of the = IETF.
>> >>
>> >> Title : Applicability Statement for the Routing
>> >> Protocol for Low Power and Lossy Networks (RPL) in AMI = Networks
>> >> Author(s) : Daniel Popa
>> >> Jorjeta Jetcheva
>> >> Nicolas Dejean
>> >> Ruben Salazar
>> >> Jonathan W. Hui
>> >> Filename : = draft-ietf-roll-applicability-ami-00.txt
>> >> Pages : 13
>> >> Date : 2011-07-25
>> >>
>> >> This document discusses the applicability of RPL in = Advanced
>> >> Metering
>> >> Infrastructure (AMI) networks.
>> >>
>> >>
>> >> A URL for this Internet-Draft is:
>> >>
>> http://www.ietf.org/internet-drafts/draft-ietf-roll-applicabil= ity-ami-00.txt
>> >>
>> >> Internet-Drafts are also available by anonymous FTP = at:
>> >> ftp://ftp.ietf.org/internet-d= rafts/
>> >>
>> >> This Internet-Draft can be retrieved at:
>> >>
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-applicabilit= y-ami-00.txt
>> >> _______________________________________________
>> >> Roll mailing list
>> >> Roll@ietf.org = <mailto:Roll@ietf.org> <mailto:Roll@ietf.org>
>> >> https://www.ietf.org/m= ailman/listinfo/roll
>> >>
>> >
>> >
>> > _______________________________________________
>> > Roll mailing list
>> > Roll@ietf.org <mailto:Roll@ietf.org> <mailto:Roll@ietf.org>
>> > https://www.ietf.org/m= ailman/listinfo/roll
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Roll mailing list
>> > Roll@ietf.org <mailto:Roll@ietf.org>
>> > https://www.ietf.org/m= ailman/listinfo/roll
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org <mailto:Roll@ietf.org>
>> https://www.ietf.org/m= ailman/listinfo/roll
>>
>


= --Apple-Mail=_2FBEF38D-3CD9-4032-9FE5-15498D6B88A3-- From jpv@cisco.com Mon Jul 25 17:06: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 4824421F86CA for ; Mon, 25 Jul 2011 17:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.254 X-Spam-Level: X-Spam-Status: No, score=-105.254 tagged_above=-999 required=5 tests=[AWL=-2.656, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 DLe6PtYY05PG for ; Mon, 25 Jul 2011 17:06:20 -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 4F2BB21F86C2 for ; Mon, 25 Jul 2011 17:06:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=4315; q=dns/txt; s=iport; t=1311638780; x=1312848380; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=u/9/wW1us2ShBgvhMXEgDfC1NOSuC3Zel2LHDKLaA6c=; b=FXwgwnZjOSQZmO58FpdYioYuyjoAHXGAQ6GHFfWy9ZQS/ZYc1ogGGCg/ dm5RQx+HQY7f70gP1kJARigbZipGpcl6TkjFerMT8Sj8xFGLavfFW1Z// /osk6nxkj5prUGy1ZEhKGUdGJQkJQGP11LQ4YLlPOsDfgaNFxGK8snWYV I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMFAMUDLk6tJV2b/2dsb2JhbAA0AQEBAQIBAQEBEQFlCwUMDAQUOhQYOQcXBSKCNpxSAYgsd4h8BKJQnkWFYF8EknKFBwmLbA X-IronPort-AV: E=Sophos;i="4.67,265,1309737600"; d="scan'208,217";a="6304252" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 26 Jul 2011 00:06:19 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6Q06Jhw021535; Tue, 26 Jul 2011 00:06:19 GMT Received: from xfe-rcd-302.cisco.com ([72.163.63.13]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jul 2011 19:06:19 -0500 Received: from [10.255.254.166] ([10.82.214.238]) by xfe-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jul 2011 19:06:16 -0500 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_62D0C18B-C602-42E3-811B-2C5650CB950A" From: JP Vasseur In-Reply-To: Date: Mon, 25 Jul 2011 19:55:11 -0400 Message-Id: <91B46371-480F-42E2-A9C0-4CE6976DC35D@cisco.com> References: <42B54ABB-9B22-485F-BB11-887CBA815105@watteco.com> To: Emmanuel Baccelli X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 26 Jul 2011 00:06:17.0585 (UTC) FILETIME=[D75C2610:01CC4B27] Cc: ROLL WG Subject: Re: [Roll] P2P implementation (draft-ietf-roll-p2p-rpl) 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, 26 Jul 2011 00:06:21 -0000 --Apple-Mail=_62D0C18B-C602-42E3-811B-2C5650CB950A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Thanks a lot for sharing Emmanuel. On Jul 25, 2011, at 2:53 PM, Emmanuel Baccelli wrote: > Hi Cedric, > the code is based on Contiki 2.5-rc1 > Cheers > Emmanuel >=20 > On Mon, Jul 25, 2011 at 6:55 PM, C Chauvenet = wrote: > Hi Emmanuel,=20 >=20 > This looks gorgeous. >=20 > =46rom what Contiki version did you start the implementation ? > I've CCed the implementer. >=20 > C=E9dric. >=20 > Le 25 juil. 2011 =E0 18:44, Emmanuel Baccelli a =E9crit : >=20 >> Hi Rollers, >>=20 >> here is a link to our open source implementation of the P2P extension = (http://tools.ietf.org/html/draft-ietf-roll-p2p-rpl-04). >>=20 >> The implementation builds upon the Contiki OS code base, and is = available at the below url: >> http://www.lix.polytechnique.fr/~mphi/p2p/ >>=20 >> We are looking forward to feedback from you testers out there! >>=20 >> cheers, >>=20 >> Emmanuel >>=20 >>=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail=_62D0C18B-C602-42E3-811B-2C5650CB950A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Hi = Cedric,
the code is based on = Contiki 2.5-rc1
Cheers
Emmanuel

On Mon, Jul 25, 2011 at 6:55 PM, C Chauvenet <c.chauvenet@watteco.com> wrote:
Hi = Emmanuel, 

This looks gorgeous.

=46rom what Contiki version did you start the implementation = ?
I've CCed the = implementer.

C=E9dric.

<= div class=3D"im">
Le 25 juil. 2011 =E0 18:44, Emmanuel Baccelli a = =E9crit :

Hi Rollers,

here is a link to our open source implementation of the P2P = extension (http://tools.ietf.org/html/draft-ietf-roll-p2p-rpl-04).

The implementation builds upon the Contiki OS code base, and is = available at the below url:
http://www.lix.polytechnique.fr/~mphi/p2p/

We are looking forward to feedback from you testers out = there!

cheers,

Emmanuel


=


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


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

= --Apple-Mail=_62D0C18B-C602-42E3-811B-2C5650CB950A-- From ulrich@herberg.name Mon Jul 25 21:18: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 3FAA921F8B1C for ; Mon, 25 Jul 2011 21:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 E32-SVEB06L6 for ; Mon, 25 Jul 2011 21:18:35 -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 BB86021F8B07 for ; Mon, 25 Jul 2011 21:18:34 -0700 (PDT) Received: by vxi40 with SMTP id 40so71240vxi.31 for ; Mon, 25 Jul 2011 21:18:34 -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=SiK7s2lN6TTj9Uwfr7siLCx2LzbOF/n/ByAoWP3ZBDk=; b=0fkpumaliLc/3EM4NKduH75I2ud02yQ2KlIpdKw9OXgUgqp2i05alJxZHUaF/rjseS W80mZ9Mx6XR9sD3sCJVxlJTSNNHeP/BLg4ITjRWyf1tkNwZiVZhFhsuA3248RCwV4/Og x3Cor1bcKVz2FnKxxl7YQEkHZ5oVYHD8P7BRk= MIME-Version: 1.0 Received: by 10.52.97.33 with SMTP id dx1mr5355541vdb.34.1311653912643; Mon, 25 Jul 2011 21:18:32 -0700 (PDT) Received: by 10.220.2.15 with HTTP; Mon, 25 Jul 2011 21:18:32 -0700 (PDT) In-Reply-To: <9F3DB5EB-8417-4B3A-8E80-03E93C6AF00F@cisco.com> References: <20110725164130.11058.51738.idtracker@ietfa.amsl.com> <4E2DBB77.3060304@gmail.com> <04A37653-9900-478B-A083-60498A3E93B7@cisco.com> <4E2DF2A8.9000500@gmail.com> <9F3DB5EB-8417-4B3A-8E80-03E93C6AF00F@cisco.com> Date: Tue, 26 Jul 2011 00:18:32 -0400 Message-ID: From: Ulrich Herberg To: JP Vasseur Content-Type: multipart/alternative; boundary=20cf307f30ee88072c04a8f1392c Cc: roll@ietf.org Subject: Re: [Roll] Fwd: I-D Action: draft-ietf-roll-applicability-ami-00.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, 26 Jul 2011 04:18:36 -0000 --20cf307f30ee88072c04a8f1392c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable JP, On Mon, Jul 25, 2011 at 7:52 PM, JP Vasseur wrote: > Let me clarify a bit more. > 1) As you know, producing applicability statements is on our charter: > 2) There was no alternative draft for this WG item, > Well, that may well be true, but the individual document was just submitted a few weeks ago, and has only be announced on the ROLL mailing list today (unless I have missed a discussion on that on the mailing list, in which case I beg for pardon). > 3) To answer your question, yes you missed it, but there was an individua= l > submission > and make it a WG document does not violate any process, > Yes, it is formally not incorrect, but leaving only 12 hours from announcin= g an individual draft on the list to adopting it as WG document without discussing it in the WG is pretty fast. > 4) The IESG asked the chairs to deliver on that particular milestone > > Note also that this was not a contentious protocol work with several > documents being discussed > by the WG, simply the base for further work on an applicability statement > addressing a WG item. > > Now, this document is also yours (this is a WG document), feel free to > provide comments. The more > comments we have the better to make this document as relevant as possible > for our community. > As you mentioned the slides from Adrian, I just would like to point out tha= t the slide "criteria for adoption" mentions: - (citing RFC 4677) "Working Group drafts are usually reviewed by the Working Group before being accepted as a WG item, although the chairs have the final say." So I would like to know what the reason was for not asking the WG (and that only 12 hours after announcing the individual draft on the mailing list). - "There is good support to work on the I-D" and "The level of technical (o= r other) objections is low" My 2cts on the draft: I do not think this draft has the necessary level of quality for a WG document, and my personal opinion is that it should not have been adopted in its current form. I could go into technical details here now, but in this email, I just wanted to argue on the procedure. Regards Ulrich > > Thanks. > > JP. > > Alex > > > > > On Jul 25, 2011, at 2:52 PM, Alexandru Petrescu wrote: > > > >> I have precisely the same concern. > >> > >> It seems the Chairs are confident this WG accepts that item without > >> asking. > >> > >> Alex > >> > >> Le 25/07/2011 20:45, Ulrich Herberg a =E9crit : > >> > Hi, > >> > > >> > I must have missed the decision of the WG to adopt > >> > draft-popa-roll-applicability-ami-00 as a WG document, at least I di= d > >> > not see any discussion about it on the mailing list. Could you pleas= e > >> > point me to that discussion in the archives? > >> > > >> > Thanks > >> > Ulrich > >> > > >> > On Mon, Jul 25, 2011 at 1:09 PM, JP Vasseur >> > > >> > >> wrote: > >> > > >> > Dear all, > >> > > >> > As discussed during the last IETF meeting, we have several important > >> > WG items in our charter, > >> > and in particular the "applicability > >> > statement". draft-ietf-roll-applicability-ami-00.txt is the first on= e, > >> > please comment on the mailing list. Needless to say that the > >> > document is now under the control > >> > of the WG and additions/changes can be made through dicussion on the > >> > mailing list. > >> > > >> > Thanks. > >> > > >> > JP. > >> > > >> > Begin forwarded message: > >> > > >> >> *From: * > > > >> >> > >> >> *Subject: **[Roll] I-D Action: > >> >> draft-ietf-roll-applicability-ami-00.txt* > >> >> *Date: *July 25, 2011 12:41:30 PM EDT > >> >> *To: * > > > >> >> > >> >> *Cc: *> < > mailto:roll@ietf.org >> > >> >> > >> >> A New Internet-Draft is available from the on-line Internet-Drafts > >> >> directories. This draft is a work item of the Routing Over Low > >> >> power and Lossy networks Working Group of the IETF. > >> >> > >> >> Title : Applicability Statement for the Routing > >> >> Protocol for Low Power and Lossy Networks (RPL) in AMI Networks > >> >> Author(s) : Daniel Popa > >> >> Jorjeta Jetcheva > >> >> Nicolas Dejean > >> >> Ruben Salazar > >> >> Jonathan W. Hui > >> >> Filename : draft-ietf-roll-applicability-ami-00.txt > >> >> Pages : 13 > >> >> Date : 2011-07-25 > >> >> > >> >> This document discusses the applicability of RPL in Advanced > >> >> Metering > >> >> Infrastructure (AMI) networks. > >> >> > >> >> > >> >> A URL for this Internet-Draft is: > >> >> > >> > http://www.ietf.org/internet-drafts/draft-ietf-roll-applicability-ami-00.= 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-applicability-ami-00.t= xt > > --20cf307f30ee88072c04a8f1392c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable JP,

On Mon, Jul 25, 2011 at 7:52 PM, JP V= asseur <jpv@cisco.com= > wrote:
Let me clarify a bit mor= e.=A0
1) As you know, producing applicability statements is on ou= r charter:
2) There was no alternative draft for this WG item,

Well, that may well be true, but th= e individual document was just submitted a few weeks ago, and has only be a= nnounced on the ROLL mailing list today (unless I have missed a discussion = on that on the mailing list, in which case I beg for pardon).

=A0
3) To answer your question= , yes you missed it, but there was an individual submission
and make it a WG document does not violate any process,

Yes, it is formally not incorrect, but leavi= ng only 12 hours from announcing an individual draft on the list to adoptin= g it as WG document without discussing it in the WG is pretty fast.

=A0
4)=A0The IESG asked the ch= airs to deliver on that particular milestone

Note also that this was not a contentious protocol work= with several documents being discussed
by the WG, simply the bas= e for further work on an applicability statement addressing a WG item.

Now, this document is also yours (this is a WG document= ), feel free to provide comments. The more
comments we have the b= etter to make this document as relevant as possible for our community.


As you mentioned the slides fro= m Adrian, I just would like to point out that the slide "criteria for = adoption" mentions:
=A0- (citing RFC 4677) "Working Group draf= ts are usually reviewed by the Working Group before being accepted as a WG = item, although the chairs have the final say."

So I would like to know what the reason was for not asking the WG (and = that only 12 hours after announcing the individual draft on the mailing lis= t).

- "There is good support to work on the I-D" and "= ;The level of technical (or other) objections is low"

My 2cts on the draft: I do not think=20 this draft has the necessary level of quality for a WG document, and my per= sonal opinion is that it should not have been adopted in its current form. I could go into technical details here now, b= ut in this email, I just wanted to argue on the procedure.
=A0

Re= gards
Ulrich

=A0

Thanks.=

JP.

Alex

>
> On Jul 25, 2011, at 2:52 PM, Alexandru Petrescu wrote:
>
>> I have precisely the same concern.
>>
>> It seems the Chairs are confident this WG accepts that item withou= t
>> asking.
>>
>> Alex
>>
>> Le 25/07/2011 20:45, Ulrich Herberg a =E9crit :
>> > Hi,
>> >
>> > I must have missed the decision of the WG to adopt
>> > draft-popa-roll-applicability-ami-00 as a WG document, at lea= st I did
>> > not see any discussion about it on the mailing list. Could yo= u please
>> > point me to that discussion in the archives?
>> >
>> > Thanks
>> > Ulrich
>> >
>> > On Mon, Jul 25, 2011 at 1:09 PM, JP Vasseur <jpv@cisco.com
>> <mailto:jpv@= cisco.com>
>> > <mailto= :jpv@cisco.com>> wrote:
>> >
>> > Dear all,
>> >
>> > As discussed during the last IETF meeting, we have several im= portant
>> > WG items in our charter,
>> > and in particular the "applicability
>> > statement". draft-ietf-roll-applicability-ami-00.txt is = the first one,
>> > please comment on the mailing list. Needless to say that the<= br> >> > document is now under the control
>> > of the WG and additions/changes can be made through dicussion= on the
>> > mailing list.
>> >
>> > Thanks.
>> >
>> > JP.
>> >
>> > Begin forwarded message:
>> >
>> >> *From: *<internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>= ;
>> <= mailto:internet-drafts@ietf.org>>
>> >> *Subject: **[Roll] I-D Action:
>> >> draft-ietf-roll-applicability-ami-00.txt*
>> >> *Date: *July 25, 2011 12:41:30 PM EDT
>> >> *To: *<i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
>> <mai= lto:i-d-announce@ietf.org>>
>> >> *Cc: *<roll@ietf.org <mailto:roll@ietf.org> <mailto:roll@ietf.org>>
>> >>
>> >> A New Internet-Draft is available from the on-line Intern= et-Drafts
>> >> directories. This draft is a work item of the Routing Ove= r Low
>> >> power and Lossy networks Working Group of the IETF.
>> >>
>> >> Title : Applicability Statement for the Routing
>> >> Protocol for Low Power and Lossy Networks (RPL) in AMI Ne= tworks
>> >> Author(s) : Daniel Popa
>> >> Jorjeta Jetcheva
>> >> Nicolas Dejean
>> >> Ruben Salazar
>> >> Jonathan W. Hui
>> >> Filename : draft-ietf-roll-applicability-ami-00.txt
>> >> Pages : 13
>> >> Date : 2011-07-25
>> >>
>> >> This document discusses the applicability of RPL in Advan= ced
>> >> Metering
>> >> Infrastructure (AMI) networks.
>> >>
>> >>
>> >> A URL for this Internet-Draft is:
>> >>
>> http://www.ietf.org/internet-draft= s/draft-ietf-roll-applicability-ami-00.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-applicability-ami-00.txt


--20cf307f30ee88072c04a8f1392c-- From jpv@cisco.com Tue Jul 26 07:01: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 2FBA621F8B1B for ; Tue, 26 Jul 2011 07:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 WLKFQS5dYpQS for ; Tue, 26 Jul 2011 07:01:54 -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 2A06C21F8B27 for ; Tue, 26 Jul 2011 07:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=15501; q=dns/txt; s=iport; t=1311688907; x=1312898507; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=Q9rs2v5D2acpBDDFGNufzcwrq94V0u7ndv6Na18ksko=; b=OgI057VHq3+izAPLNBhu7wrd78pa/okdptV7W2e6H9XToo31XKtrJMki uXCTBpWvbLT42QVccOt1dtcBQkPpGHbU7lIilPE6Bn2yQx+WLNJuViJiN JcGj/Ayil+DYpYdk/UQRmT7wB1sa1CPpR9Xw07rxmgZDat1+X0K/4zvmZ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANTHLk6rRDoH/2dsb2JhbAA1AQEBAQIBFAFlCwUMDBEDAQIBMwcUOw4IBxcNDA6Fd6E/d4h8BKJynmOFYV8EknKFBwmLbA X-IronPort-AV: E=Sophos;i="4.67,269,1309737600"; d="scan'208,217";a="6492251" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-8.cisco.com with ESMTP; 26 Jul 2011 14:01:46 +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 p6QE1ksI013636; Tue, 26 Jul 2011 14:01:46 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 07:01:45 -0700 Received: from [10.255.254.166] ([10.21.123.71]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 07:01:43 -0700 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_58AB0A29-8F64-47E7-9152-3ABD9381B243" From: JP Vasseur In-Reply-To: Date: Tue, 26 Jul 2011 10:01:38 -0400 Message-Id: <15C43589-A0FD-4066-BF5D-E35936A07210@cisco.com> References: <20110725164130.11058.51738.idtracker@ietfa.amsl.com><4E2DBB77.3060304@gmail.com><04A37653-9900-478B-A083-60498A3E93B7@cisco.com><4E2DF2A8.9000500@gmail.com><9F3DB5EB-8417-4B3A-8E80-03E93C6AF00F@cisco.com> To: Ulrich Herberg X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 26 Jul 2011 14:01:44.0377 (UTC) FILETIME=[8D419A90:01CC4B9C] Cc: roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-00.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, 26 Jul 2011 14:01:56 -0000 --Apple-Mail=_58AB0A29-8F64-47E7-9152-3ABD9381B243 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Good, we have a discussion on the process, to which I hope that I = answered. Now time to discuss the document, which once again is in our charter and = the IESG asked us to deliver =85 Your comments are welcome. Thanks. JP. On Jul 26, 2011, at 12:18 AM, Ulrich Herberg wrote: > JP, >=20 > On Mon, Jul 25, 2011 at 7:52 PM, JP Vasseur wrote: > Let me clarify a bit more.=20 > 1) As you know, producing applicability statements is on our charter: > 2) There was no alternative draft for this WG item, >=20 > Well, that may well be true, but the individual document was just = submitted a few weeks ago, and has only be announced on the ROLL mailing = list today (unless I have missed a discussion on that on the mailing = list, in which case I beg for pardon).=20 >=20 > =20 > 3) To answer your question, yes you missed it, but there was an = individual submission > and make it a WG document does not violate any process, >=20 > Yes, it is formally not incorrect, but leaving only 12 hours from = announcing an individual draft on the list to adopting it as WG document = without discussing it in the WG is pretty fast. >=20 > =20 > 4) The IESG asked the chairs to deliver on that particular milestone >=20 > Note also that this was not a contentious protocol work with several = documents being discussed > by the WG, simply the base for further work on an applicability = statement addressing a WG item. >=20 > Now, this document is also yours (this is a WG document), feel free to = provide comments. The more > comments we have the better to make this document as relevant as = possible for our community. >=20 >=20 > As you mentioned the slides from Adrian, I just would like to point = out that the slide "criteria for adoption" mentions: > - (citing RFC 4677) "Working Group drafts are usually reviewed by the = Working Group before being accepted as a WG item, although the chairs = have the final say."=20 >=20 > So I would like to know what the reason was for not asking the WG (and = that only 12 hours after announcing the individual draft on the mailing = list). >=20 > - "There is good support to work on the I-D" and "The level of = technical (or other) objections is low" >=20 > My 2cts on the draft: I do not think this draft has the necessary = level of quality for a WG document, and my personal opinion is that it = should not have been adopted in its current form. I could go into = technical details here now, but in this email, I just wanted to argue on = the procedure. > =20 >=20 > Regards > Ulrich >=20 > =20 >=20 > Thanks. >=20 > JP. >> Alex >>=20 >> > >> > On Jul 25, 2011, at 2:52 PM, Alexandru Petrescu wrote: >> > >> >> I have precisely the same concern. >> >> >> >> It seems the Chairs are confident this WG accepts that item = without >> >> asking. >> >> >> >> Alex >> >> >> >> Le 25/07/2011 20:45, Ulrich Herberg a =E9crit : >> >> > Hi, >> >> > >> >> > I must have missed the decision of the WG to adopt >> >> > draft-popa-roll-applicability-ami-00 as a WG document, at least = I did >> >> > not see any discussion about it on the mailing list. Could you = please >> >> > point me to that discussion in the archives? >> >> > >> >> > Thanks >> >> > Ulrich >> >> > >> >> > On Mon, Jul 25, 2011 at 1:09 PM, JP Vasseur > >> >> >> > > wrote: >> >> > >> >> > Dear all, >> >> > >> >> > As discussed during the last IETF meeting, we have several = important >> >> > WG items in our charter, >> >> > and in particular the "applicability >> >> > statement". draft-ietf-roll-applicability-ami-00.txt is the = first one, >> >> > please comment on the mailing list. Needless to say that the >> >> > document is now under the control >> >> > of the WG and additions/changes can be made through dicussion on = the >> >> > mailing list. >> >> > >> >> > Thanks. >> >> > >> >> > JP. >> >> > >> >> > Begin forwarded message: >> >> > >> >> >> *From: * >> >> > >> >> >> *Subject: **[Roll] I-D Action: >> >> >> draft-ietf-roll-applicability-ami-00.txt* >> >> >> *Date: *July 25, 2011 12:41:30 PM EDT >> >> >> *To: * >> >> > >> >> >> *Cc: * = > >> >> >> >> >> >> A New Internet-Draft is available from the on-line = Internet-Drafts >> >> >> directories. This draft is a work item of the Routing Over Low >> >> >> power and Lossy networks Working Group of the IETF. >> >> >> >> >> >> Title : Applicability Statement for the Routing >> >> >> Protocol for Low Power and Lossy Networks (RPL) in AMI Networks >> >> >> Author(s) : Daniel Popa >> >> >> Jorjeta Jetcheva >> >> >> Nicolas Dejean >> >> >> Ruben Salazar >> >> >> Jonathan W. Hui >> >> >> Filename : draft-ietf-roll-applicability-ami-00.txt >> >> >> Pages : 13 >> >> >> Date : 2011-07-25 >> >> >> >> >> >> This document discusses the applicability of RPL in Advanced >> >> >> Metering >> >> >> Infrastructure (AMI) networks. >> >> >> >> >> >> >> >> >> A URL for this Internet-Draft is: >> >> >> >> >> = http://www.ietf.org/internet-drafts/draft-ietf-roll-applicability-ami-00.t= xt >> >> >> >> >> >> 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-applicability-ami-00.tx= t >>=20 >=20 --Apple-Mail=_58AB0A29-8F64-47E7-9152-3ABD9381B243 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
JP,

On Mon, Jul 25, 2011 = at 7:52 PM, JP Vasseur <jpv@cisco.com> = wrote:
Let me clarify a bit = more. 
1) As you know, producing applicability statements = is on our charter:
2) There was no alternative draft for this = WG item,

Well, that may well be true, but = the individual document was just submitted a few weeks ago, and has only = be announced on the ROLL mailing list today (unless I have missed a = discussion on that on the mailing list, in which case I beg for pardon). =

 
3) To answer = your question, yes you missed it, but there was an individual = submission
and make it a WG document does not violate any = process,

Yes, it is = formally not incorrect, but leaving only 12 hours from announcing an = individual draft on the list to adopting it as WG document without = discussing it in the WG is pretty fast.

 
4) The = IESG asked the chairs to deliver on that particular milestone

Note also that this was not a contentious protocol = work with several documents being discussed
by the WG, simply = the base for further work on an applicability statement addressing a WG = item.

Now, this document is also yours (this is a WG = document), feel free to provide comments. The more
comments we = have the better to make this document as relevant as possible for our = community.


As you mentioned the slides = from Adrian, I just would like to point out that the slide "criteria for = adoption" mentions:
 - (citing RFC 4677) "Working Group drafts = are usually reviewed by the Working Group before being accepted as a WG = item, although the chairs have the final say."

So I would like to know what the reason was for not asking the WG = (and that only 12 hours after announcing the individual draft on the = mailing list).

- "There is good support to work on the I-D" and = "The level of technical (or other) objections is low"

My 2cts on the draft: I do not think=20 this draft has the necessary level of quality for a WG document, and my = personal opinion is that it should not have been adopted in its current form. I could go into technical details here = now, but in this email, I just wanted to argue on the = procedure.
 

Regards
Ulrich

 

Thanks.

JP.

Alex

>
> On Jul 25, 2011, at 2:52 PM, Alexandru Petrescu wrote:
>
>> I have precisely the same concern.
>>
>> It seems the Chairs are confident this WG accepts that item = without
>> asking.
>>
>> Alex
>>
>> Le 25/07/2011 20:45, Ulrich Herberg a =E9crit :
>> > Hi,
>> >
>> > I must have missed the decision of the WG to adopt
>> > draft-popa-roll-applicability-ami-00 as a WG document, at = least I did
>> > not see any discussion about it on the mailing list. Could = you please
>> > point me to that discussion in the archives?
>> >
>> > Thanks
>> > Ulrich
>> >
>> > On Mon, Jul 25, 2011 at 1:09 PM, JP Vasseur <jpv@cisco.com
>> <mailto:jpv@cisco.com>
>> > <mailto:jpv@cisco.com>> wrote:
>> >
>> > Dear all,
>> >
>> > As discussed during the last IETF meeting, we have several = important
>> > WG items in our charter,
>> > and in particular the "applicability
>> > statement". draft-ietf-roll-applicability-ami-00.txt is = the first one,
>> > please comment on the mailing list. Needless to say that = the
>> > document is now under the control
>> > of the WG and additions/changes can be made through = dicussion on the
>> > mailing list.
>> >
>> > Thanks.
>> >
>> > JP.
>> >
>> > Begin forwarded message:
>> >
>> >> *From: *<internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
>> <mailto:internet-drafts@ietf.org>>
>> >> *Subject: **[Roll] I-D Action:
>> >> draft-ietf-roll-applicability-ami-00.txt*
>> >> *Date: *July 25, 2011 12:41:30 PM EDT
>> >> *To: *<i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
>> <mailto:i-d-announce@ietf.org>>
>> >> *Cc: *<roll@ietf.org <mailto:roll@ietf.org> <mailto:roll@ietf.org>>
>> >>
>> >> A New Internet-Draft is available from the on-line = Internet-Drafts
>> >> directories. This draft is a work item of the Routing = Over Low
>> >> power and Lossy networks Working Group of the = IETF.
>> >>
>> >> Title : Applicability Statement for the Routing
>> >> Protocol for Low Power and Lossy Networks (RPL) in AMI = Networks
>> >> Author(s) : Daniel Popa
>> >> Jorjeta Jetcheva
>> >> Nicolas Dejean
>> >> Ruben Salazar
>> >> Jonathan W. Hui
>> >> Filename : = draft-ietf-roll-applicability-ami-00.txt
>> >> Pages : 13
>> >> Date : 2011-07-25
>> >>
>> >> This document discusses the applicability of RPL in = Advanced
>> >> Metering
>> >> Infrastructure (AMI) networks.
>> >>
>> >>
>> >> A URL for this Internet-Draft is:
>> >>
>> http://www.ietf.org/internet-drafts/draft-ietf-roll-appl= icability-ami-00.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-appli= cability-ami-00.txt



= --Apple-Mail=_58AB0A29-8F64-47E7-9152-3ABD9381B243-- From jpv@cisco.com Tue Jul 26 07:15: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 185E621F8456 for ; Tue, 26 Jul 2011 07:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.395 X-Spam-Level: X-Spam-Status: No, score=-102.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Sd0m4C1kkBfm for ; Tue, 26 Jul 2011 07:15:17 -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 85E5021F8CB4 for ; Tue, 26 Jul 2011 07:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=142; q=dns/txt; s=iport; t=1311689714; x=1312899314; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=Atm6Ryp0gm/SWqls4XhishFOC14czBe8l3c8mq1o6Sc=; b=I3u3poPeVvvYGdiyG8sMqveLis8z/wNd+J3xUbUwekyZdoBSBSvBDoKz GVKW0Se01NSeQVa8PI6LABkos+h7hTJXQLVrsgSTw/IzqLqRhsBWhBw2H RTeV34m5U3tpeSoQreKFDCtoRzbcBVSLpsrcKzjslsLPe9L1WqllM4hAG w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEANbKLk6rRDoG/2dsb2JhbABQASuBSFgkGqc2d4kAoWmBI55hhWFfBJJyhQcJi2w X-IronPort-AV: E=Sophos;i="4.67,269,1309737600"; d="scan'208";a="6496291" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-2.cisco.com with ESMTP; 26 Jul 2011 14:15:14 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6QEFDxb000971 for ; Tue, 26 Jul 2011 14:15:13 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 07:15:13 -0700 Received: from [10.255.254.166] ([10.21.123.71]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 07:15:12 -0700 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 26 Jul 2011 10:15:05 -0400 Message-Id: <86C9F55C-215F-445E-96A8-9218341A92D5@cisco.com> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 26 Jul 2011 14:15:12.0935 (UTC) FILETIME=[6F31C370:01CC4B9E] Subject: [Roll] Agenda slightly Updated 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, 26 Jul 2011 14:15:18 -0000 Here it is: http://www.ietf.org/proceedings/81/agenda/roll.txt (same drafts, just a change in the ordering). Thanks, see you all. JP. From Daniel.Popa@itron.com Tue Jul 26 11:48: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 3CDDF21F8BEA for ; Tue, 26 Jul 2011 11:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 uq0H3vfPS+dq for ; Tue, 26 Jul 2011 11:48:17 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.116]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7D421F8BDA for ; Tue, 26 Jul 2011 11:48:17 -0700 (PDT) Received: from ITR-EXMBXVS-1.itron.com ([192.168.9.112]) by spo-exchcn-2.itron.com ([192.168.9.116]) with mapi; Tue, 26 Jul 2011 11:48:17 -0700 From: "Popa, Daniel" To: Philip Levis Date: Tue, 26 Jul 2011 11:48:16 -0700 Thread-Topic: [Roll] [ROLL] RPL applicability statement for AMI networks Thread-Index: AcxK6GM6nB9kzqomR6CjdsFiHseyqgA2ZG6Q Message-ID: <83027ECE5ECDC04E9BA5350B756A88E159933CC835@ITR-EXMBXVS-1.itron.com> References: <83027ECE5ECDC04E9BA5350B756A88E1599333F876@ITR-EXMBXVS-1.itron.com> <823F1D1D-3FF9-4907-B58C-5487644A6588@cs.stanford.edu> In-Reply-To: <823F1D1D-3FF9-4907-B58C-5487644A6588@cs.stanford.edu> 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] [ROLL] RPL applicability statement for AMI networks 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, 26 Jul 2011 18:48:18 -0000 Dear Phil,=20 I think that setting DIORedundancyConstant to a value of 10 or more is not = necessarily giving up of Trickle ability to suppress messages, while in the= same time being able to facilitate a significant reduction of transmission= s.=20 I believe you will agree that there is a tradeoff between the redundancy co= unt and how quickly one can find good paths. You will probably also agree t= hat the application space you have in mind when speaking about low communic= ation/energy cost is the battery powered devices. Or in AMI space, many (me= tering) devices are not energy constrained (being connected to the powerlin= e). =20 This being said, this is a typical feature we would to hear different opini= ons/feedbacks and so I thank you for your question. Regards,=20 Daniel > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Monday, July 25, 2011 12:32 PM > To: Popa, Daniel > Cc: roll@ietf.org > Subject: Re: [Roll] [ROLL] RPL applicability statement for AMI networks >=20 >=20 > On Jul 25, 2011, at 8:34 AM, Popa, Daniel wrote: >=20 > > draft-popa-roll-applicability-ami-00 >=20 > Daniel, >=20 > Can you explain the reasoning for this statement: >=20 > o AMI deployments SHOULD set DIORedundancyConstant to a value of 10 > or more. >=20 > This basically gives up one of the very valuable properties of Trickle, > its ability to scale well to high densities while maintaining a low > communication/energy cost. >=20 > Thanks! >=20 > Phil From pal@cs.stanford.edu Tue Jul 26 11:57: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 3743A21F86AF for ; Tue, 26 Jul 2011 11:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uc8zw84C23b for ; Tue, 26 Jul 2011 11:57:55 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id C3D7021F86AE for ; Tue, 26 Jul 2011 11:57:55 -0700 (PDT) Received: from dn522123.sunet ([10.33.4.67]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1QlmpG-0007P2-DC; Tue, 26 Jul 2011 11:57:54 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <83027ECE5ECDC04E9BA5350B756A88E159933CC835@ITR-EXMBXVS-1.itron.com> Date: Tue, 26 Jul 2011 11:57:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <83027ECE5ECDC04E9BA5350B756A88E1599333F876@ITR-EXMBXVS-1.itron.com> <823F1D1D-3FF9-4907-B58C-5487644A6588@cs.stanford.edu> <83027ECE5ECDC04E9BA5350B756A88E159933CC835@ITR-EXMBXVS-1.itron.com> To: "Popa, Daniel" X-Mailer: Apple Mail (2.1084) X-Scan-Signature: 993826b9125cbf1b907f71dc54053338 Cc: "roll@ietf.org" Subject: Re: [Roll] [ROLL] RPL applicability statement for AMI networks 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, 26 Jul 2011 18:57:56 -0000 On Jul 26, 2011, at 11:48 AM, Popa, Daniel wrote: > Dear Phil,=20 >=20 > I think that setting DIORedundancyConstant to a value of 10 or more is = not necessarily giving up of Trickle ability to suppress messages, while = in the same time being able to facilitate a significant reduction of = transmissions.=20 >=20 > I believe you will agree that there is a tradeoff between the = redundancy count and how quickly one can find good paths. You will = probably also agree that the application space you have in mind when = speaking about low communication/energy cost is the battery powered = devices. Or in AMI space, many (metering) devices are not energy = constrained (being connected to the powerline). =20 >=20 > This being said, this is a typical feature we would to hear different = opinions/feedbacks and so I thank you for your question. >=20 > Regards,=20 > Daniel My major concern is that this is a SHOULD on a magic constant which = doesn't really have any evidence behind it. Why 10? Why not 5? Why not = 20? In practice, I've seen a constant of 2 be sufficient to find good = paths. It might be that the first interval doesn't find the best path, = but since there are multiple intervals nodes do tend to reasonable ones = quickly and the best ones within a reasonable latency. The major issue is that as DIORedundancyConstant grows, so does the = minimum interval size. If you have a DIORedundancyConstant of 10, then = you need to pick a minimum interval size large enough to accommodate 10 = log(n) transmissions. This reduces the speed with which RPL can repair = problems in a sparse network. Phil From jramasas@silverspringnet.com Tue Jul 26 12: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 4E67321F8545 for ; Tue, 26 Jul 2011 12:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plPl3vtR6lGm for ; Tue, 26 Jul 2011 12:04:04 -0700 (PDT) Received: from it-ipcorp-01.silverspringnet.com (it-ipcorp-01.silverspringnet.com [74.121.22.25]) by ietfa.amsl.com (Postfix) with ESMTP id D5FCD21F84DE for ; Tue, 26 Jul 2011 12:04:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtQAAKgOL04KyAE+/2dsb2JhbAA1AQEBAQMBAQE9OgsMBQIBCQ0EBAEBAQogCQcUGAsYDggBAQMCAQ4IDJdpkFGJAMIbhWFfBIdXkECLBFc X-IronPort-AV: E=Sophos;i="4.67,270,1309762800"; d="scan'208";a="6231419" Received: from unknown (HELO IT-EXCA-02.silverspringnet.com) ([10.200.1.62]) by it-ipcorp-01.silverspringnet.com with ESMTP/TLS/AES128-SHA; 26 Jul 2011 12:04:04 -0700 Received: from IT-EXMB-01.silverspringnet.com ([fe80::b81e:2d5b:d263:6c44]) by IT-EXCA-02.silverspringnet.com ([::1]) with mapi; Tue, 26 Jul 2011 12:04:04 -0700 From: Jay Ramasastry To: "Popa, Daniel" , Philip Levis Date: Tue, 26 Jul 2011 12:04:03 -0700 Thread-Topic: [Roll] [ROLL] RPL applicability statement for AMI networks Thread-Index: AcxK6GM6nB9kzqomR6CjdsFiHseyqgA2ZG6QAAEgvCA= Message-ID: <625F39517869164ABE7DB2FFB4CA66A730B161E1@IT-EXMB-01.silverspringnet.com> References: <83027ECE5ECDC04E9BA5350B756A88E1599333F876@ITR-EXMBXVS-1.itron.com> <823F1D1D-3FF9-4907-B58C-5487644A6588@cs.stanford.edu> <83027ECE5ECDC04E9BA5350B756A88E159933CC835@ITR-EXMBXVS-1.itron.com> In-Reply-To: <83027ECE5ECDC04E9BA5350B756A88E159933CC835@ITR-EXMBXVS-1.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: "roll@ietf.org" Subject: Re: [Roll] [ROLL] RPL applicability statement for AMI networks 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, 26 Jul 2011 19:33:39 -0000 There are many other issues that influence the routing protocol for smart-g= rid wireless networks beyond that described in this ROLL contribution. Such= issues are being addressed at the IEEE802 and TIA. It is useful if this co= ntribution is referred to those for a rather than addressed in isolation. Jay R -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pop= a, Daniel Sent: Tuesday, July 26, 2011 11:48 AM To: Philip Levis Cc: roll@ietf.org Subject: Re: [Roll] [ROLL] RPL applicability statement for AMI networks Dear Phil,=20 I think that setting DIORedundancyConstant to a value of 10 or more is not = necessarily giving up of Trickle ability to suppress messages, while in the= same time being able to facilitate a significant reduction of transmission= s.=20 I believe you will agree that there is a tradeoff between the redundancy co= unt and how quickly one can find good paths. You will probably also agree t= hat the application space you have in mind when speaking about low communic= ation/energy cost is the battery powered devices. Or in AMI space, many (me= tering) devices are not energy constrained (being connected to the powerlin= e). =20 This being said, this is a typical feature we would to hear different opini= ons/feedbacks and so I thank you for your question. Regards, Daniel > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Monday, July 25, 2011 12:32 PM > To: Popa, Daniel > Cc: roll@ietf.org > Subject: Re: [Roll] [ROLL] RPL applicability statement for AMI=20 > networks >=20 >=20 > On Jul 25, 2011, at 8:34 AM, Popa, Daniel wrote: >=20 > > draft-popa-roll-applicability-ami-00 >=20 > Daniel, >=20 > Can you explain the reasoning for this statement: >=20 > o AMI deployments SHOULD set DIORedundancyConstant to a value of 10 > or more. >=20 > This basically gives up one of the very valuable properties of=20 > Trickle, its ability to scale well to high densities while maintaining=20 > a low communication/energy cost. >=20 > Thanks! >=20 > Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From Daniel.Popa@itron.com Tue Jul 26 12:34: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 DBB9711E80EF for ; Tue, 26 Jul 2011 12:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 lRj9YMWebkL2 for ; Tue, 26 Jul 2011 12:34:17 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.115]) by ietfa.amsl.com (Postfix) with ESMTP id 93C3511E80D9 for ; Tue, 26 Jul 2011 12:34:15 -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, 26 Jul 2011 12:34:15 -0700 From: "Popa, Daniel" To: Philip Levis Date: Tue, 26 Jul 2011 12:34:15 -0700 Thread-Topic: [Roll] [ROLL] RPL applicability statement for AMI networks Thread-Index: AcxLxe/gNp/SWEyCQMWYY4KNYssTfAAA7uSg Message-ID: <83027ECE5ECDC04E9BA5350B756A88E159933CC848@ITR-EXMBXVS-1.itron.com> References: <83027ECE5ECDC04E9BA5350B756A88E1599333F876@ITR-EXMBXVS-1.itron.com> <823F1D1D-3FF9-4907-B58C-5487644A6588@cs.stanford.edu> <83027ECE5ECDC04E9BA5350B756A88E159933CC835@ITR-EXMBXVS-1.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: "roll@ietf.org" Subject: Re: [Roll] [ROLL] RPL applicability statement for AMI networks 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, 26 Jul 2011 19:34:18 -0000 Phil, > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Tuesday, July 26, 2011 2:58 PM > To: Popa, Daniel > Cc: roll@ietf.org > Subject: Re: [Roll] [ROLL] RPL applicability statement for AMI networks >=20 >=20 > On Jul 26, 2011, at 11:48 AM, Popa, Daniel wrote: >=20 > > Dear Phil, > > > > I think that setting DIORedundancyConstant to a value of 10 or more > is not necessarily giving up of Trickle ability to suppress messages, > while in the same time being able to facilitate a significant reduction > of transmissions. > > > > I believe you will agree that there is a tradeoff between the > redundancy count and how quickly one can find good paths. You will > probably also agree that the application space you have in mind when > speaking about low communication/energy cost is the battery powered > devices. Or in AMI space, many (metering) devices are not energy > constrained (being connected to the powerline). > > > > This being said, this is a typical feature we would to hear different > opinions/feedbacks and so I thank you for your question. > > > > Regards, > > Daniel >=20 > My major concern is that this is a SHOULD on a magic constant which > doesn't really have any evidence behind it. Why 10? Why not 5? Why not > 20?=20 DP> You have a good point! Why 2 is better than 10, or 5, or 20? Let explor= e and see what is the "best" value. >In practice, I've seen a constant of 2 be sufficient to find good =20 > paths. It might be that the first interval doesn't find the best path, > but since there are multiple intervals nodes do tend to reasonable ones > quickly and the best ones within a reasonable latency. DP> I see.... Can you PLS provide details on simulations/deployments that a= llowed you to conclude that that a constant of 2 is sufficient (or better t= han...)? > The major issue is that as DIORedundancyConstant grows, so does the > minimum interval size. If you have a DIORedundancyConstant of 10, then > you need to pick a minimum interval size large enough to accommodate 10 > log(n) transmissions. This reduces the speed with which RPL can repair > problems in a sparse network. DP> A trade-off should be find but without giving bigger advantage to one s= cenario (e.g., sparse) over another. > Phil >=20 From Daniel.Popa@itron.com Tue Jul 26 12:37: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 DC7DB11E8082 for ; Tue, 26 Jul 2011 12:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 YKN+eLnH79CR for ; Tue, 26 Jul 2011 12:37:39 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.115]) by ietfa.amsl.com (Postfix) with ESMTP id 4730A11E8088 for ; Tue, 26 Jul 2011 12:37:39 -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, 26 Jul 2011 12:37:39 -0700 From: "Popa, Daniel" To: Jay Ramasastry Date: Tue, 26 Jul 2011 12:37:40 -0700 Thread-Topic: [Roll] [ROLL] RPL applicability statement for AMI networks Thread-Index: AcxK6GM6nB9kzqomR6CjdsFiHseyqgA2ZG6QAAEgvCAAAS1hEA== Message-ID: <83027ECE5ECDC04E9BA5350B756A88E159933CC84B@ITR-EXMBXVS-1.itron.com> References: <83027ECE5ECDC04E9BA5350B756A88E1599333F876@ITR-EXMBXVS-1.itron.com> <823F1D1D-3FF9-4907-B58C-5487644A6588@cs.stanford.edu> <83027ECE5ECDC04E9BA5350B756A88E159933CC835@ITR-EXMBXVS-1.itron.com> <625F39517869164ABE7DB2FFB4CA66A730B161E1@IT-EXMB-01.silverspringnet.com> In-Reply-To: <625F39517869164ABE7DB2FFB4CA66A730B161E1@IT-EXMB-01.silverspringnet.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: "roll@ietf.org" Subject: Re: [Roll] [ROLL] RPL applicability statement for AMI networks 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, 26 Jul 2011 19:37:40 -0000 Hi Jay,=20 Thank you for your feedback.=20 Can you please point us to the documents you mention? Daniel =20 > -----Original Message----- > From: Jay Ramasastry [mailto:jramasas@silverspringnet.com] > Sent: Tuesday, July 26, 2011 3:04 PM > To: Popa, Daniel; Philip Levis > Cc: roll@ietf.org > Subject: RE: [Roll] [ROLL] RPL applicability statement for AMI networks >=20 > There are many other issues that influence the routing protocol for > smart-grid wireless networks beyond that described in this ROLL > contribution. Such issues are being addressed at the IEEE802 and TIA. > It is useful if this contribution is referred to those for a rather > than addressed in isolation. >=20 > Jay R >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Popa, Daniel > Sent: Tuesday, July 26, 2011 11:48 AM > To: Philip Levis > Cc: roll@ietf.org > Subject: Re: [Roll] [ROLL] RPL applicability statement for AMI networks >=20 > Dear Phil, >=20 > I think that setting DIORedundancyConstant to a value of 10 or more is > not necessarily giving up of Trickle ability to suppress messages, > while in the same time being able to facilitate a significant reduction > of transmissions. >=20 > I believe you will agree that there is a tradeoff between the > redundancy count and how quickly one can find good paths. You will > probably also agree that the application space you have in mind when > speaking about low communication/energy cost is the battery powered > devices. Or in AMI space, many (metering) devices are not energy > constrained (being connected to the powerline). >=20 > This being said, this is a typical feature we would to hear different > opinions/feedbacks and so I thank you for your question. >=20 > Regards, > Daniel >=20 > > -----Original Message----- > > From: Philip Levis [mailto:pal@cs.stanford.edu] > > Sent: Monday, July 25, 2011 12:32 PM > > To: Popa, Daniel > > Cc: roll@ietf.org > > Subject: Re: [Roll] [ROLL] RPL applicability statement for AMI > > networks > > > > > > On Jul 25, 2011, at 8:34 AM, Popa, Daniel wrote: > > > > > draft-popa-roll-applicability-ami-00 > > > > Daniel, > > > > Can you explain the reasoning for this statement: > > > > o AMI deployments SHOULD set DIORedundancyConstant to a value of > 10 > > or more. > > > > This basically gives up one of the very valuable properties of > > Trickle, its ability to scale well to high densities while > maintaining > > a low communication/energy cost. > > > > Thanks! > > > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=18158567c=Roger.Alexander@cooperindustries.com Tue Jul 26 14:54: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 B829D11E80B9 for ; Tue, 26 Jul 2011 14:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-OGMxkgMuq6 for ; Tue, 26 Jul 2011 14:54:31 -0700 (PDT) Received: from cooperlighting-sw.cooperlighting.com (cooperlighting-sw.cooperlighting.com [216.130.131.68]) by ietfa.amsl.com (Postfix) with ESMTP id 14CD511E80B7 for ; Tue, 26 Jul 2011 14:54:30 -0700 (PDT) Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.65,600,1304308800"; d="scan'208";a="19459532" Received: from cipt0174.nam.ci.root ([10.132.108.174]) by cooperlighting-sw.cooperlighting.com with ESMTP; 26 Jul 2011 17:54:29 -0400 Received: from EVS4.NAM.CI.ROOT ([10.132.108.172]) by cipt0174.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 17:54:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Tue, 26 Jul 2011 17:53:30 -0400 Message-ID: <9BB070DB2D281946859EA89837931EEE0196F057@EVS4.nam.ci.root> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification fordraft-alexander-roll-mikey-lln-key-mgmt-02.txt thread-index: AcxL2yUh/kWVgGOQTQ6PjfDizEWFlwAAAlKg From: "Alexander, Roger" To: X-OriginalArrivalTime: 26 Jul 2011 21:54:29.0396 (UTC) FILETIME=[98200540:01CC4BDE] Cc: "Tsao, Tzeta" Subject: [Roll] FW: New Version Notification fordraft-alexander-roll-mikey-lln-key-mgmt-02.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, 26 Jul 2011 21:54:31 -0000 RGVhciBXRywNCg0KQW4gdXBkYXRlIG9mIHRoZSBrZXkgbWFuYWdlbWVudCBJLUQgaXMgYXZhaWxh YmxlIGF0IHRoZSBVUkwgYmVsb3cuIFRoZSBpbnRyb2R1Y2VkIOKAnEFNSUtFWSBLZXkgTWFuYWdl bWVudCBTaWduYWxpbmfigJ0gc2VjdGlvbiAoMy4sIHBwLjE0IC0gMTcpIHN1bW1hcml6ZXMgdGhl IGNlbnRyYWwgZWxlbWVudHMgb2YgdGhlIHByb3Bvc2VkIGtleSBtYW5hZ2VtZW50IGV4dGVuc2lv biAoaW5jbHVkaW5nIGluY29ycG9yYXRpb24gb2YgYSDigJhSZXF1ZXN0b3LigJkgbWVzc2FnZSB0 aGF0IGFkZHJlc3NlcyB0aGUgUlBMIHJlcXVpcmVtZW50IGZvciBub2RlLXJlcXVlc3RlZCBrZXkg YXNzaWdubWVudCkuIA0KDQpEbyB0YWtlIHRoZSBvcHBvcnR1bml0eSB0byBzY2FuIG9yIHJldmll dyB0aGVzZSBmZXcgcGFnZXMgdG8gZ2V0IGFuIG92ZXJhbGwgdW5kZXJzdGFuZGluZyBvZiB0aGUg cHJvcG9zYWwgdGhhdCB3aWxsIGJlIGRpc2N1c3NlZCBkdXJpbmcgRnJpZGF54oCZcyBXRyBzZXNz aW9uLg0KDQpUaGFua3MsDQoNClJvZ2VyDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWFsZXhhbmRlci1yb2xsLW1pa2V5LWxsbi1rZXktbWdtdC8NCg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWls dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFR1ZXNkYXksIEp1bHkgMjYsIDIw MTEgNTozMCBQTQ0KVG86IEFsZXhhbmRlciwgUm9nZXINCkNjOiBBbGV4YW5kZXIsIFJvZ2VyOyBU c2FvLCBUemV0YQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcmRyYWZ0LWFs ZXhhbmRlci1yb2xsLW1pa2V5LWxsbi1rZXktbWdtdC0wMi50eHQNCg0KQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LWFsZXhhbmRlci1yb2xsLW1pa2V5LWxsbi1rZXktbWdtdC0wMi50eHQgaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBSb2dlciBBbGV4YW5kZXIgYW5kIHBvc3Rl ZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWFsZXhhbmRlci1y b2xsLW1pa2V5LWxsbi1rZXktbWdtdA0KUmV2aXNpb246CSAwMg0KVGl0bGU6CQkgQWRhcHRlZCBN dWx0aW1lZGlhIEludGVybmV0IEtFWWluZyAoQU1JS0VZKTogQW4gZXh0ZW5zaW9uIG9mIE11bHRp bWVkaWEgSW50ZXJuZXQgS0VZaW5nIChNSUtFWSkgTWV0aG9kcyBmb3IgR2VuZXJpYyBMTE4gRW52 aXJvbm1lbnRzDQpDcmVhdGlvbiBkYXRlOgkgMjAxMS0wNy0yNg0KV0cgSUQ6CQkgSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDM2DQoNCkFic3RyYWN0Og0KICAgTXVsdGlt ZWRpYSBJbnRlcm5ldCBLZXlpbmcgKE1JS0VZKSBpcyBhIGtleSBtYW5hZ2VtZW50IHByb3RvY29s IHVzZWQNCiAgIGZvciByZWFsLXRpbWUgYXBwbGljYXRpb25zLiAgQXMgc3RhbmRhcmRpemVkIHdp dGhpbiBSRkMzODMwIGl0DQogICBkZWZpbmVzIGZvdXIga2V5IGRpc3RyaWJ1dGlvbiBtZXRob2Rz LCBpbmNsdWRpbmcgcHJlLXNoYXJlZCBrZXlzLA0KICAgcHVibGljLWtleSBlbmNyeXB0aW9uLCBh bmQgRGlmZmllLUhlbGxtYW4ga2V5IGV4Y2hhbmdlLCB3aXRoDQogICBhbGxvd2FuY2VzIGZvciBy ZWFkeSBwcm90b2NvbCBleHRlbnNpb24uICBBIG51bWJlciBvZiBhZGRpdGlvbmFsDQogICBtZXRo b2RzIGhhdmUgYmVlbiBkZXZlbG9wZWQgYW5kIGNvbnRpbnVlIHRvIGJlIGJ1aWx0IGZyb20gdGhl IGJhc2UNCiAgIHByb3RvY29sIChzZWUgZm9yIGV4YW1wbGUsIFJGQzQ0NDIsIFJGQzQ1NjMsIFJG QzQ2NTAsIFJGQzQ3MzgsDQogICBSRkM1NDEwLCBSRkM2MDQzIGFuZCBSRkM2MjY3LiAgSG93ZXZl ciwgaW4gc3BpdGUgb2YgaXRzIGV4dGVuc2liaWxpdHkNCiAgIGFuZCBtb3JlIGdlbmVyYWwgYXBw bGljYWJpbGl0eSwgTUlLRVkgYW5kIGl0cyByZWxhdGVkIGV4dGVuc2lvbnMgaGF2ZQ0KICAgcHJp bWFyaWx5IGZvY3VzZWQgb24gdGhlIHN1cHBvcnQgb2YgdGhlIFNlY3VyZSBSZWFsLXRpbWUgVHJh bnNwb3J0DQogICBQcm90b2NvbCAoU1JUUCkuDQoNCiAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVz IGEgc2ltcGxlIGFkYXB0YXRpb24gb2YgdGhlIE1JS0VZDQogICBzcGVjaWZpY2F0aW9uIHRvIGFs bG93IHRoZSBiYXNlIHByb3RvY29sIGFuZCBpdHMgdmFyaW91cyBrZXkNCiAgIG1hbmFnZW1lbnQg bW9kZSBleHRlbnNpb25zIHRvIGJlIHJlYWRpbHkgYXBwbGllZCBpbiBtb3JlIGdlbmVyYWwNCiAg IGVudmlyb25tZW50cyBiZXlvbmQgdGhlIG11bHRpbWVkaWEgU1JUUCBkb21haW4uICBJbiBwYXJ0 aWN1bGFyLCB0aGUNCiAgIGRvY3VtZW50IGRlZmluZXMgYSByZXB1cnBvc2luZyBvZiB0aGUgTUlL RVkgbXVsdGltZWRpYSBjcnlwdG8NCiAgIHNlc3Npb25zIHN0cnVjdHVyZSBhbmQgaW50cm9kdWNl cyBhIHNldCBvZiBtZXNzYWdlIGV4dGVuc2lvbnMgdG8gdGhlDQogICBiYXNlIHNwZWNpZmljYXRp b24gdG8gYWxsb3cgdGhlIE1JS0VZIGtleSBtYW5hZ2VtZW50IG1ldGhvZHMgdG8gYmUNCiAgIGFw cGxpZWQgd2l0aGluIExvdy1wb3dlciBhbmQgTG9zc3kgbmV0d29ya3MgKExMTnMpIGFuZCBvdGhl ciBnZW5lcmFsDQogICBjb25zdHJhaW5lZC1kZXZpY2UgbmV0d29ya3MuDQoNCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQo= From pal@cs.stanford.edu Tue Jul 26 15:08: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 9187621F86CA for ; Tue, 26 Jul 2011 15:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GBKH201sOsh for ; Tue, 26 Jul 2011 15:08:53 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs3.Stanford.EDU [171.64.64.27]) by ietfa.amsl.com (Postfix) with ESMTP id A683721F86AF for ; Tue, 26 Jul 2011 15:08:53 -0700 (PDT) Received: from dn0a2100ef.sunet ([10.33.0.239]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Qlpo0-0007SN-K3; Tue, 26 Jul 2011 15:08:48 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <83027ECE5ECDC04E9BA5350B756A88E159933CC848@ITR-EXMBXVS-1.itron.com> Date: Tue, 26 Jul 2011 15:08:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <89C633A5-6A3A-4A7E-A586-DA679B570D49@cs.stanford.edu> References: <83027ECE5ECDC04E9BA5350B756A88E1599333F876@ITR-EXMBXVS-1.itron.com> <823F1D1D-3FF9-4907-B58C-5487644A6588@cs.stanford.edu> <83027ECE5ECDC04E9BA5350B756A88E159933CC835@ITR-EXMBXVS-1.itron.com> <83027ECE5ECDC04E9BA5350B756A88E159933CC848@ITR-EXMBXVS-1.itron.com> To: "Popa, Daniel" X-Mailer: Apple Mail (2.1084) X-Scan-Signature: daeb03f1a6494d8fe08e106a714ef916 Cc: "roll@ietf.org" Subject: Re: [Roll] [ROLL] RPL applicability statement for AMI networks 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, 26 Jul 2011 22:08:54 -0000 On Jul 26, 2011, at 12:34 PM, Popa, Daniel wrote: > Phil, >=20 >=20 >> -----Original Message----- >> From: Philip Levis [mailto:pal@cs.stanford.edu] >> Sent: Tuesday, July 26, 2011 2:58 PM >> To: Popa, Daniel >> Cc: roll@ietf.org >> Subject: Re: [Roll] [ROLL] RPL applicability statement for AMI = networks >>=20 >>=20 >> On Jul 26, 2011, at 11:48 AM, Popa, Daniel wrote: >>=20 >>> Dear Phil, >>>=20 >>> I think that setting DIORedundancyConstant to a value of 10 or more >> is not necessarily giving up of Trickle ability to suppress messages, >> while in the same time being able to facilitate a significant = reduction >> of transmissions. >>>=20 >>> I believe you will agree that there is a tradeoff between the >> redundancy count and how quickly one can find good paths. You will >> probably also agree that the application space you have in mind when >> speaking about low communication/energy cost is the battery powered >> devices. Or in AMI space, many (metering) devices are not energy >> constrained (being connected to the powerline). >>>=20 >>> This being said, this is a typical feature we would to hear = different >> opinions/feedbacks and so I thank you for your question. >>>=20 >>> Regards, >>> Daniel >>=20 >> My major concern is that this is a SHOULD on a magic constant which >> doesn't really have any evidence behind it. Why 10? Why not 5? Why = not >> 20?=20 >=20 > DP> You have a good point! Why 2 is better than 10, or 5, or 20? Let = explore and see what is the "best" value. Sure. Just trying to point out some of these experiments have been done, = and the results have been posted to this list by Om on April 29, 2010 = (link below). >=20 >> In practice, I've seen a constant of 2 be sufficient to find good =20 >> paths. It might be that the first interval doesn't find the best = path, >> but since there are multiple intervals nodes do tend to reasonable = ones >> quickly and the best ones within a reasonable latency. >=20 > DP> I see.... Can you PLS provide details on simulations/deployments = that allowed you to conclude that that a constant of 2 is sufficient (or = better than...)? General conclusion: setting a k=3D10 (DIORedundancyConstant=3D10) = increases control overhead but does not improve path quality: http://stuff.stanford.edu/~om_p/ctp/beaconsuppression.html The way to think of it is this: what's important is that a node find a = "usable" route almost immediately, a "reasonable" route quickly, and = something within an epsilon of the best route within a reasonable time = frame. Because Trickle is a continuous process, this is what generally = happens. By accepting the eventual nature of the algorithm and its use = in routing maintenance, you can find routes faster yet still converge to = near-optimal routes pretty quickly. The tiny overhead in that "lost" = optimality over a couple of Trickle intervals really is in the noise. Phil From jonhui@cisco.com Tue Jul 26 15:36: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 E4D6C5E800F for ; Tue, 26 Jul 2011 15:36: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 pAptDQMKwGAc for ; Tue, 26 Jul 2011 15:36:43 -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 18C7A5E8008 for ; Tue, 26 Jul 2011 15:36:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=2048; q=dns/txt; s=iport; t=1311719803; x=1312929403; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=wYi3jIaP+nYIFa1Fa1wKrvpFlPMigPW2ELeknbeJ+ng=; b=ZhL9pa8tUGZulLe6BsMqLAqc8ThkvfGf2PhbjIWl4sU27RbQyhovgCca meh70QjWIcNldxf6uch8GohTqjus5x1l4vHBXFNrcw/zbw88+qHgRWskk VfL1pDg1hRlujP80RGw7yOSmuGeeZvC6vBiw7lEehTPEKvXo3utevstzM o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHhAL06rRDoI/2dsb2JhbAA1AQEBAQIBFAErRQUMDA5EFFEFAhwipyp3iHwEoyWeVIVhXwSHV4sbkClX X-IronPort-AV: E=Sophos;i="4.67,272,1309737600"; d="scan'208";a="6682432" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-8.cisco.com with ESMTP; 26 Jul 2011 22:36:42 +0000 Received: from dhcp-128-107-155-204.cisco.com (dhcp-128-107-155-204.cisco.com [128.107.155.204]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6QMaf42001050; Tue, 26 Jul 2011 22:36:41 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: <89C633A5-6A3A-4A7E-A586-DA679B570D49@cs.stanford.edu> Date: Tue, 26 Jul 2011 15:36:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2EDD5973-0D87-4020-978A-0DC405E3772F@cisco.com> References: <83027ECE5ECDC04E9BA5350B756A88E1599333F876@ITR-EXMBXVS-1.itron.com> <823F1D1D-3FF9-4907-B58C-5487644A6588@cs.stanford.edu> <83027ECE5ECDC04E9BA5350B756A88E159933CC835@ITR-EXMBXVS-1.itron.com> <83027ECE5ECDC04E9BA5350B756A88E159933CC848@ITR-EXMBXVS-1.itron.com> <89C633A5-6A3A-4A7E-A586-DA679B570D49@cs.stanford.edu> To: Philip Levis X-Mailer: Apple Mail (2.1084) Cc: "roll@ietf.org" Subject: Re: [Roll] [ROLL] RPL applicability statement for AMI networks 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, 26 Jul 2011 22:36:44 -0000 On Jul 26, 2011, at 3:08 PM, Philip Levis wrote: > General conclusion: setting a k=3D10 (DIORedundancyConstant=3D10) = increases control overhead but does not improve path quality: >=20 > http://stuff.stanford.edu/~om_p/ctp/beaconsuppression.html >=20 > The way to think of it is this: what's important is that a node find a = "usable" route almost immediately, a "reasonable" route quickly, and = something within an epsilon of the best route within a reasonable time = frame. Because Trickle is a continuous process, this is what generally = happens. By accepting the eventual nature of the algorithm and its use = in routing maintenance, you can find routes faster yet still converge to = near-optimal routes pretty quickly. The tiny overhead in that "lost" = optimality over a couple of Trickle intervals really is in the noise. Phil, Om's results seem to focus on networks that are relatively sparse = compared to what we have in mind. Could you provide some insight into = how dense these testbeds are under the different setups? We are dealing with networks where nodes can have order hundreds of = neighbors (yes, a single node can have more neighbors than all nodes in = Tutornet and Motelab combined). =46rom our experiments, increasing the = min interval helps deal with increased density because it reduces the = likelihood of collisions. Of course, the side effect of that is that = the overall responsiveness of the protocol becomes slower. To find good = routes within a reasonable time scale, it also helps to increase the = redundancy constant. Note that a value of 10 still allows significant = suppression ratios when the density is high. I recognize that the Trickle parameters will vary for different = deployment scenarios (sparse vs. dense, energy-constrained vs. = mains-powered, etc) and application requirements (capacity allocated to = control traffic, response time, etc.). The draft does not currently = provide any discussion on that but should. -- Jonathan Hui From cardenas@fla.fujitsu.com Tue Jul 26 15:43: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 E4C4611E80C0 for ; Tue, 26 Jul 2011 15:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 2FNDb1VHQbEC for ; Tue, 26 Jul 2011 15:43:38 -0700 (PDT) Received: from fujitsu25.fnanic.fujitsu.com (fujitsu25.fnanic.fujitsu.com [192.240.6.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5221411E80BD for ; Tue, 26 Jul 2011 15:43:38 -0700 (PDT) Received: from pps.filterd (fujitsu25 [127.0.0.1]) by fujitsu25.fnanic.fujitsu.com (8.14.4/8.14.4) with SMTP id p6QMfGWa013703; Tue, 26 Jul 2011 15:43:37 -0700 Received: from fujitsuii.fna.fujitsu.com ([133.164.253.2]) by fujitsu25.fnanic.fujitsu.com with ESMTP id xsy1qrav1-1; Tue, 26 Jul 2011 15:43:37 -0700 Received: from toyama.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsuii.fna.fujitsu.com (8.13.8/8.13.8) with ESMTP id p6QMhbo0028165; Tue, 26 Jul 2011 15:43:37 -0700 (PDT) Received: from [10.157.253.31] (localhost [127.0.0.1]) by toyama.fla.fujitsu.com (8.11.6+Sun/8.11.6) with ESMTP id p6QMhaJ26697; Tue, 26 Jul 2011 15:43:36 -0700 (PDT) Message-ID: <4E2F4318.4090709@fla.fujitsu.com> Date: Tue, 26 Jul 2011 15:43:36 -0700 From: "Alvaro A. Cardenas" User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Jonathan Hui References: <83027ECE5ECDC04E9BA5350B756A88E1599333F876@ITR-EXMBXVS-1.itron.com> <823F1D1D-3FF9-4907-B58C-5487644A6588@cs.stanford.edu> <83027ECE5ECDC04E9BA5350B756A88E159933CC835@ITR-EXMBXVS-1.itron.com> <83027ECE5ECDC04E9BA5350B756A88E159933CC848@ITR-EXMBXVS-1.itron.com> <89C633A5-6A3A-4A7E-A586-DA679B570D49@cs.stanford.edu> <2EDD5973-0D87-4020-978A-0DC405E3772F@cisco.com> In-Reply-To: <2EDD5973-0D87-4020-978A-0DC405E3772F@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-07-26_07:2011-07-27, 2011-07-26, 1970-01-01 signatures=0 Cc: "roll@ietf.org" Subject: Re: [Roll] [ROLL] RPL applicability statement for AMI networks 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, 26 Jul 2011 22:43:39 -0000 Jonathan, > We are dealing with networks where nodes can have order hundreds of neighbors (yes, a single node can have more neighbors than all nodes in Tutornet and Motelab combined). From our experiments, increasing the min interval helps deal with increased There has been a lot of work regarding the density of AMI networks in the Priority Action Plan 2 (PAP 2) of the SGIP (and also the Open SG networking groups) and several considerations for rural, suburban and urban environments under different PHY layers and power used for reception and transmission. Is the draft taking into consideration this work and how the parameters will change depending on the specific deployment? Regards, Alvaro > density because it reduces the likelihood of collisions. Of course, the side effect of that is that the overall responsiveness of the protocol becomes slower. To find good routes within a reasonable time scale, it also helps to increase the redundancy constant. Note that a value of 10 still allows significant suppression ratios when the density is high. > > I recognize that the Trickle parameters will vary for different deployment scenarios (sparse vs. dense, energy-constrained vs. mains-powered, etc) and application requirements (capacity allocated to control traffic, response time, etc.). The draft does not currently provide any discussion on that but should. > > -- > Jonathan Hui > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From Daniel.Popa@itron.com Tue Jul 26 17:11: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 5234021F8591 for ; Tue, 26 Jul 2011 17:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 JN+RnhNKh6h0 for ; Tue, 26 Jul 2011 17:11:39 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.116]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB0B21F8581 for ; Tue, 26 Jul 2011 17:11:39 -0700 (PDT) Received: from ITR-EXMBXVS-1.itron.com ([192.168.9.112]) by spo-exchcn-2.itron.com ([192.168.9.116]) with mapi; Tue, 26 Jul 2011 17:11:39 -0700 From: "Popa, Daniel" To: "Alvaro A. Cardenas" Date: Tue, 26 Jul 2011 17:11:40 -0700 Thread-Topic: [Roll] [ROLL] RPL applicability statement for AMI networks Thread-Index: AcxL5XnQKgeAzNekTMWgdEZnN6n0PwAC76ag Message-ID: <83027ECE5ECDC04E9BA5350B756A88E159933CC89A@ITR-EXMBXVS-1.itron.com> References: <83027ECE5ECDC04E9BA5350B756A88E1599333F876@ITR-EXMBXVS-1.itron.com> <823F1D1D-3FF9-4907-B58C-5487644A6588@cs.stanford.edu> <83027ECE5ECDC04E9BA5350B756A88E159933CC835@ITR-EXMBXVS-1.itron.com> <83027ECE5ECDC04E9BA5350B756A88E159933CC848@ITR-EXMBXVS-1.itron.com> <89C633A5-6A3A-4A7E-A586-DA679B570D49@cs.stanford.edu> <2EDD5973-0D87-4020-978A-0DC405E3772F@cisco.com> <4E2F4318.4090709@fla.fujitsu.com> In-Reply-To: <4E2F4318.4090709@fla.fujitsu.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: "roll@ietf.org" Subject: Re: [Roll] [ROLL] RPL applicability statement for AMI networks 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, 27 Jul 2011 00:11:40 -0000 Alvaro,=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Alvaro A. Cardenas > Sent: Tuesday, July 26, 2011 6:44 PM > To: Jonathan Hui > Cc: roll@ietf.org > Subject: Re: [Roll] [ROLL] RPL applicability statement for AMI networks >=20 > Jonathan, >=20 > > We are dealing with networks where nodes can have order hundreds of > neighbors (yes, a single node can have more neighbors than all nodes in > Tutornet and Motelab combined). From our experiments, increasing the > min interval helps deal with increased > There has been a lot of work regarding the density of AMI networks in > the Priority Action Plan 2 (PAP 2) of the SGIP (and also the Open SG > networking groups) and several considerations for rural, suburban and > urban environments under different PHY layers and power used for > reception and transmission. Is the draft taking into consideration > this > work and how the parameters will change depending on the specific > deployment? Can you be more specific PLS and point us to some documents? A lot of work = has been done within PAP2, SGIP or OpenSG=20 on wireless PHY and MAC performance versus channel characteristics & densit= y. > Regards, > Alvaro >=20 > > density because it reduces the likelihood of collisions. Of course, > the side effect of that is that the overall responsiveness of the > protocol becomes slower. To find good routes within a reasonable time > scale, it also helps to increase the redundancy constant. Note that a > value of 10 still allows significant suppression ratios when the > density is high. > > > > I recognize that the Trickle parameters will vary for different > deployment scenarios (sparse vs. dense, energy-constrained vs. mains- > powered, etc) and application requirements (capacity allocated to > control traffic, response time, etc.). The draft does not currently > provide any discussion on that but should. > > > > -- > > Jonathan Hui > > > > _______________________________________________ > > 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 pal@cs.stanford.edu Tue Jul 26 17:40: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 53B815E8015 for ; Tue, 26 Jul 2011 17:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYH8zekoz0z2 for ; Tue, 26 Jul 2011 17:40:03 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id A52B45E8008 for ; Tue, 26 Jul 2011 17:40:03 -0700 (PDT) Received: from dn52218r.sunet ([10.33.5.27]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1QlsAM-0005jU-I9; Tue, 26 Jul 2011 17:40:02 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <2EDD5973-0D87-4020-978A-0DC405E3772F@cisco.com> Date: Tue, 26 Jul 2011 17:40:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <83027ECE5ECDC04E9BA5350B756A88E1599333F876@ITR-EXMBXVS-1.itron.com> <823F1D1D-3FF9-4907-B58C-5487644A6588@cs.stanford.edu> <83027ECE5ECDC04E9BA5350B756A88E159933CC835@ITR-EXMBXVS-1.itron.com> <83027ECE5ECDC04E9BA5350B756A88E159933CC848@ITR-EXMBXVS-1.itron.com> <89C633A5-6A3A-4A7E-A586-DA679B570D49@cs.stanford.edu> <2EDD5973-0D87-4020-978A-0DC405E3772F@cisco.com> To: Jonathan Hui X-Mailer: Apple Mail (2.1084) X-Scan-Signature: 2c21b60125577a2cbf52524016395bed Cc: "roll@ietf.org" Subject: Re: [Roll] [ROLL] RPL applicability statement for AMI networks 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, 27 Jul 2011 00:40:04 -0000 On Jul 26, 2011, at 3:36 PM, Jonathan Hui wrote: >=20 > On Jul 26, 2011, at 3:08 PM, Philip Levis wrote: >=20 >> General conclusion: setting a k=3D10 (DIORedundancyConstant=3D10) = increases control overhead but does not improve path quality: >>=20 >> http://stuff.stanford.edu/~om_p/ctp/beaconsuppression.html >>=20 >> The way to think of it is this: what's important is that a node find = a "usable" route almost immediately, a "reasonable" route quickly, and = something within an epsilon of the best route within a reasonable time = frame. Because Trickle is a continuous process, this is what generally = happens. By accepting the eventual nature of the algorithm and its use = in routing maintenance, you can find routes faster yet still converge to = near-optimal routes pretty quickly. The tiny overhead in that "lost" = optimality over a couple of Trickle intervals really is in the noise. >=20 >=20 > Phil, >=20 > Om's results seem to focus on networks that are relatively sparse = compared to what we have in mind. Could you provide some insight into = how dense these testbeds are under the different setups? >=20 > We are dealing with networks where nodes can have order hundreds of = neighbors (yes, a single node can have more neighbors than all nodes in = Tutornet and Motelab combined). =46rom our experiments, increasing the = min interval helps deal with increased density because it reduces the = likelihood of collisions. Of course, the side effect of that is that = the overall responsiveness of the protocol becomes slower. To find good = routes within a reasonable time scale, it also helps to increase the = redundancy constant. Note that a value of 10 still allows significant = suppression ratios when the density is high. >=20 > I recognize that the Trickle parameters will vary for different = deployment scenarios (sparse vs. dense, energy-constrained vs. = mains-powered, etc) and application requirements (capacity allocated to = control traffic, response time, etc.). The draft does not currently = provide any discussion on that but should. Let me try to summarize, please tell me if/how I'm wrong: in very dense = AMI deployments, MAC collisions on short intervals are a real problem, = so you need significant additional random backoff from a higher layer to = avoid these collisions.=20 If this is the case, then I'd recommend describing this as a more = conservative value than what is specified in 6.6 of RFC6206. I.e., AMI = networks have super-high density, so recommend that Imin be XX times the = packet transmission time, and use a larger k to increase the = communication rate.=20 It's useful to note that, in the case of synchronized intervals, these k = may be clustered early in the interval. So you can have bursts of = control traffic. Phil From Jorjeta.Jetcheva@itron.com Wed Jul 27 07:05:02 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 EFF7121F86EA for ; Wed, 27 Jul 2011 07:05:01 -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 H8FEYtUE9Tiv for ; Wed, 27 Jul 2011 07:05:00 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.116]) by ietfa.amsl.com (Postfix) with ESMTP id CBCF721F86DE for ; Wed, 27 Jul 2011 07:05:00 -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, 27 Jul 2011 07:05:00 -0700 From: "Jetcheva, Jorjeta" To: "roll@ietf.org" Date: Wed, 27 Jul 2011 07:05:05 -0700 Thread-Topic: [Roll] [ROLL] RPL applicability statement for AMI networks Thread-Index: AcxL5XnQKgeAzNekTMWgdEZnN6n0PwAC76agAAs5DCAAEV1JQAAARwtQ Message-ID: <0368F388C03BB34BBBFA73209849D47A4BDA8739@ITR-EXMBXVS-2.itron.com> References: <83027ECE5ECDC04E9BA5350B756A88E1599341E1C5@ITR-EXMBXVS-1.itron.com> In-Reply-To: <83027ECE5ECDC04E9BA5350B756A88E1599341E1C5@ITR-EXMBXVS-1.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 Subject: Re: [Roll] [ROLL] RPL applicability statement for AMI networks 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, 27 Jul 2011 14:05:02 -0000 Hi Alvaro, We are aware of the PAP2 work. The AMI applicability draft does talk about= the wide range of network densities that are possible (see Section 1.1 for= example). =20 Jorjeta > -----Original Message----- > From: Alvaro A. Cardenas [mailto:alvaro.cardenas-mora@us.fujitsu.com] > Sent: Wednesday, July 27, 2011 1:51 AM > To: Popa, Daniel > Cc: roll@ietf.org; 'Jonathan Hui' > Subject: RE: [Roll] [ROLL] RPL applicability statement for AMI networks >=20 > Hi Daniel, >=20 > I am talking about the main (only?) document of PAP2: NIST-IR 7761. > There > are many examples where the average number of neighbors can range > between a > dozen or so for rural deployments to thousands of nodes (depending on > the > transmission and reception power). >=20 > http://collaborate.nist.gov/twiki- > sggrid/pub/SmartGrid/PAP02Objective3/NISTI > R7761.pdf >=20 > OpenSG is doing follow up work on PAP 2. >=20 > In our experience, even in the same AMI network deployment, the node > connectivity can range from 1 neighbor to hundreds of neighbors. >=20 > Regards, > Alvaro >=20 >=20 > -----Original Message----- > From: Popa, Daniel [mailto:Daniel.Popa@itron.com] > Sent: Tuesday, July 26, 2011 5:12 PM > To: Alvaro A. Cardenas > Cc: roll@ietf.org; Jonathan Hui > Subject: RE: [Roll] [ROLL] RPL applicability statement for AMI networks >=20 > Alvaro, >=20 > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > > Alvaro A. Cardenas > > Sent: Tuesday, July 26, 2011 6:44 PM > > To: Jonathan Hui > > Cc: roll@ietf.org > > Subject: Re: [Roll] [ROLL] RPL applicability statement for AMI > networks > > > > Jonathan, > > > > > We are dealing with networks where nodes can have order hundreds of > > neighbors (yes, a single node can have more neighbors than all nodes > in > > Tutornet and Motelab combined). From our experiments, increasing the > > min interval helps deal with increased > > There has been a lot of work regarding the density of AMI networks in > > the Priority Action Plan 2 (PAP 2) of the SGIP (and also the Open SG > > networking groups) and several considerations for rural, suburban and > > urban environments under different PHY layers and power used for > > reception and transmission. Is the draft taking into consideration > > this > > work and how the parameters will change depending on the specific > > deployment? >=20 > Can you be more specific PLS and point us to some documents? A lot of > work > has been done within PAP2, SGIP or OpenSG > on wireless PHY and MAC performance versus channel characteristics & > density. >=20 >=20 > > Regards, > > Alvaro > > > > > density because it reduces the likelihood of collisions. Of > course, > > the side effect of that is that the overall responsiveness of the > > protocol becomes slower. To find good routes within a reasonable > time > > scale, it also helps to increase the redundancy constant. Note that > a > > value of 10 still allows significant suppression ratios when the > > density is high. > > > > > > I recognize that the Trickle parameters will vary for different > > deployment scenarios (sparse vs. dense, energy-constrained vs. mains- > > powered, etc) and application requirements (capacity allocated to > > control traffic, response time, etc.). The draft does not currently > > provide any discussion on that but should. > > > > > > -- > > > Jonathan Hui > > > > > > _______________________________________________ > > > 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 alvaro.cardenas-mora@us.fujitsu.com Tue Jul 26 22:51: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 0708921F8B1E for ; Tue, 26 Jul 2011 22:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.15 X-Spam-Level: X-Spam-Status: No, score=-105.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 ovi8mDAXFeZI for ; Tue, 26 Jul 2011 22:51:37 -0700 (PDT) Received: from fujitsu25.fnanic.fujitsu.com (fujitsu25.fnanic.fujitsu.com [192.240.6.15]) by ietfa.amsl.com (Postfix) with ESMTP id 17F4A21F8B1D for ; Tue, 26 Jul 2011 22:51:36 -0700 (PDT) Received: from pps.filterd (fujitsu25 [127.0.0.1]) by fujitsu25.fnanic.fujitsu.com (8.14.4/8.14.4) with SMTP id p6R5pas9001525; Tue, 26 Jul 2011 22:51:36 -0700 Received: from fujitsui.fna.fujitsu.com ([133.164.253.1]) by fujitsu25.fnanic.fujitsu.com with ESMTP id xsy1qregb-1; Tue, 26 Jul 2011 22:51:35 -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 p6R5pV4E005287; Tue, 26 Jul 2011 22:51:31 -0700 (PDT) Received: from alvarot5010 (localhost [127.0.0.1]) by toyama.fla.fujitsu.com (8.11.6+Sun/8.11.6) with ESMTP id p6R5pTJ05816; Tue, 26 Jul 2011 22:51:29 -0700 (PDT) From: "Alvaro A. Cardenas" To: "'Popa, Daniel'" References: <83027ECE5ECDC04E9BA5350B756A88E1599333F876@ITR-EXMBXVS-1.itron.com> <823F1D1D-3FF9-4907-B58C-5487644A6588@cs.stanford.edu> <83027ECE5ECDC04E9BA5350B756A88E159933CC835@ITR-EXMBXVS-1.itron.com> <83027ECE5ECDC04E9BA5350B756A88E159933CC848@ITR-EXMBXVS-1.itron.com> <89C633A5-6A3A-4A7E-A586-DA679B570D49@cs.stanford.edu> <2EDD5973-0D87-4020-978A-0DC405E3772F@cisco.com> <4E2F4318.4090709@fla.fujitsu.com> <83027ECE5ECDC04E9BA5350B756A88E159933CC89A@ITR-EXMBXVS-1.itron.com> In-Reply-To: <83027ECE5ECDC04E9BA5350B756A88E159933CC89A@ITR-EXMBXVS-1.itron.com> Date: Tue, 26 Jul 2011 22:51:29 -0700 Message-ID: <005601cc4c21$3c32b690$b49823b0$@cardenas-mora@us.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxL5XnQKgeAzNekTMWgdEZnN6n0PwAC76agAAs5DCA= Content-Language: en-us X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-07-27_01:2011-07-27, 2011-07-27, 1970-01-01 signatures=0 X-Mailman-Approved-At: Wed, 27 Jul 2011 11:05:49 -0700 Cc: roll@ietf.org Subject: Re: [Roll] [ROLL] RPL applicability statement for AMI networks 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, 27 Jul 2011 05:51:38 -0000 Hi Daniel, I am talking about the main (only?) document of PAP2: NIST-IR 7761. There are many examples where the average number of neighbors can range between a dozen or so for rural deployments to thousands of nodes (depending on the transmission and reception power). http://collaborate.nist.gov/twiki-sggrid/pub/SmartGrid/PAP02Objective3/NISTI R7761.pdf OpenSG is doing follow up work on PAP 2. In our experience, even in the same AMI network deployment, the node connectivity can range from 1 neighbor to hundreds of neighbors. Regards, Alvaro -----Original Message----- From: Popa, Daniel [mailto:Daniel.Popa@itron.com] Sent: Tuesday, July 26, 2011 5:12 PM To: Alvaro A. Cardenas Cc: roll@ietf.org; Jonathan Hui Subject: RE: [Roll] [ROLL] RPL applicability statement for AMI networks Alvaro, > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Alvaro A. Cardenas > Sent: Tuesday, July 26, 2011 6:44 PM > To: Jonathan Hui > Cc: roll@ietf.org > Subject: Re: [Roll] [ROLL] RPL applicability statement for AMI networks > > Jonathan, > > > We are dealing with networks where nodes can have order hundreds of > neighbors (yes, a single node can have more neighbors than all nodes in > Tutornet and Motelab combined). From our experiments, increasing the > min interval helps deal with increased > There has been a lot of work regarding the density of AMI networks in > the Priority Action Plan 2 (PAP 2) of the SGIP (and also the Open SG > networking groups) and several considerations for rural, suburban and > urban environments under different PHY layers and power used for > reception and transmission. Is the draft taking into consideration > this > work and how the parameters will change depending on the specific > deployment? Can you be more specific PLS and point us to some documents? A lot of work has been done within PAP2, SGIP or OpenSG on wireless PHY and MAC performance versus channel characteristics & density. > Regards, > Alvaro > > > density because it reduces the likelihood of collisions. Of course, > the side effect of that is that the overall responsiveness of the > protocol becomes slower. To find good routes within a reasonable time > scale, it also helps to increase the redundancy constant. Note that a > value of 10 still allows significant suppression ratios when the > density is high. > > > > I recognize that the Trickle parameters will vary for different > deployment scenarios (sparse vs. dense, energy-constrained vs. mains- > powered, etc) and application requirements (capacity allocated to > control traffic, response time, etc.). The draft does not currently > provide any discussion on that but should. > > > > -- > > Jonathan Hui > > > > _______________________________________________ > > 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 d.sturek@att.net Wed Jul 27 12:46: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 B937211E8073 for ; Wed, 27 Jul 2011 12:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=0.615, 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 sGUVt7TRrZNF for ; Wed, 27 Jul 2011 12:46:38 -0700 (PDT) Received: from nm29.access.bullet.mail.sp2.yahoo.com (nm29.access.bullet.mail.sp2.yahoo.com [98.139.44.156]) by ietfa.amsl.com (Postfix) with SMTP id CB6BC11E8148 for ; Wed, 27 Jul 2011 12:46:38 -0700 (PDT) Received: from [98.139.44.101] by nm29.access.bullet.mail.sp2.yahoo.com with NNFMP; 27 Jul 2011 19:46:38 -0000 Received: from [98.139.44.64] by tm6.access.bullet.mail.sp2.yahoo.com with NNFMP; 27 Jul 2011 19:46:38 -0000 Received: from [127.0.0.1] by omp1001.access.mail.sp2.yahoo.com with NNFMP; 27 Jul 2011 19:46:38 -0000 X-Yahoo-Newman-Id: 619695.86677.bm@omp1001.access.mail.sp2.yahoo.com Received: (qmail 65839 invoked from network); 27 Jul 2011 19:46:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1311795996; bh=itFUSKDzc4fncmewRf34X8DZ+QRaPeGzoR1+w891VPs=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=mABBnD2+naZrzruWwuaHPzLyWxQG1jqUwK/+K/QBk09RefUkqImaqBwGj9jLI2iCIgpfWzAV9EZpFyN6zbvRbjkOXqW8qhbORTdFvKN/nDILeYKb1aKeshyujWOe0D5HWdle9ydSVFJnGL+cC3IFzxhW6LHLd3dqCXU4kgWfGcI= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: qW_g2bwVM1nGAKWfa2Uq3QihaQuxeTQcYjO8bPjr_CS9ebj 8WD6CM8GZZ.BmlVXjgXzlLHLER_4jOy4ZbTgf23u_8Qfxz7.5P3CASgwlvPF zrI5YpqPNI6NXk75sT92VdTCieZqU5PfexQd_mpgz3fTKzHy3UzKeBnfqj8K 0E6JkHL11igcKOZ3PaKNMTpO_xxfQ_EzYz9tiVAPNVLrIsk79mreBKelj6CF z0fMLlZxca5lZEn69dHKTs4EuouSKXlU.HS6TIWrpX5vl_7RGg_Hg5abIKjR ENPHSbf2la9IwOOQ3Q2e7KITcTEjz2M2ffU5WzXmVL7OZTg78im9Z4bKS0c8 WP_rrW2Uh9TlAwa.ZKWJuYQ1AmiVn6KF4As73U8cwWqdRM93fB_sDTWQldLI F5XwN.5sRdbo3jlwIRzbZkLjhJPtvLxrdCuG3J2GVKKQSS.0LLfKe9CNUyTV ZXA95eZPQUQ-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [172.31.39.252] (d.sturek@64.168.229.50 with login) by smtp107.sbc.mail.gq1.yahoo.com with SMTP; 27 Jul 2011 12:46:36 -0700 PDT User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Wed, 27 Jul 2011 12:46:30 -0700 From: Don Sturek To: "Alvaro A. Cardenas" , "'Popa, Daniel'" Message-ID: Thread-Topic: [Roll] [ROLL] RPL applicability statement for AMI networks In-Reply-To: <005601cc4c21$3c32b690$b49823b0$@cardenas-mora@us.fujitsu.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] [ROLL] RPL applicability statement for AMI networks 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, 27 Jul 2011 19:46:39 -0000 Hi Alvaro, The PAP 2 NISTIR 7761 is probably not the document you want. There is ongoing work in PAP 2 to model density, foliage and distance in addition to the requirements presented in NISTIR 7761. Have a look at this ongoing PAP 2 work as the modeling is just now being discussed and there should be some important density/distance information forthcoming by the end of this year. Don On 7/26/11 10:51 PM, "Alvaro A. Cardenas" wrote: >Hi Daniel, > >I am talking about the main (only?) document of PAP2: NIST-IR 7761. There >are many examples where the average number of neighbors can range between >a >dozen or so for rural deployments to thousands of nodes (depending on the >transmission and reception power). > >http://collaborate.nist.gov/twiki-sggrid/pub/SmartGrid/PAP02Objective3/NIS >TI >R7761.pdf > >OpenSG is doing follow up work on PAP 2. > >In our experience, even in the same AMI network deployment, the node >connectivity can range from 1 neighbor to hundreds of neighbors. > >Regards, >Alvaro > > >-----Original Message----- >From: Popa, Daniel [mailto:Daniel.Popa@itron.com] >Sent: Tuesday, July 26, 2011 5:12 PM >To: Alvaro A. Cardenas >Cc: roll@ietf.org; Jonathan Hui >Subject: RE: [Roll] [ROLL] RPL applicability statement for AMI networks > >Alvaro, > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >> Alvaro A. Cardenas >> Sent: Tuesday, July 26, 2011 6:44 PM >> To: Jonathan Hui >> Cc: roll@ietf.org >> Subject: Re: [Roll] [ROLL] RPL applicability statement for AMI networks >> >> Jonathan, >> >> > We are dealing with networks where nodes can have order hundreds of >> neighbors (yes, a single node can have more neighbors than all nodes in >> Tutornet and Motelab combined). From our experiments, increasing the >> min interval helps deal with increased >> There has been a lot of work regarding the density of AMI networks in >> the Priority Action Plan 2 (PAP 2) of the SGIP (and also the Open SG >> networking groups) and several considerations for rural, suburban and >> urban environments under different PHY layers and power used for >> reception and transmission. Is the draft taking into consideration >> this >> work and how the parameters will change depending on the specific >> deployment? > >Can you be more specific PLS and point us to some documents? A lot of work >has been done within PAP2, SGIP or OpenSG >on wireless PHY and MAC performance versus channel characteristics & >density. > > >> Regards, >> Alvaro >> >> > density because it reduces the likelihood of collisions. Of course, >> the side effect of that is that the overall responsiveness of the >> protocol becomes slower. To find good routes within a reasonable time >> scale, it also helps to increase the redundancy constant. Note that a >> value of 10 still allows significant suppression ratios when the >> density is high. >> > >> > I recognize that the Trickle parameters will vary for different >> deployment scenarios (sparse vs. dense, energy-constrained vs. mains- >> powered, etc) and application requirements (capacity allocated to >> control traffic, response time, etc.). The draft does not currently >> provide any discussion on that but should. >> > >> > -- >> > Jonathan Hui >> > >> > _______________________________________________ >> > 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 jonhui@cisco.com Thu Jul 28 06:46: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 1809E21F8A96 for ; Thu, 28 Jul 2011 06:46:28 -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=[AWL=-1.000, 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 d9Err-l68uRJ for ; Thu, 28 Jul 2011 06:46:27 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 727DB21F8B43 for ; Thu, 28 Jul 2011 06:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=2261; q=dns/txt; s=iport; t=1311860787; x=1313070387; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=0CalTXljmCdFDnfRS1Onsdyt8GxvR/VLFmDDW3XoPC4=; b=eKCv1OryetrszdzpIVcf9BA4h2/Zt6Zi0Z1yE/wNreB2aW95oIGByKxE 7vXHN0anjVRHG+EyNWZWgEFlkbfeGqgdc25R/pW60Gd0KzRePioCmlijF DiTSWPeBjgdRTM1PysWnDyRAAcLlkYPvYA2nvjSh3fuwh8o2TX3WcFsmH k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALNnMU6rRDoJ/2dsb2JhbAA0AQEBAQIBFAErRQUMDA4KOhRRBQI+pzB3iHyjTp5bhWJfBIdZiyCQLVc X-IronPort-AV: E=Sophos;i="4.67,282,1309737600"; d="scan'208";a="7380875" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-3.cisco.com with ESMTP; 28 Jul 2011 13:46:26 +0000 Received: from sjc-vpn5-910.cisco.com (sjc-vpn5-910.cisco.com [10.21.91.142]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6SDkPbJ017961; Thu, 28 Jul 2011 13:46:25 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: Date: Thu, 28 Jul 2011 06:46:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <112C6885-7FBC-4A77-BC8A-70D77C7AB3C6@cisco.com> References: <83027ECE5ECDC04E9BA5350B756A88E1599333F876@ITR-EXMBXVS-1.itron.com> <823F1D1D-3FF9-4907-B58C-5487644A6588@cs.stanford.edu> <83027ECE5ECDC04E9BA5350B756A88E159933CC835@ITR-EXMBXVS-1.itron.com> <83027ECE5ECDC04E9BA5350B756A88E159933CC848@ITR-EXMBXVS-1.itron.com> <89C633A5-6A3A-4A7E-A586-DA679B570D49@cs.stanford.edu> <2EDD5973-0D87-4020-978A-0DC405E3772F@cisco.com> To: Philip Levis X-Mailer: Apple Mail (2.1084) Cc: "roll@ietf.org" Subject: Re: [Roll] [ROLL] RPL applicability statement for AMI networks 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, 28 Jul 2011 13:46:28 -0000 On Jul 26, 2011, at 5:40 PM, Philip Levis wrote: > On Jul 26, 2011, at 3:36 PM, Jonathan Hui wrote: >=20 >> Om's results seem to focus on networks that are relatively sparse = compared to what we have in mind. Could you provide some insight into = how dense these testbeds are under the different setups? >>=20 >> We are dealing with networks where nodes can have order hundreds of = neighbors (yes, a single node can have more neighbors than all nodes in = Tutornet and Motelab combined). =46rom our experiments, increasing the = min interval helps deal with increased density because it reduces the = likelihood of collisions. Of course, the side effect of that is that = the overall responsiveness of the protocol becomes slower. To find good = routes within a reasonable time scale, it also helps to increase the = redundancy constant. Note that a value of 10 still allows significant = suppression ratios when the density is high. >>=20 >> I recognize that the Trickle parameters will vary for different = deployment scenarios (sparse vs. dense, energy-constrained vs. = mains-powered, etc) and application requirements (capacity allocated to = control traffic, response time, etc.). The draft does not currently = provide any discussion on that but should. >=20 > Let me try to summarize, please tell me if/how I'm wrong: in very = dense AMI deployments, MAC collisions on short intervals are a real = problem, so you need significant additional random backoff from a higher = layer to avoid these collisions.=20 That's a good summary. > If this is the case, then I'd recommend describing this as a more = conservative value than what is specified in 6.6 of RFC6206. I.e., AMI = networks have super-high density, so recommend that Imin be XX times the = packet transmission time, and use a larger k to increase the = communication rate.=20 Right. The draft should do a better job discussing the tradeoffs and = the particular choice of suggested parameters. > It's useful to note that, in the case of synchronized intervals, these = k may be clustered early in the interval. So you can have bursts of = control traffic. Yes, another side effect of a relatively small Imin. -- Jonathan Hui From pal@cs.stanford.edu Thu Jul 28 09:00: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 6EF7B11E80BE for ; Thu, 28 Jul 2011 09:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Utbl99HMJ9mB for ; Thu, 28 Jul 2011 09:00:05 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id C07EB11E80C0 for ; Thu, 28 Jul 2011 09:00:04 -0700 (PDT) Received: from dn52219l.sunet ([10.33.5.53]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1QmT0F-0001ed-40; Thu, 28 Jul 2011 09:00:03 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <112C6885-7FBC-4A77-BC8A-70D77C7AB3C6@cisco.com> Date: Thu, 28 Jul 2011 08:32:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <819F25B1-3D31-4B75-81A7-79B49F984ECA@cs.stanford.edu> References: <83027ECE5ECDC04E9BA5350B756A88E1599333F876@ITR-EXMBXVS-1.itron.com> <823F1D1D-3FF9-4907-B58C-5487644A6588@cs.stanford.edu> <83027ECE5ECDC04E9BA5350B756A88E159933CC835@ITR-EXMBXVS-1.itron.com> <83027ECE5ECDC04E9BA5350B756A88E159933CC848@ITR-EXMBXVS-1.itron.com> <89C633A5-6A3A-4A7E-A586-DA679B570D49@cs.stanford.edu> <2EDD5973-0D87-4020-978A-0DC405E3772F@cisco.com> <112C6885-7FBC-4A77-BC8A-70D77C7AB3C6@cisco.com> To: Jonathan Hui X-Mailer: Apple Mail (2.1084) X-Scan-Signature: daeb03f1a6494d8fe08e106a714ef916 Cc: "roll@ietf.org" Subject: Re: [Roll] [ROLL] RPL applicability statement for AMI networks 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, 28 Jul 2011 16:00:06 -0000 On Jul 28, 2011, at 6:46 AM, Jonathan Hui wrote: >=20 > On Jul 26, 2011, at 5:40 PM, Philip Levis wrote: >=20 >> On Jul 26, 2011, at 3:36 PM, Jonathan Hui wrote: >>=20 >>> Om's results seem to focus on networks that are relatively sparse = compared to what we have in mind. Could you provide some insight into = how dense these testbeds are under the different setups? >>>=20 >>> We are dealing with networks where nodes can have order hundreds of = neighbors (yes, a single node can have more neighbors than all nodes in = Tutornet and Motelab combined). =46rom our experiments, increasing the = min interval helps deal with increased density because it reduces the = likelihood of collisions. Of course, the side effect of that is that = the overall responsiveness of the protocol becomes slower. To find good = routes within a reasonable time scale, it also helps to increase the = redundancy constant. Note that a value of 10 still allows significant = suppression ratios when the density is high. >>>=20 >>> I recognize that the Trickle parameters will vary for different = deployment scenarios (sparse vs. dense, energy-constrained vs. = mains-powered, etc) and application requirements (capacity allocated to = control traffic, response time, etc.). The draft does not currently = provide any discussion on that but should. >>=20 >> Let me try to summarize, please tell me if/how I'm wrong: in very = dense AMI deployments, MAC collisions on short intervals are a real = problem, so you need significant additional random backoff from a higher = layer to avoid these collisions.=20 >=20 > That's a good summary. >=20 >> If this is the case, then I'd recommend describing this as a more = conservative value than what is specified in 6.6 of RFC6206. I.e., AMI = networks have super-high density, so recommend that Imin be XX times the = packet transmission time, and use a larger k to increase the = communication rate.=20 >=20 > Right. The draft should do a better job discussing the tradeoffs and = the particular choice of suggested parameters. With my engineering hat on, I think I'm arguing something a bit = stronger. Rather than say that k should be large, it should say that = Imin should be large to deal with high densities, and that k can be = scaled up to lead to better responsiveness. With my research hat on, I'm not sure doing this is the right answer. = One of the original motivations for exponentially increasing I was this = exact problem, that too small an I can lead to MAC layer collisions. By = exponentially increasing I, one should be able to find the first "good" = I value (let's call it Igood) within Igood; all of the intervals before = Igood sum to Igood/2, and the silence period adds another Igood/2. This = requires no configuration, and will work for any Igood (as long as it is = smaller than Imax). One can of course tune k and Imin to a particular = density, but wireless networks typically have highly variable density, = so good settings in one part of the network might not be good in others.=20= The research question would be, for networks with highly variable = density, whether it's better to select a suitable large Imin and k or to = choose a small Imin and k. If you have some results which sheds light on = the question, I'd appreciate it. I've always thought it was the latter, = but I could imagine all kinds of nitty gritty details (such as MAC = backoff behavior) could affect the result. >=20 >> It's useful to note that, in the case of synchronized intervals, = these k may be clustered early in the interval. So you can have bursts = of control traffic. >=20 >=20 > Yes, another side effect of a relatively small Imin. You mean *large* Imin, right? A small Imin would spread, over the same = time duration, transmissions over intervals of exponentially increasing = length. Phil= From jonhui@cisco.com Thu Jul 28 09:32: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 D1E2D21F8C11 for ; Thu, 28 Jul 2011 09:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 GErOEGC7kQwC for ; Thu, 28 Jul 2011 09:32:44 -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 0C0D521F8B1A for ; Thu, 28 Jul 2011 09:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=4409; q=dns/txt; s=iport; t=1311870764; x=1313080364; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ESARXpoCekZFa2fIQ4Foy0vAQMyXlTq96GNEuI+PoRU=; b=LTWeUdIHYQ/gqGw5hzgCXphouM1j40Z4b3ONO9MdcxNqwUyX8Lh0yCvs cC/EXPYfxqQIyaFQEXNGVyPu2DTpgxCUj+mmm9BTxTVXdSKEaed7j+YUs nWG3CU56Mqhg9vdMwiWiJhqqh0dfMXugx/Uwuaf6s9UM/KqF0ifSpzREw k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOqNMU6rRDoG/2dsb2JhbAA0AQEBAQIBFAErRQUMDA4KOhRRBQI+pzl3iHykDp5ZhWJfBIdZiyCFB4smVw X-IronPort-AV: E=Sophos;i="4.67,283,1309737600"; d="scan'208";a="7443850" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-8.cisco.com with ESMTP; 28 Jul 2011 16:32:43 +0000 Received: from [10.21.79.227] ([10.21.79.227]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6SGWf5s024439; Thu, 28 Jul 2011 16:32:41 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: <819F25B1-3D31-4B75-81A7-79B49F984ECA@cs.stanford.edu> Date: Thu, 28 Jul 2011 09:32:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <83027ECE5ECDC04E9BA5350B756A88E1599333F876@ITR-EXMBXVS-1.itron.com> <823F1D1D-3FF9-4907-B58C-5487644A6588@cs.stanford.edu> <83027ECE5ECDC04E9BA5350B756A88E159933CC835@ITR-EXMBXVS-1.itron.com> <83027ECE5ECDC04E9BA5350B756A88E159933CC848@ITR-EXMBXVS-1.itron.com> <89C633A5-6A3A-4A7E-A586-DA679B570D49@cs.stanford.edu> <2EDD5973-0D87-4020-978A-0DC405E3772F@cisco.com> <112C6885-7FBC-4A77-BC8A-70D77C7AB3C6@cisco.com> <819F25B1-3D31-4B75-81A7-79B49F984ECA@cs.stanford.edu> To: Philip Levis X-Mailer: Apple Mail (2.1084) Cc: "roll@ietf.org" Subject: Re: [Roll] [ROLL] RPL applicability statement for AMI networks 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, 28 Jul 2011 16:32:44 -0000 On Jul 28, 2011, at 8:32 AM, Philip Levis wrote: > On Jul 28, 2011, at 6:46 AM, Jonathan Hui wrote: >=20 >> On Jul 26, 2011, at 5:40 PM, Philip Levis wrote: >>=20 >>> Let me try to summarize, please tell me if/how I'm wrong: in very = dense AMI deployments, MAC collisions on short intervals are a real = problem, so you need significant additional random backoff from a higher = layer to avoid these collisions.=20 >>=20 >> That's a good summary. >>=20 >>> If this is the case, then I'd recommend describing this as a more = conservative value than what is specified in 6.6 of RFC6206. I.e., AMI = networks have super-high density, so recommend that Imin be XX times the = packet transmission time, and use a larger k to increase the = communication rate.=20 >>=20 >> Right. The draft should do a better job discussing the tradeoffs and = the particular choice of suggested parameters. >=20 > With my engineering hat on, I think I'm arguing something a bit = stronger. Rather than say that k should be large, it should say that = Imin should be large to deal with high densities, and that k can be = scaled up to lead to better responsiveness. Yes, I had that in mind as well. > With my research hat on, I'm not sure doing this is the right answer. = One of the original motivations for exponentially increasing I was this = exact problem, that too small an I can lead to MAC layer collisions. By = exponentially increasing I, one should be able to find the first "good" = I value (let's call it Igood) within Igood; all of the intervals before = Igood sum to Igood/2, and the silence period adds another Igood/2. This = requires no configuration, and will work for any Igood (as long as it is = smaller than Imax). One can of course tune k and Imin to a particular = density, but wireless networks typically have highly variable density, = so good settings in one part of the network might not be good in others.=20= >=20 > The research question would be, for networks with highly variable = density, whether it's better to select a suitable large Imin and k or to = choose a small Imin and k. If you have some results which sheds light on = the question, I'd appreciate it. I've always thought it was the latter, = but I could imagine all kinds of nitty gritty details (such as MAC = backoff behavior) could affect the result. While I agree that AMI networks can have highly variable density, it's = also important to consider the actual magnitudes of that range. In this = particular case, the minimum density for many urban deployments are = typically more dense that the Tutor and Motelab testbeds. Part of the answer in choosing an appropriate Imin depends on the level = of peak congestion you are willing to accept. One could argue that it's = the MAC's job of appropriately handling congestion, but that reduces = down to rate-limiting what upper layers can send and removes the need = for Imin. We've found that too small an Imin can lead to excessive congestion and = packet loss, causing updated Trickle information to propagate less = reliably for some period of time. During this inconsistent period, = devices continue to reset their Trickle timers and the interval stays at = Imin. Also, RFC6206 makes the following statement: Finally, a protocol SHOULD set k and Imin such that Imin is at least two to three times as long as it takes to transmit k packets. Otherwise, if more than k nodes reset their intervals to Imin, the resulting communication will lead to congestion and significant packet loss. To me, that statement conveys that an appropriate "Imin" value is = dependent on density. >>> It's useful to note that, in the case of synchronized intervals, = these k may be clustered early in the interval. So you can have bursts = of control traffic. >>=20 >> Yes, another side effect of a relatively small Imin. >=20 > You mean *large* Imin, right? A small Imin would spread, over the same = time duration, transmissions over intervals of exponentially increasing = length. I guess we are talking about different scenarios. I was addressing the = case of many devices resetting their Trickle timer in response to = receiving a single inconsistent message. With a small Imin, all those = devices would choose a new t within a small window. -- Jonathan Hui From pal@cs.stanford.edu Thu Jul 28 12:59: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 8B6DA11E8167 for ; Thu, 28 Jul 2011 12:59:39 -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=[AWL=0.000, BAYES_00=-2.599, 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 z7e5Jh1DCfpp for ; Thu, 28 Jul 2011 12:59:38 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs3.Stanford.EDU [171.64.64.27]) by ietfa.amsl.com (Postfix) with ESMTP id BD33121F8A80 for ; Thu, 28 Jul 2011 12:59:38 -0700 (PDT) Received: from dn52219l.sunet ([10.33.5.53]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1QmWk5-0001b5-K0; Thu, 28 Jul 2011 12:59:37 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Thu, 28 Jul 2011 12:59:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5D1C96E8-1729-4801-8B7F-11526684A192@cs.stanford.edu> References: <83027ECE5ECDC04E9BA5350B756A88E1599333F876@ITR-EXMBXVS-1.itron.com> <823F1D1D-3FF9-4907-B58C-5487644A6588@cs.stanford.edu> <83027ECE5ECDC04E9BA5350B756A88E159933CC835@ITR-EXMBXVS-1.itron.com> <83027ECE5ECDC04E9BA5350B756A88E159933CC848@ITR-EXMBXVS-1.itron.com> <89C633A5-6A3A-4A7E-A586-DA679B570D49@cs.stanford.edu> <2EDD5973-0D87-4020-978A-0DC405E3772F@cisco.com> <112C6885-7FBC-4A77-BC8A-70D77C7AB3C6@cisco.com> <819F25B1-3D31-4B75-81A7-79B49F984ECA@cs.stanford.edu> To: Jonathan Hui X-Mailer: Apple Mail (2.1084) X-Scan-Signature: 7e839a9fe5d3c1ffc6f045e071031982 Cc: "roll@ietf.org" Subject: Re: [Roll] [ROLL] RPL applicability statement for AMI networks 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, 28 Jul 2011 19:59:39 -0000 On Jul 28, 2011, at 9:32 AM, Jonathan Hui wrote: > While I agree that AMI networks can have highly variable density, it's = also important to consider the actual magnitudes of that range. In this = particular case, the minimum density for many urban deployments are = typically more dense that the Tutor and Motelab testbeds. To be fair, we have tested Trickle's use in CTP in networks with a = density ~300 neighbors.=20 > Also, RFC6206 makes the following statement: >=20 > Finally, a protocol SHOULD set k and Imin such that Imin is at least > two to three times as long as it takes to transmit k packets. > Otherwise, if more than k nodes reset their intervals to Imin, the > resulting communication will lead to congestion and significant > packet loss. >=20 > To me, that statement conveys that an appropriate "Imin" value is = dependent on density. That implication wasn't intended. There's a reason why it says "at = least." >=20 >>>> It's useful to note that, in the case of synchronized intervals, = these k may be clustered early in the interval. So you can have bursts = of control traffic. >>>=20 >>> Yes, another side effect of a relatively small Imin. >>=20 >> You mean *large* Imin, right? A small Imin would spread, over the = same time duration, transmissions over intervals of exponentially = increasing length. >=20 >=20 > I guess we are talking about different scenarios. I was addressing = the case of many devices resetting their Trickle timer in response to = receiving a single inconsistent message. With a small Imin, all those = devices would choose a new t within a small window. Ah, right. I was talking about the fact that you'll see a transmission = just after Imin/2, followed by another, followed by another, until you = reach k, then the rest of the interval will be mostly quiet. When = looking at transmissions across a longer time scale, you'll see distinct = bursts of packets where I/2 falls. This isn't necessarily good or bad, = was just an observation. Phil= From wei-peng.chen@us.fujitsu.com Thu Jul 28 18:22:20 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 E6D5C11E80D6 for ; Thu, 28 Jul 2011 18:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.149 X-Spam-Level: X-Spam-Status: No, score=-105.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 0A49KKI+vh3T for ; Thu, 28 Jul 2011 18:22:19 -0700 (PDT) Received: from fujitsu25.fnanic.fujitsu.com (fujitsu25.fnanic.fujitsu.com [192.240.6.15]) by ietfa.amsl.com (Postfix) with ESMTP id D925711E8092 for ; Thu, 28 Jul 2011 18:22:19 -0700 (PDT) Received: from pps.filterd (fujitsu25 [127.0.0.1]) by fujitsu25.fnanic.fujitsu.com (8.14.4/8.14.4) with SMTP id p6T1MJps020129; Thu, 28 Jul 2011 18:22:19 -0700 Received: from fujitsu7i.fnanic.fujitsu.com ([133.164.253.7]) by fujitsu25.fnanic.fujitsu.com with ESMTP id xtqt28r9q-1; Thu, 28 Jul 2011 18:22:19 -0700 Received: from toyama.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsu7i.fnanic.fujitsu.com (8.13.8/8.13.8) with ESMTP id p6T1MJ8s029814; Thu, 28 Jul 2011 18:22:19 -0700 (PDT) Received: from chenvista (localhost [127.0.0.1]) by toyama.fla.fujitsu.com (8.11.6+Sun/8.11.6) with ESMTP id p6T1MHJ26877; Thu, 28 Jul 2011 18:22:17 -0700 (PDT) From: "Wei-Peng Chen" To: Date: Thu, 28 Jul 2011 18:23:23 -0700 Message-ID: <007201cc4d8e$1c8fe970$55afbc50$@chen@us.fujitsu.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0073_01CC4D53.70311170" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxNjhvUoXAcY9D1Rf+8a0jdmUFGHg== Content-Language: en-us X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-07-28_06:2011-07-29, 2011-07-28, 1970-01-01 signatures=0 Cc: roll@ietf.org Subject: [Roll] Need quantitative requirements in 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: Fri, 29 Jul 2011 01:22:21 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0073_01CC4D53.70311170 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Daniel, =20 To judge the applicability of RPL in AMI networks, in my opinion, we = need to specify a few key quantitative requirements of AMI networks. But = I cannot find quantitative requirements in neither your ID and RFC5548. = Do you think whether we should specify some key requirements such as:=20 - What is the interval each meter reports its reading? - The quantitative requirements for the latency, reliability, packet = payload, etc. of UL/DL connections, in particular DL connections such as = demand response, distribution automation. (You can find those numbers = specified in UCAIAG=E2=80=99s = SG Network System Requirements Specification and IEEE = P2030 specification.) If I miss any previous draft which has already covered these = quantitative requirements, please let me know.=20 =20 Regards, Wei-Peng =20 =20 ------=_NextPart_000_0073_01CC4D53.70311170 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi = Daniel,

 

To = judge the applicability of RPL in AMI networks, in my opinion, we need = to specify a few key quantitative requirements of AMI networks. But I = cannot find quantitative requirements in neither your ID and RFC5548. Do = you think whether we should specify some key requirements such as: =

- What is the interval each = meter reports its reading?

- The = quantitative requirements for the latency, reliability, packet payload, = etc. of UL/DL connections, in particular DL connections such as demand = response, distribution automation. (You can find those numbers specified = in UCAIAG=E2=80=99s SG Network System = Requirements Specification = and IEEE P2030 specification.)

If I = miss any previous draft which has already covered these quantitative = requirements, please let me know.

 

Regards,

Wei-Peng

 

 =

------=_NextPart_000_0073_01CC4D53.70311170-- From jpv@cisco.com Thu Jul 28 19:36: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 2E96921F886C for ; Thu, 28 Jul 2011 19:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.19 X-Spam-Level: X-Spam-Status: No, score=-102.19 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 VrKttlMaLS6v for ; Thu, 28 Jul 2011 19:36:11 -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 2FCDD21F8666 for ; Thu, 28 Jul 2011 19:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=8804; q=dns/txt; s=iport; t=1311906971; x=1313116571; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=YK9hwQH70B/0cE5IqrZtVO1COQrBwHFeXVYfWSeYjEE=; b=d9zL2u5w1KVKp1BYlgVsra1eGhj6foSNbkLkKXkTETaRUQq28k3LXp+w yZ2ggsfkt0e/MNZ5oF8gOaQCbTe/I4xmlRvHtV66wGBDK556/nXe5sNqx tf8toApxtrQQIJcLK26xW6kxaCSECOAaizPmdW3VPStvRpMCZFBb7Ozm2 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALkbMk6rRDoH/2dsb2JhbAA1AQEBAQIBAQEBEQFlCwUMDFIUGDkHFyeCNqUBd4h8BKMXnj6FYl8EknqFBgmLcA X-IronPort-AV: E=Sophos;i="4.67,285,1309737600"; d="scan'208,217";a="7620771" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-6.cisco.com with ESMTP; 29 Jul 2011 02:36:10 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6T2aAhv023152; Fri, 29 Jul 2011 02:36:10 GMT Received: from xfe-sjc-221.amer.cisco.com ([128.107.191.32]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 19:36:09 -0700 Received: from [10.255.254.166] ([10.21.148.107]) by xfe-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 19:36:06 -0700 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_AD9B100A-DF6F-47D9-AF4E-F393849B1C9A" From: JP Vasseur In-Reply-To: <007201cc4d8e$1c8fe970$55afbc50$@chen@us.fujitsu.com> Date: Thu, 28 Jul 2011 22:36:05 -0400 Message-Id: References: <007201cc4d8e$1c8fe970$55afbc50$@chen@us.fujitsu.com> To: Wei-Peng Chen X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 29 Jul 2011 02:36:06.0651 (UTC) FILETIME=[448004B0:01CC4D98] Cc: roll@ietf.org Subject: Re: [Roll] Need quantitative requirements in 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: Fri, 29 Jul 2011 02:36:12 -0000 --Apple-Mail=_AD9B100A-DF6F-47D9-AF4E-F393849B1C9A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear Wei-Peng, On Jul 28, 2011, at 9:23 PM, Wei-Peng Chen wrote: > Hi Daniel, > =20 > To judge the applicability of RPL in AMI networks, in my opinion, we = need to specify a few key quantitative requirements of AMI networks. But = I cannot find quantitative requirements in neither your ID and RFC5548. = Do you think whether we should specify some key requirements such as: > - What is the interval each meter reports its reading? > - The quantitative requirements for the latency, reliability, packet = payload, etc. of UL/DL connections, in particular DL connections such as = demand response, distribution automation. (You can find those numbers = specified in UCAIAG=92s SG Network System Requirements Specification and = IEEE P2030 specification.) > If I miss any previous draft which has already covered these = quantitative requirements, please let me know. Just an important clarification: this is an RPL applicability statement, = thus many of the items list above are out of the scope of such a document. Thanks. JP. > =20 > Regards, > Wei-Peng > =20 > =20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail=_AD9B100A-DF6F-47D9-AF4E-F393849B1C9A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear Wei-Peng,

On Jul 28, 2011, = at 9:23 PM, Wei-Peng Chen wrote:

Hi = Daniel,
To judge = the applicability of RPL in AMI networks, in my opinion, we need to = specify a few key quantitative requirements of AMI networks. But I = cannot find quantitative requirements in neither your ID and RFC5548. Do = you think whether we should specify some key requirements such = as:
- What is the = interval each meter reports its reading?
- The quantitative requirements for the latency, = reliability, packet payload, etc. of UL/DL connections, in particular DL = connections such as demand response, distribution automation. (You can = find those numbers specified in UCAIAG=92s SG Network System Requirements Specification and IEEE P2030 = specification.)
If I miss = any previous draft which has already covered these quantitative = requirements, please let me know.
Subject: Re: [Roll] Need quantitative requirements in 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: Fri, 29 Jul 2011 02:42:25 -0000 --_000_410569961B3B4C8184BDD0F3950B067Awattecocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Wei-Peng This would be indeed usefull informations. The document you pointed out gives usefull and very precise requirements. But, I'm wondering if this specification could be taken as a global rule fo= r most of AMI applications. As I'm not a SmartGrid expert, is this specification approved by most of th= e AMI actors ? C=E9dric. Le 28 juil. 2011 =E0 21:23, Wei-Peng Chen a =E9crit : Hi Daniel, To judge the applicability of RPL in AMI networks, in my opinion, we need t= o specify a few key quantitative requirements of AMI networks. But I cannot= find quantitative requirements in neither your ID and RFC5548. Do you thin= k whether we should specify some key requirements such as: - What is the interval each meter reports its reading? - The quantitative requirements for the latency, reliability, packet payloa= d, etc. of UL/DL connections, in particular DL connections such as demand r= esponse, distribution automation. (You can find those numbers specified in = UCAIAG=92sSG Network System Requirements Specification and IEEE P2030= specification.) If I miss any previous draft which has already covered these quantitative r= equirements, please let me know. Regards, Wei-Peng --_000_410569961B3B4C8184BDD0F3950B067Awattecocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable = Hi Wei-Peng

This would be indeed usefull informations.

The document you pointed out gives usefull and very= precise requirements.

But, I'm wondering if this = specification could be taken as a global rule for most of AMI applications.=

As I'm not a SmartGrid expert, is this speci= fication approved by most of the AMI actors ?

C=E9= dric.

Le 28 juil. 2011 =E0 21:23, Wei-Peng Chen a = =E9crit :

Hi Daniel,
 
To judge the applicability of RPL in AMI networks, in my = opinion, we need to specify a few key quantitative requirements of AMI netw= orks. But I cannot find quantitative requirements in neither your ID and RF= C5548. Do you think whether we should specify some key requirements such as= :
- What is the interval each meter reports its rea= ding?
- The quantitative requirements for the laten= cy, reliability, packet payload, etc. of UL/DL connections, in particular D= L connections such as demand response, distribution automation. (You can fi= nd those numbers specified in UCAIAG=92sSG Network Syste= m Requirements Specifica= tion and IEEE = P2030 specification.)
If I miss any previous draf= t which has already covered these quantitative requirements, please let me = know.
 
Regards,<= /o:p>
Wei-Peng
 
 
<ATT00001..tx= t>

= --_000_410569961B3B4C8184BDD0F3950B067Awattecocom_-- From d.sturek@att.net Thu Jul 28 20:20:24 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 0FE0A21F8AD3 for ; Thu, 28 Jul 2011 20:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 whudKxpZAGRw for ; Thu, 28 Jul 2011 20:20:23 -0700 (PDT) Received: from nm12-vm1.bullet.mail.ne1.yahoo.com (nm12-vm1.bullet.mail.ne1.yahoo.com [98.138.91.41]) by ietfa.amsl.com (Postfix) with SMTP id B0EE521F8877 for ; Thu, 28 Jul 2011 20:20:22 -0700 (PDT) Received: from [98.138.90.49] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jul 2011 03:20:18 -0000 Received: from [98.138.89.172] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jul 2011 03:20:18 -0000 Received: from [127.0.0.1] by omp1028.mail.ne1.yahoo.com with NNFMP; 29 Jul 2011 03:20:18 -0000 X-Yahoo-Newman-Id: 567642.47015.bm@omp1028.mail.ne1.yahoo.com Received: (qmail 80109 invoked from network); 29 Jul 2011 03:20:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1311909617; bh=kKoST5GFf1tjT8NFqDbae8hIORonWsZUgJGhKdHrRYA=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:Mime-Version:In-Reply-To:X-Apple-Yahoo-Original-Message-Folder:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:X-Apple-Yahoo-Replied-Msgid:Subject:Date:To; b=29fyEFd6Ir271OMh6Cl4Vj/uEVFA4bKtSZavXv47yg297UB9oW+SdDlYwjBzbShwhkuc5P56BRfF/4et1zUjpLzC42EuKFEXKAB2mRwtsU0ksGMgquFq/hADwBVMutT1s10duu1iNaAImhSG4HzshsFhJ7o8q9jaDKK59kcYQL0= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: DJzCHBoVM1nMoe1lofMIPNmkT1puaiAJljiP5WVpEqsqiU4 Fq9S0RdayE_WzLGepFU3PmdR.bBhUGRl4D.9V9Isv7As9RN1FxPw897nNBpg MfSZbP7mjHv1WF.5.Kl0McMT_OgpsnyFWHvAbof4KMwnWtYgsgcRTyNlHh4K 0p5xV4FXeQ4MxTmipq7Jr1k5E3o9MSbWco0mdBPCRq341.t7qNYmVEeUBYkf RDmWN1nY07kNBt1S9FJDJHfzXW0Yx0fe5Ail342sKupAkOHEfC3JVVh7dhuE _1VBxHGu62jMws4bkiy0PqowGoicOjA1lK0u98dwLC4ybNb05m07HfSiqPW3 HOks1RQLgeE6mdAJKa1eKnoYh7Q7HNsajza1Z4uIhgsGoa6HUkz37aCjYtTu Ls6GPYTxt.h9tozPCTUWqkRiTiEu5tLBcsFJxsyphmCF0zCkqjo_NiRhJjYf bPOUhyccnxFu6PUvfgVqg15VvUJ.Yvbh6g8H3IFxkcYr91UHs.VOuGlZOMiQ qnY14K96oxkEIFeDsZwW9z_OuuxE8vCgw3fOl.QOGO1P2Yv.n5delUGqPqaA hGxejhgLV2Au6l9QBFPInExAc9VELYaEb9QhGzhDYW8UQvI1nsHAr3jlyoWR xikEsO3uQlItfnQTEo4280MSW_s29RkrMk.7vK0_kXYXeur7LIf6K9jkrgFC ZqudijDlbwcsTCbEkWgSGlqjzphjoNmgyK1dv2o6eKgo5GClOftpob4J05oK Ik534Zf34fLLP.vzebj22vl1IRSy1fM8KHQs7rMkLUE.u7KnijpCejpHi.uz W83hVACZFUpQcVbUoABFyree1VoyIstLZIByzGIuTmddOFez0v6FTDV2S7_G 8xZ1xbTG2.Kv7DmW7bYcqDYTTSLMSbNoXsEZA30ggEcY4VsdGSDiuTq9bseO ohWgIIg_xGh_Aqw9BaRw0JQr3EfEKlQHsmKVW._cLHyqJjPqsxAZ7vJ9ManW ajIlFeeuLiY49keXdgmxJxOHhsQPpT94fWnFuEo4oPs15v4vgiXBMzzVL2C. ozOBXPsf5ziJOVnShei5xb2JJoN7XY8BPmyhOBF.P4DmnjailL9OSOceY5Sw 2pIUqmB6fXMfsdneavjXRcJm_cMWbxRkNHlcqAp.Oe29B39fhFOzE_EDV7JI rYAOSk_kFxHuhVYK.tq7s3qs_89lkp4IINtKdTSWLLHDJHYOJAQpWpyDrO1O RlrUxESwF5cuVyfyX1uZj6vsWwRl9ngLrhvLeDFv0idNBzCWnJw0bwIEVxg- - X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.196] (d.sturek@69.108.51.214 with xymcookie) by smtp112-mob.biz.mail.gq1.yahoo.com with SMTP; 28 Jul 2011 20:20:15 -0700 PDT References: <007201cc4d8e$1c8fe970$55afbc50$@chen@us.fujitsu.com> Mime-Version: 1.0 (iPad Mail 8C148) In-Reply-To: X-Apple-Yahoo-Original-Message-Folder: Inbox Content-Type: multipart/alternative; boundary=Apple-Mail-1-742949830 Content-Transfer-Encoding: 7bit Message-Id: <55549B8A-06A8-4815-BEFA-103FD2EAD0D4@att.net> X-Mailer: iPad Mail (8C148) From: Don Sturek X-Apple-Yahoo-Replied-Msgid: 1_142883_AIbHjkQAASRQTjIcowuXJXyi4c4 Date: Thu, 28 Jul 2011 20:28:32 -0700 To: JP Vasseur Cc: "roll@ietf.org" , Wei-Peng Chen Subject: Re: [Roll] Need quantitative requirements in 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: Fri, 29 Jul 2011 03:20:24 -0000 --Apple-Mail-1-742949830 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi JP, The OpenSG SG-NET, and additional NIST PAP 2 work, are important contributio= ns to the requirements for AMI routing. I think both are applicable to the u= se of ROLL RPL for AMI applications. Don Sent from my iPad On Jul 28, 2011, at 7:36 PM, JP Vasseur wrote: > Dear Wei-Peng, >=20 > On Jul 28, 2011, at 9:23 PM, Wei-Peng Chen wrote: >=20 >> Hi Daniel, >> =20 >> To judge the applicability of RPL in AMI networks, in my opinion, we need= to specify a few key quantitative requirements of AMI networks. But I canno= t find quantitative requirements in neither your ID and RFC5548. Do you thin= k whether we should specify some key requirements such as: >> - What is the interval each meter reports its reading? >> - The quantitative requirements for the latency, reliability, packet payl= oad, etc. of UL/DL connections, in particular DL connections such as demand r= esponse, distribution automation. (You can find those numbers specified in U= CAIAG=E2=80=99s SG Network System Requirements Specification and IEEE P2030 s= pecification.) >> If I miss any previous draft which has already covered these quantitative= requirements, please let me know. >=20 > Just an important clarification: this is an RPL applicability statement, t= hus many of the items list above > are out of the scope of such a document. >=20 > Thanks. >=20 > JP. >=20 >> =20 >> Regards, >> Wei-Peng >> =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 --Apple-Mail-1-742949830 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi JP,

The Ope= nSG SG-NET, and additional NIST PAP 2 work, are important contributions to t= he requirements for AMI routing.  I think both are applicable to the us= e of ROLL RPL for AMI applications.

Don

Sent= from my iPad

On Jul 28, 2011, at 7:36 PM, JP Vasseur <jpv@cisco.com> wrote:

=
Dear Wei-Peng,

On Jul= 28, 2011, at 9:23 PM, Wei-Peng Chen wrote:

<= div style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bo= ttom: 0.0001pt; text-align: justify; font-size: 10.5pt; font-family: Arial, s= ans-serif; ">Hi D= aniel,
 
To judge the applica= bility of RPL in AMI networks, in my opinion, we need to specify a few key q= uantitative requirements of AMI networks. But I cannot find quantitative req= uirements in neither your ID and RFC5548. Do you think whether we should spe= cify some key requirements such as:
- What is the interv= al each meter reports its reading?
- The quantitative r= equirements for the latency, reliability, packet payload, etc. of UL/DL conn= ections, in particular DL connections such as demand response, distribution a= utomation. (You can find those numbers specified in UCAIAG=E2=80=99s SG Network System Req= uirements Specification and IEEE P2030 sp= ecification.)
If I miss any previous draft which has al= ready covered these quantitative requirements, please let me know.

= Just an important clarification: this is an RPL applicability statement, thu= s many of the items list above
are out of the scope of such a docu= ment.

Thanks.

JP.
 
Regards,
Wei-Peng
=  
 
________= _______________________________________
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-1-742949830-- From thomas@thomasclausen.org Thu Jul 28 20:22: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 0A97821F86D2 for ; Thu, 28 Jul 2011 20:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 FjccTeo+EuS5 for ; Thu, 28 Jul 2011 20:22:14 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id C5A2121F86DD for ; Thu, 28 Jul 2011 20:22:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 141073254008; Thu, 28 Jul 2011 20:22:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.0.1.4] (dhcp-475d.meeting.ietf.org [130.129.71.93]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id BDC6E3246248; Thu, 28 Jul 2011 20:22:12 -0700 (PDT) References: <007201cc4d8e$1c8fe970$55afbc50$@chen@us.fujitsu.com> In-Reply-To: Mime-Version: 1.0 (iPad Mail 8K2) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1-742567578 Message-Id: <86CDEBEF-340A-4152-9D8E-71448EDC99D9@thomasclausen.org> X-Mailer: iPad Mail (8K2) From: Thomas Heide Clausen Date: Thu, 28 Jul 2011 23:22:10 -0400 To: JP Vasseur Cc: "roll@ietf.org" , Wei-Peng Chen Subject: Re: [Roll] Need quantitative requirements in 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: Fri, 29 Jul 2011 03:22:15 -0000 --Apple-Mail-1-742567578 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 28 Jul 2011, at 22:36, JP Vasseur wrote: > Dear Wei-Peng, >=20 > On Jul 28, 2011, at 9:23 PM, Wei-Peng Chen wrote: >=20 >> Hi Daniel, >> =20 >> To judge the applicability of RPL in AMI networks, in my opinion, we need= to specify a few key quantitative requirements of AMI networks. But I canno= t find quantitative requirements in neither your ID and RFC5548. Do you thin= k whether we should specify some key requirements such as: >> - What is the interval each meter reports its reading? >> - The quantitative requirements for the latency, reliability, packet payl= oad, etc. of UL/DL connections, in particular DL connections such as demand r= esponse, distribution automation. (You can find those numbers specified in U= CAIAG=E2=80=99s SG Network System Requirements Specification and IEEE P2030 s= pecification.) >> If I miss any previous draft which has already covered these quantitative= requirements, please let me know. >=20 > Just an important clarification: this is an RPL applicability statement, t= hus many of the items list above > are out of the scope of such a document. >=20 Just to clarify, you are saying that RPL is not applicable for AMI, and ther= efore these considerations are out of scope. I agree with that,. I, then, wonder why draft-ietf-roll-applicability-ami exists as WG document -= as you say that AMI is out of scope for RPL. Thomas > Thanks. >=20 > JP. >=20 >> =20 >> Regards, >> Wei-Peng >> =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 --Apple-Mail-1-742567578 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8



On 28= Jul 2011, at 22:36, JP Vasseur <jpv@cis= co.com> wrote:

Dear Wei-Peng,

On Jul 28, 2011, at 9:23 PM, Wei-Peng Chen= wrote:

Hi Daniel,
&nb= sp;
To judge the applicability of RPL in AMI networks, in my o= pinion, we need to specify a few key quantitative requirements of AMI networ= ks. But I cannot find quantitative requirements in neither your ID and RFC55= 48. Do you think whether we should specify some key requirements such as:
- What is the interval each meter reports its reading?
- The quantitative requirements for the latency, reliabil= ity, packet payload, etc. of UL/DL connections, in particular DL connections= such as demand response, distribution automation. (You can find those numbe= rs specified in UCAIAG=E2=80=99s = SG Network System Requirements Specification and IEEE P2030 specification.)
<= div style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bo= ttom: 0.0001pt; text-align: justify; font-size: 10.5pt; font-family: Arial, s= ans-serif; ">If I= miss any previous draft which has already covered these quantitative requir= ements, please let me know.

Just an important clarification: this i= s an RPL applicability statement, thus many of the items list above
are out of the scope of such a document.

<= /div>

Just to clarify, you are saying that RPL is= not applicable for AMI, and therefore these considerations are out of scope= . I agree with that,.

I, then, wonder why draft-ietf= -roll-applicability-ami exists as WG document - as you say that AMI is out o= f scope for RPL.

Thomas

Thanks.

JP.
 
Regards,
Wei-Peng
=  
 
________= _______________________________________
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
<= /html>= --Apple-Mail-1-742567578-- From ietfroll@yahoo.com Thu Jul 28 20:22: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 6BA5411E807F for ; Thu, 28 Jul 2011 20:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hDNSNIwC44T for ; Thu, 28 Jul 2011 20:22:24 -0700 (PDT) Received: from nm24-vm3.bullet.mail.ne1.yahoo.com (nm24-vm3.bullet.mail.ne1.yahoo.com [98.138.91.154]) by ietfa.amsl.com (Postfix) with SMTP id 6DBD011E8077 for ; Thu, 28 Jul 2011 20:22:24 -0700 (PDT) Received: from [98.138.90.50] by nm24.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jul 2011 03:22:21 -0000 Received: from [98.138.87.1] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jul 2011 03:22:21 -0000 Received: from [127.0.0.1] by omp1001.mail.ne1.yahoo.com with NNFMP; 29 Jul 2011 03:22:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 571051.47839.bm@omp1001.mail.ne1.yahoo.com Received: (qmail 76876 invoked by uid 60001); 29 Jul 2011 03:22:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311909740; bh=6i9sp1wah/jXOyTYHID3gYisGAlW2YClI4P3mOAAFKU=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=EuV6+HWJDyVBnUP0F8eVufKlSHnURx3XJvZvLNFl4eyn4vvpLvRx1WtshvGR50X4XTHOKkpKCXgC/M1WxnDWeWvNXdYJv7SoR8J7KvvXGBEkNwkgrxXR55V5WCsd2J7piul/iBXD9ff0Fo6P17gCEk7Tf+Ue8oFa6H/jFaE56Dg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=rS2rVxu+Pe0q+G8GT8i6ZTzo5wys8ygDyMYHiiShjSGAV10kTlRGSZzy0U+AJ7A2fs/dkdFoEohqMnRJhuTOQv6k7sakxFynYqUcdW2GN+sLVR3HGGpsIvSJN2sGX3+Ld3dwkGGEaxc3idYskQ3zYATSEqqXSYH89A+vFA5sgjc=; X-YMail-OSG: Fszj3CwVM1kw4dAWy9phDgpvQ8w7kN2S3DjlyAOmPINKBsy vHta5vjuBcyGSrGvfjTq9zOtmajqQqslaeLKbFg2R2x0nJ73O.enib6h_bxM xAmJdeVgYgrOS__qBhHKzZ5o_205MtH36ZBkAruMeQu4o9jHcX60kSUw8d1y IA7D0E1pxuNRQNxo29ovdidi50BiKX4KJhcq.AGEWV7zrP728CyOgNpZMajb 0wY5unJi3gUPwlbXwoDmybqsgPDZPjZ.KnHipXKFbuJGD5cTRCqbE6fWWrHU mJ8aE30SYVCvQGhFx1ME8dfrJt.WwDqpcuSHaDK2UNGAEUGC6.yk- Received: from [184.105.146.4] by web113904.mail.gq1.yahoo.com via HTTP; Thu, 28 Jul 2011 20:22:20 PDT X-Mailer: YahooMailClassic/14.0.3 YahooMailWebService/0.8.112.310352 Message-ID: <1311909740.76584.YahooMailClassic@web113904.mail.gq1.yahoo.com> Date: Thu, 28 Jul 2011 20:22:20 -0700 (PDT) From: Ietf Roll To: Wei-Peng Chen , JP Vasseur In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] Need quantitative requirements in 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: Fri, 29 Jul 2011 03:22:25 -0000 JP, This is completely illogical. This is an Applicability Statement=20 \about AMI/ so specifying some quantitative requirements of the AMI netork = is completely within scope.How can you judge any applicability without spec= ifying what you are saying it is applicable to. Without some concrete requirements all you have is a marketing / sales docu= ment. Rav --- On Fri, 7/29/11, JP Vasseur wrote: > From: JP Vasseur > Subject: Re: [Roll] Need quantitative requirements in draft-ietf-roll-app= licability-ami-01 > To: "Wei-Peng Chen" > Cc: roll@ietf.org > Date: Friday, July 29, 2011, 2:36 AM > Dear > Wei-Peng, > On Jul 28, 2011, at 9:23 PM, Wei-Peng Chen > wrote: > Hi Daniel, =C2=A0To judge the applicability of RPL in AMI networks, in > my opinion, we need to specify a few key quantitative > requirements of AMI networks. But I cannot find quantitative > requirements in neither your ID and RFC5548. Do you think > whether we should specify some key requirements such > as:- What is the interval each meter reports its > reading?- The quantitative requirements for the latency, > reliability, packet payload, etc. of UL/DL connections, in > particular DL connections such as demand response, > distribution automation. (You can find those numbers > specified in UCAIAG=E2=80=99s=C2=A0SG > Network System Requirements=C2=A0Specification=C2=A0and > IEEE P2030 specification.)If I miss any previous draft which has already > covered these quantitative requirements, please let me > know. > Just an important clarification: this is an RPL > applicability statement, thus many of the items list > aboveare out of the scope of such a > document. > Thanks. > JP. > =C2=A0Regards,Wei-Peng =C2=A0 > =C2=A0 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 >=20 > -----Inline Attachment Follows----- >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From jpv@cisco.com Thu Jul 28 21:18: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 D2A1E1F0C42 for ; Thu, 28 Jul 2011 21:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.153 X-Spam-Level: X-Spam-Status: No, score=-110.153 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 0hMqQp176FcT for ; Thu, 28 Jul 2011 21:18:29 -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 13E461F0C41 for ; Thu, 28 Jul 2011 21:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=11875; q=dns/txt; s=iport; t=1311913109; x=1313122709; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=Z06ZSO6Gzazx2HD8r153cWcXqBWbI89kwzJvo3//Nys=; b=HQcSzuvWHh294wEiDc45DqYYhrC4eG3YQVJ5OkabQbVL1n94v9HPcWli 0PJzu6+88XmOOngHZNB3U2xjwZUmtKMNWxMkZPRjujzJ0sEL9Wtr+jf2A 4pDdsqXROd+no9DxPRX3V3QjfnJphThTClWX1F1oBj15gynCvF41jsKZn I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPgzMk6Q/khR/2dsb2JhbAA2AQEBAQIBAQEBEQFlCwUMDBg6FBg5BxcngjalAXeIfASiZp49hWJfBJJ6hQYJi3A X-IronPort-AV: E=Sophos;i="4.67,286,1309737600"; d="scan'208,217";a="45318141" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 29 Jul 2011 04:18:27 +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 p6T4IRGR011164; Fri, 29 Jul 2011 04:18:27 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Jul 2011 06:18:27 +0200 Received: from [10.255.254.166] ([10.55.94.186]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Jul 2011 06:04:21 +0200 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_D883BD0D-684C-41C0-8E53-F6BFD59E25DD" From: JP Vasseur In-Reply-To: <86CDEBEF-340A-4152-9D8E-71448EDC99D9@thomasclausen.org> Date: Fri, 29 Jul 2011 00:03:13 -0400 Message-Id: References: <007201cc4d8e$1c8fe970$55afbc50$@chen@us.fujitsu.com> <86CDEBEF-340A-4152-9D8E-71448EDC99D9@thomasclausen.org> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 29 Jul 2011 04:05:26.0780 (UTC) FILETIME=[BF62CBC0:01CC4DA4] Cc: "roll@ietf.org" , Wei-Peng Chen Subject: Re: [Roll] Need quantitative requirements in 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: Fri, 29 Jul 2011 04:18:30 -0000 --Apple-Mail=_D883BD0D-684C-41C0-8E53-F6BFD59E25DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 28, 2011, at 11:22 PM, Thomas Heide Clausen wrote: >=20 >=20 >=20 > On 28 Jul 2011, at 22:36, JP Vasseur wrote: >=20 >> Dear Wei-Peng, >>=20 >> On Jul 28, 2011, at 9:23 PM, Wei-Peng Chen wrote: >>=20 >>> Hi Daniel, >>> =20 >>> To judge the applicability of RPL in AMI networks, in my opinion, we = need to specify a few key quantitative requirements of AMI networks. But = I cannot find quantitative requirements in neither your ID and RFC5548. = Do you think whether we should specify some key requirements such as: >>> - What is the interval each meter reports its reading? >>> - The quantitative requirements for the latency, reliability, packet = payload, etc. of UL/DL connections, in particular DL connections such as = demand response, distribution automation. (You can find those numbers = specified in UCAIAG=92s SG Network System Requirements Specification and = IEEE P2030 specification.) >>> If I miss any previous draft which has already covered these = quantitative requirements, please let me know. >>=20 >> Just an important clarification: this is an RPL applicability = statement, thus many of the items list above >> are out of the scope of such a document. >>=20 >=20 > Just to clarify, you are saying that RPL is not applicable for AMI, = and therefore these considerations are out of scope. I agree with that,. >=20 Thomas, where do you see that I said this ? I said that "interval each meter reports its reading", "packet payload", = =85 are not routing parameters, thus there are of the scope of this = document, which is a RPL AMI applicability statement. In other words, = the objective is to explain how RPL can be used for AMI purposes. Non = routing related issues are thus out of the scope. I am just stating the = obvious here. Thanks. JP. > I, then, wonder why draft-ietf-roll-applicability-ami exists as WG = document - as you say that AMI is out of scope for RPL. >=20 > Thomas >=20 >> Thanks. >>=20 >> JP. >>=20 >>> =20 >>> Regards, >>> Wei-Peng >>> =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 --Apple-Mail=_D883BD0D-684C-41C0-8E53-F6BFD59E25DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252



On 28 Jul = 2011, at 22:36, JP Vasseur <jpv@cisco.com> = wrote:

Dear = Wei-Peng,

On Jul 28, 2011, at 9:23 PM, Wei-Peng Chen = wrote:

Hi = Daniel,
To judge = the applicability of RPL in AMI networks, in my opinion, we need to = specify a few key quantitative requirements of AMI networks. But I = cannot find quantitative requirements in neither your ID and RFC5548. Do = you think whether we should specify some key requirements such = as:
- What is the = interval each meter reports its reading?
- The quantitative requirements for the latency, = reliability, packet payload, etc. of UL/DL connections, in particular DL = connections such as demand response, distribution automation. (You can = find those numbers specified in UCAIAG=92s SG Network System Requirements Specification and IEEE P2030 = specification.)
If I miss = any previous draft which has already covered these quantitative = requirements, please let me know.
routing = parameters, thus there are of the scope of this document, which is a RPL = AMI applicability statement. In other words, the objective is to explain = how RPL can be used for AMI purposes. Non routing related issues are = thus out of the scope. I am just stating the obvious = here.

Thanks.

JP.
<= div>

I, then, wonder = why draft-ietf-roll-applicability-ami exists as WG document - as = you say that AMI is out of scope for = RPL.

Thomas

= --Apple-Mail=_D883BD0D-684C-41C0-8E53-F6BFD59E25DD-- From Thomas@ThomasClausen.org Thu Jul 28 21:28: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 69BAD11E8084 for ; Thu, 28 Jul 2011 21:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, 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 3dxbchbMSD6C for ; Thu, 28 Jul 2011 21:28:04 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id DFA0F11E807F for ; Thu, 28 Jul 2011 21:28:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id B8CEE325C155; Thu, 28 Jul 2011 21:27:56 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.0.1.6] (dhcp-475d.meeting.ietf.org [130.129.71.93]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 1EDE33244FB4; Thu, 28 Jul 2011 21:27:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_A97D411C-A731-4901-8E59-0DF3505B82E4" From: Thomas Heide Clausen In-Reply-To: Date: Fri, 29 Jul 2011 00:27:53 -0400 Message-Id: <651AEDF5-B195-40B7-B5E6-EDF5F78A12EE@ThomasClausen.org> References: <007201cc4d8e$1c8fe970$55afbc50$@chen@us.fujitsu.com> <86CDEBEF-340A-4152-9D8E-71448EDC99D9@thomasclausen.org> To: JP Vasseur X-Mailer: Apple Mail (2.1244.3) Cc: "roll@ietf.org" , Wei-Peng Chen Subject: Re: [Roll] Need quantitative requirements in 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: Fri, 29 Jul 2011 04:28:05 -0000 --Apple-Mail=_A97D411C-A731-4901-8E59-0DF3505B82E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 29, 2011, at 00:03 , JP Vasseur wrote: >=20 > On Jul 28, 2011, at 11:22 PM, Thomas Heide Clausen wrote: >=20 >>=20 >>=20 >>=20 >> On 28 Jul 2011, at 22:36, JP Vasseur wrote: >>=20 >>> Dear Wei-Peng, >>>=20 >>> On Jul 28, 2011, at 9:23 PM, Wei-Peng Chen wrote: >>>=20 >>>> Hi Daniel, >>>> =20 >>>> To judge the applicability of RPL in AMI networks, in my opinion, = we need to specify a few key quantitative requirements of AMI networks. = But I cannot find quantitative requirements in neither your ID and = RFC5548. Do you think whether we should specify some key requirements = such as: >>>> - What is the interval each meter reports its reading? >>>> - The quantitative requirements for the latency, reliability, = packet payload, etc. of UL/DL connections, in particular DL connections = such as demand response, distribution automation. (You can find those = numbers specified in UCAIAG=92s SG Network System Requirements = Specification and IEEE P2030 specification.) >>>> If I miss any previous draft which has already covered these = quantitative requirements, please let me know. >>>=20 >>> Just an important clarification: this is an RPL applicability = statement, thus many of the items list above >>> are out of the scope of such a document. >>>=20 >>=20 >> Just to clarify, you are saying that RPL is not applicable for AMI, = and therefore these considerations are out of scope. I agree with that,. >>=20 >=20 > Thomas, where do you see that I said this ? > I said that "interval each meter reports its reading", "packet = payload", =85 are not routing parameters, thus there are of the scope of = this document, which is a RPL AMI applicability statement. In other = words, the objective is to explain how RPL can be used for AMI purposes. = Non routing related issues are thus out of the scope. I am just stating = the obvious here. >=20 Traffic patterns are important to understand the applicability (if any) = of a given routing protocol. I am also just stating the obvious here. Thomas > Thanks. >=20 > JP. >=20 >=20 >> I, then, wonder why draft-ietf-roll-applicability-ami exists as WG = document - as you say that AMI is out of scope for RPL. >>=20 >> Thomas >>=20 >>> Thanks. >>>=20 >>> JP. >>>=20 >>>> =20 >>>> Regards, >>>> Wei-Peng >>>> =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 --Apple-Mail=_A97D411C-A731-4901-8E59-0DF3505B82E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

On Jul 28, 2011, = at 11:22 PM, Thomas Heide Clausen wrote:




On 28 Jul = 2011, at 22:36, JP Vasseur <jpv@cisco.com> = wrote:

Dear = Wei-Peng,

On Jul 28, 2011, at 9:23 PM, Wei-Peng Chen = wrote:

Hi = Daniel,
To judge = the applicability of RPL in AMI networks, in my opinion, we need to = specify a few key quantitative requirements of AMI networks. But I = cannot find quantitative requirements in neither your ID and RFC5548. Do = you think whether we should specify some key requirements such = as:
- What is the = interval each meter reports its reading?
- The quantitative requirements for the latency, = reliability, packet payload, etc. of UL/DL connections, in particular DL = connections such as demand response, distribution automation. (You can = find those numbers specified in UCAIAG=92s SG Network System Requirements Specification and IEEE P2030 = specification.)
If I miss = any previous draft which has already covered these quantitative = requirements, please let me know.
routing = parameters, thus there are of the scope of this document, which is a RPL = AMI applicability statement. In other words, the objective is to explain = how RPL can be used for AMI purposes. Non routing related issues are = thus out of the scope. I am just stating the obvious = here.


Traffic = patterns are important to understand the applicability (if any) of a = given routing protocol. I am also just stating the obvious = here.

Thomas

I, then, wonder = why draft-ietf-roll-applicability-ami exists as WG document - as = you say that AMI is out of scope for = RPL.

Thomas


= --Apple-Mail=_A97D411C-A731-4901-8E59-0DF3505B82E4-- From ietfroll@yahoo.com Thu Jul 28 21:37: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 8185211E807F for ; Thu, 28 Jul 2011 21:37:29 -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 AaTPiD2cXi-j for ; Thu, 28 Jul 2011 21:37:28 -0700 (PDT) Received: from nm10-vm0.bullet.mail.sp2.yahoo.com (nm10-vm0.bullet.mail.sp2.yahoo.com [98.139.91.198]) by ietfa.amsl.com (Postfix) with SMTP id 746A221F863E for ; Thu, 28 Jul 2011 21:37:28 -0700 (PDT) Received: from [98.139.91.68] by nm10.bullet.mail.sp2.yahoo.com with NNFMP; 29 Jul 2011 04:37:24 -0000 Received: from [98.139.91.47] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 29 Jul 2011 04:37:24 -0000 Received: from [127.0.0.1] by omp1047.mail.sp2.yahoo.com with NNFMP; 29 Jul 2011 04:37:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 532871.58838.bm@omp1047.mail.sp2.yahoo.com Received: (qmail 4429 invoked by uid 60001); 29 Jul 2011 04:37:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311914244; bh=XvBT4n56vKwjGGJR+ea4sNHiogKOY89/pn+1X2PXKro=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=V5D+ODQ9hyKN2tLMcgg/v/eRJb6jJRffMOe1E7192aBNhtY+1epoFWP5x6s3RDLprGInDuE4VmbLD81f3hJhn6rbyI8pnwkDyivC76eu9/860SJBCnk7L8hGp3oKpcCR7J8Btmdjd9KAwRhb8GZBgbTnxypXm3pM8vFF2dUxgFQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bWAgZY20N95e+vIiBViE/hrZ+3hTN/VKIO7c2rGGkH91vBI1J3gvs8CkSGAagHQORcmUz3kD8pfkes6ZDQ61Rj5H7rZ/TTlpACSIgr5lbrrTZxnlrKkoIvmmtNwzEQ6cmP5uBtfI0ZXS0eDym78+G3NZjHuL1b3dg1IwBWYfyB4=; X-YMail-OSG: CpnwCWMVM1lA8UCbJSm4jz8P_HaZWME1rLaFWcTrz1M_o54 n86PMg0O4aY6sELoT1DWI3kbv2EFbDCfuCh82bl4iM6Z2Z0DSk3Xec4wQ0y2 lL6sKj_g5AfETp72wM1Y86VKcxi6Znb_Do8v.gvw1ipxwX3PtodIusImBBGY MuOD0hoRpb17pAF6wtJ8pY0b0GRlK1U_hUFbfMf.od3txZKCH5ikntYmBSDh RFlxRwk8lrWowSkklNfFXBW_lPDdjh6Y_JdDZQEOtQ0OzCJ3FQzxA8oMxPzN XC_9fZFKVEYsaQQm5hjuYA6GGJzRVuTKViVVLgZfFRbk7.kDiPnqA Received: from [199.167.132.227] by web113913.mail.gq1.yahoo.com via HTTP; Thu, 28 Jul 2011 21:37:23 PDT X-Mailer: YahooMailClassic/14.0.3 YahooMailWebService/0.8.112.310352 Message-ID: <1311914243.47928.YahooMailClassic@web113913.mail.gq1.yahoo.com> Date: Thu, 28 Jul 2011 21:37:23 -0700 (PDT) From: Ietf Roll To: Thomas Heide Clausen , JP Vasseur In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "roll@ietf.org" , Wei-Peng Chen Subject: Re: [Roll] Need quantitative requirements in 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: Fri, 29 Jul 2011 04:37:29 -0000 This is what you are saying now in your revisionist history, but certainly = not what you said. It is important to understand the total communications environment that the= routing protocol must work in or do you forget the now abandoned draft on = protocol survey made a big deal about the routing maintenance overhead (as = computed by comparing data vs maintenance packets.) If I'm only sending a packet once in a long while and latency isn't an issu= e I could search for path on each packet, could I not. In a "good" applicability statement it would seem beneficial to well specif= y the network you are claiming applicability to. --- On Fri, 7/29/11, JP Vasseur wrote: > From: JP Vasseur > Subject: Re: [Roll] Need quantitative requirements in draft-ietf-roll-app= licability-ami-01 > To: "Thomas Heide Clausen" > Cc: "roll@ietf.org" , "Wei-Peng Chen" > Date: Friday, July 29, 2011, 4:03 AM >=20 > On Jul 28, 2011, at 11:22 PM, Thomas Heide > Clausen wrote: >=20 >=20 >=20 > On 28 Jul 2011, at 22:36, JP Vasseur > wrote: >=20 > Dear > Wei-Peng, > On Jul 28, 2011, at 9:23 PM, Wei-Peng Chen > wrote: > Hi Daniel, =C2=A0To judge the applicability of RPL in AMI networks, in > my opinion, we need to specify a few key quantitative > requirements of AMI networks. But I cannot find quantitative > requirements in neither your ID and RFC5548. Do you think > whether we should specify some key requirements such > as:- What is the interval each meter reports its > reading?- The quantitative requirements for the latency, > reliability, packet payload, etc. of UL/DL connections, in > particular DL connections such as demand response, > distribution automation. (You can find those numbers > specified in UCAIAG=E2=80=99s=C2=A0SG > Network System Requirements=C2=A0Specification=C2=A0and > IEEE P2030 specification.)If I miss any previous draft which has already > covered these quantitative requirements, please let me > know. > Just an important clarification: this is an RPL > applicability statement, thus many of the items list > aboveare out of the scope of such a > document. >=20 > Just to clarify, you are saying that RPL is not > applicable for AMI, and therefore these considerations are > out of scope. I agree with that,. >=20 > Thomas, where do you see that I said this > ?I said that "interval each meter reports > its reading", "packet payload", =E2=80=A6 are not > routing parameters, thus there are of the scope of > this document, which is a RPL AMI applicability statement. > In other words, the objective is to explain how RPL can be > used for AMI purposes. Non routing related issues are thus > out of the scope. I am just stating the obvious > here. > Thanks. > JP. >=20 > I, then, wonder > why=C2=A0draft-ietf-roll-applicability-ami exists as WG > document - as you say that AMI is out of scope for > RPL. > Thomas >=20 > Thanks. > JP. > =C2=A0Regards,Wei-Peng =C2=A0 > =C2=A0 > _______________________________________________ > 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 >=20 > -----Inline Attachment Follows----- >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From ietfroll@yahoo.com Thu Jul 28 21:44: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 EA87011E8093 for ; Thu, 28 Jul 2011 21:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.925 X-Spam-Level: X-Spam-Status: No, score=-0.925 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_05=-1.11] 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 xFus1e48nGyZ for ; Thu, 28 Jul 2011 21:44:46 -0700 (PDT) Received: from nm24-vm0.bullet.mail.ne1.yahoo.com (nm24-vm0.bullet.mail.ne1.yahoo.com [98.138.90.34]) by ietfa.amsl.com (Postfix) with SMTP id 9E27311E807F for ; Thu, 28 Jul 2011 21:44:46 -0700 (PDT) Received: from [98.138.90.57] by nm24.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jul 2011 04:44:46 -0000 Received: from [98.138.89.164] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jul 2011 04:44:46 -0000 Received: from [127.0.0.1] by omp1020.mail.ne1.yahoo.com with NNFMP; 29 Jul 2011 04:44:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 204404.52777.bm@omp1020.mail.ne1.yahoo.com Received: (qmail 72644 invoked by uid 60001); 29 Jul 2011 04:44:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311914685; bh=r3KC/RyXCmC3zFQ0aCVyn35xWfJcN3HLprY8d0GnT7k=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=6RvHQR42NphgEKOKflTMLZmWQrqoy0uRQ1E82f3B+VV98F0V7TtwDpeMlbUFvauHbeFNVdt3MGQ0DXjDCbJS7z1TVj6ftx9nKGzE4Ik0J+QTS7nKhW8oZwGgLVzLz/+mut3CEyAa3f1+aBZq314tJ+H7S1123EdnbLbHPMqs6ak= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=NfpDUSFhBb2hoDhsKaloGV7gHXkvx7D0WlJdZ9bIFR/uTtAYl+AsWsz+UJ9t7K0BXjVomGqxxBQhUzgM9IAby9XkcllPi0SGDrsuoWK5bC70z+bwAJ/5/IPjzwb3u5vIiKbCTIv4E2uh21orCCjLNZgbRDzIN5hD5bNOIld3Al4=; X-YMail-OSG: OVoo5BYVM1mkettaCnYvopAX795JS84yUEBpY3YkK1DZs_d yq2TUnelgjmIQWPblZ40nERlGfCQACq1ICZtWK71I_9Np.VRWPIIlHJWwY_L XSePKVIWXkhahK0.MlHp3JkzrYJ7ay9EG.RuyAt9iklrCJgPLRQBIgN1K4Jx RU.QfrimIbrSm.NRyrmyvNGFRsc_v3A6cn.6UukRh0lgbNCkwlod3Glw2IbC xEQKRKjOOehLinXg83BvSlunwvxukRiSCB8H04W9.74Lo4tnUo_ZrhOfxzTF dWRqOLYVCqPPlJSckmgtXX3zhn.c6TET9cUfr8zF_O2qeMauoF1M- Received: from [184.105.135.37] by web113917.mail.gq1.yahoo.com via HTTP; Thu, 28 Jul 2011 21:44:45 PDT X-Mailer: YahooMailClassic/14.0.3 YahooMailWebService/0.8.112.310352 Message-ID: <1311914685.70336.YahooMailClassic@web113917.mail.gq1.yahoo.com> Date: Thu, 28 Jul 2011 21:44:45 -0700 (PDT) From: Ietf Roll To: roll@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Roll] comments on 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: Fri, 29 Jul 2011 04:44:48 -0000 I can be silent no more... Since no one else has really spoken up about the state of this draft I feel that I must... This is the most amazing marketing fluff piece trying to pass itself off as a serious document that I have read in quite a while. With all the hot air I'm surprised that it hasn't risen to RFC status of it's own accord - It shouldn't have needed the WG Chairs to skip standard accepted procedures for promoting WG documents. [Perhaps there is some unseen agenda in their rush to move the document forward without due process.] We have been told that "the IESG" requested it. Really, the entire IESG asked for this doc to jump normal protocol and move forward. I suspect that this an unsubstantiated assertion like much of draft-ietf-roll-applicability-ami-01. It seems to me that an AS should be based on real world experiences but that is not possible since I have seen no actual deployments of RPL. There have been some simulations attempting to show that it works and some laboratory experiments that would indicate it might work - there are other experiments that also show that it doesn't seem to perform as expected. One academic paper written by some of the authors of the RPL ID (BTW it is not yet an RFC) clearly states that RPL should be limited to 30 node networks. This seems far less than requirement listed in the this document - e.g. 100s to 10000s nodes - for AMI networks. On that topic it seems that the authors of this draft have confused AMI with AMR. Where AMR networks are primarily MP2P (unidirectional) which RPL might do well and might scale (if it weren't for the need of sending back ACKs and the lossy nature of RF networks), AMI networks are truly bidirectional with as many, if not more, messages flowing to the meter and home as away. Here RPL is known to be severely lacking. In fact the whole idea of packets flowing down a DAG (isn't that an Oxymoron) was an after-thought as evidenced by the fact that multiple other drafts had to be written to make RPL work in a downward direction. Before this WG moves this draft forward I would request that we see more than assertions and claims that RPL can perform as "designed" (I use that term loosely). The draft "says" RPL was designed to meet all the requirements in the various routing requirement use cases. This is a claim that is simple to make but where has it been shown to be true or proved. Where is there an urban, home, industrial or commercial building implementation - any real product, running code - to show that any of these claims are in fact true or just baseless wishful thinking. This would seem a critical piece for any AS and part of a proper procedure but, as we all know, when have the Chairs ever acted on proper procedure in the Working Group. Certainly not all the way back on the issues of IPR disclosures, nor the rush to push out the ID to the IETF, the abandonment of the only draft that tried to justify the work in the first place, ... So would I or why should we expect it now. I have gone on too long in this message. I will get to the factual problems (like mixing up AMI and AMR) in my next message. Thoroughly fed up, RAV From wei-peng.chen@us.fujitsu.com Thu Jul 28 22:08:02 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 2138C11E809C for ; Thu, 28 Jul 2011 22:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.082 X-Spam-Level: X-Spam-Status: No, score=-105.082 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 LhBlR7phmAXZ for ; Thu, 28 Jul 2011 22:08:01 -0700 (PDT) Received: from fujitsu25.fnanic.fujitsu.com (fujitsu25.fnanic.fujitsu.com [192.240.6.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3385511E8093 for ; Thu, 28 Jul 2011 22:08:01 -0700 (PDT) Received: from pps.filterd (fujitsu25 [127.0.0.1]) by fujitsu25.fnanic.fujitsu.com (8.14.4/8.14.4) with SMTP id p6T580iN014096; Thu, 28 Jul 2011 22:08:00 -0700 Received: from fujitsuii.fna.fujitsu.com ([133.164.253.2]) by fujitsu25.fnanic.fujitsu.com with ESMTP id xtqt28sgr-1; Thu, 28 Jul 2011 22:08:00 -0700 Received: from toyama.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsuii.fna.fujitsu.com (8.13.8/8.13.8) with ESMTP id p6T57xDr028425; Thu, 28 Jul 2011 22:07:59 -0700 (PDT) Received: from chenvista (localhost [127.0.0.1]) by toyama.fla.fujitsu.com (8.11.6+Sun/8.11.6) with ESMTP id p6T57uJ01001; Thu, 28 Jul 2011 22:07:57 -0700 (PDT) From: "Wei-Peng Chen" To: "'C Chauvenet'" References: <007201cc4d8e$1c8fe970$55afbc50$@chen@us.fujitsu.com> <41056996-1B3B-4C81-84BD-D0F3950B067A@watteco.com> In-Reply-To: <41056996-1B3B-4C81-84BD-D0F3950B067A@watteco.com> Date: Thu, 28 Jul 2011 22:09:03 -0700 Message-ID: <008901cc4dad$a33210b0$e9963210$@chen@us.fujitsu.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008A_01CC4D72.F6D338B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxNmSGFqqxiZc9yQQiW5ae8cfFhbAAEFHiQ Content-Language: en-us X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-07-28_06:2011-07-29, 2011-07-28, 1970-01-01 signatures=0 Cc: roll@ietf.org Subject: Re: [Roll] Need quantitative requirements in 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: Fri, 29 Jul 2011 05:08:02 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_008A_01CC4D72.F6D338B0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi C=E9dric, =20 I never attended OpenSG before. But according to my colleague who = attended OpenSG before, there are many representatives from major utilities in = the states.=20 I participated in IEEE P2030 briefly and part of the requirements are contributed by utility experts. BTW, I also agree with Don=92s comment. =20 Regards, Wei-Peng =20 From: C Chauvenet [mailto:c.chauvenet@watteco.com]=20 Sent: Thursday, July 28, 2011 7:42 PM To: Wei-Peng Chen Cc: Daniel.Popa@itron.com; roll@ietf.org Subject: Re: [Roll] Need quantitative requirements in draft-ietf-roll-applicability-ami-01 =20 Hi Wei-Peng =20 This would be indeed usefull informations. =20 The document you pointed out gives usefull and very precise = requirements. =20 But, I'm wondering if this specification could be taken as a global rule = for most of AMI applications. =20 As I'm not a SmartGrid expert, is this specification approved by most of = the AMI actors ? =20 C=E9dric. =20 Le 28 juil. 2011 =E0 21:23, Wei-Peng Chen a =E9crit : Hi Daniel, =20 To judge the applicability of RPL in AMI networks, in my opinion, we = need to specify a few key quantitative requirements of AMI networks. But I = cannot find quantitative requirements in neither your ID and RFC5548. Do you = think whether we should specify some key requirements such as: - What is the interval each meter reports its reading? - The quantitative requirements for the latency, reliability, packet payload, etc. of UL/DL connections, in particular DL connections such as demand response, distribution automation. (You can find those numbers specified in UCAIAG=92s SG Network System Requirements Specification and IEEE P2030 specification.) If I miss any previous draft which has already covered these = quantitative requirements, please let me know. =20 Regards, Wei-Peng =20 =20 =20 ------=_NextPart_000_008A_01CC4D72.F6D338B0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi C=E9dric,

 

I never attended OpenSG before. But according to my colleague who = attended OpenSG before, there are many representatives from major = utilities in the states.

I participated in IEEE P2030 briefly and part of the requirements are = contributed by utility experts.

BTW, I also agree with Don=92s comment.

 

Regards,

Wei-Peng

 

From:= = C Chauvenet [mailto:c.chauvenet@watteco.com]
Sent: Thursday, = July 28, 2011 7:42 PM
To: Wei-Peng Chen
Cc: = Daniel.Popa@itron.com; roll@ietf.org
Subject: Re: [Roll] Need = quantitative requirements in = draft-ietf-roll-applicability-ami-01

 

Hi = Wei-Peng

 

This would be indeed usefull = informations.

 

The document you pointed out gives usefull and very = precise requirements.

 

But, I'm wondering if this specification could be = taken as a global rule for most of AMI = applications.

 

As I'm not a SmartGrid expert, is this = specification approved by most of the AMI actors = ?

 

C=E9dric.

 

Le = 28 juil. 2011 =E0 21:23, Wei-Peng Chen a =E9crit = :



Hi Daniel,

 

To judge the applicability of RPL in AMI networks, in my opinion, we = need to specify a few key quantitative requirements of AMI networks. But = I cannot find quantitative requirements in neither your ID and RFC5548. = Do you think whether we should specify some key requirements such = as:

- What is the interval each meter reports its reading?

- The quantitative requirements for the latency, reliability, packet = payload, etc. of UL/DL connections, in particular DL connections such as = demand response, distribution automation. (You can find those numbers = specified in UCAIAG=92sSG Network System = Requirements Specification and IEEE P2030 = specification.)

If I miss any previous draft which has already covered these = quantitative requirements, please let me know.

 

Regards,

Wei-Peng

 

 

<ATT00= 001..txt>

 

------=_NextPart_000_008A_01CC4D72.F6D338B0-- From wei-peng.chen@us.fujitsu.com Thu Jul 28 22:08: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 A0B1811E80A6 for ; Thu, 28 Jul 2011 22:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.116 X-Spam-Level: X-Spam-Status: No, score=-105.116 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 3nDaaOKfFuxV for ; Thu, 28 Jul 2011 22:08:11 -0700 (PDT) Received: from fujitsu25.fnanic.fujitsu.com (fujitsu25.fnanic.fujitsu.com [192.240.6.15]) by ietfa.amsl.com (Postfix) with ESMTP id B710B11E8075 for ; Thu, 28 Jul 2011 22:08:11 -0700 (PDT) Received: from pps.filterd (fujitsu25 [127.0.0.1]) by fujitsu25.fnanic.fujitsu.com (8.14.4/8.14.4) with SMTP id p6T58BLi014780; Thu, 28 Jul 2011 22:08:11 -0700 Received: from fujitsuii.fna.fujitsu.com ([133.164.253.2]) by fujitsu25.fnanic.fujitsu.com with ESMTP id xtqt28sgs-1; Thu, 28 Jul 2011 22:08:11 -0700 Received: from toyama.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsuii.fna.fujitsu.com (8.13.8/8.13.8) with ESMTP id p6T58AiF028428; Thu, 28 Jul 2011 22:08:10 -0700 (PDT) Received: from chenvista (localhost [127.0.0.1]) by toyama.fla.fujitsu.com (8.11.6+Sun/8.11.6) with ESMTP id p6T588J01007; Thu, 28 Jul 2011 22:08:08 -0700 (PDT) From: "Wei-Peng Chen" To: "'Ietf Roll'" , "'Thomas Heide Clausen'" , "'JP Vasseur'" References: <1311914243.47928.YahooMailClassic@web113913.mail.gq1.yahoo.com> In-Reply-To: <1311914243.47928.YahooMailClassic@web113913.mail.gq1.yahoo.com> Date: Thu, 28 Jul 2011 22:09:14 -0700 Message-ID: <008e01cc4dad$a9d48560$fd7d9020$@chen@us.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxNqTfthO11lTsSS96W+044e7X8nwAAbQWg Content-Language: en-us X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-07-28_06:2011-07-29, 2011-07-28, 1970-01-01 signatures=0 Cc: roll@ietf.org Subject: Re: [Roll] Need quantitative requirements in 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: Fri, 29 Jul 2011 05:08:12 -0000 Hi JP, As I am a newbie to IETF, what I said may not make sense to the = community. And I appreciate your comment. =20 However, I agree with Thomas and Ietf that traffic patterns of the = targeted applications and communication environments are important to = understand the applicability of a given routing protocol. We need to = consider any quantitative requirements specified by utilities. In = particular, meters, once installed, would last for 20+ years. It is = important to consider the requirements of the potential applications in = the near future.=20 Regards, Wei-Peng =20 =20 -----Original Message----- From: Ietf Roll [mailto:ietfroll@yahoo.com]=20 Sent: Thursday, July 28, 2011 9:37 PM To: Thomas Heide Clausen; JP Vasseur Cc: roll@ietf.org; Wei-Peng Chen Subject: Re: [Roll] Need quantitative requirements in = draft-ietf-roll-applicability-ami-01 This is what you are saying now in your revisionist history, but = certainly not what you said. It is important to understand the total communications environment that = the routing protocol must work in or do you forget the now abandoned = draft on protocol survey made a big deal about the routing maintenance = overhead (as computed by comparing data vs maintenance packets.) If I'm only sending a packet once in a long while and latency isn't an = issue I could search for path on each packet, could I not. In a "good" applicability statement it would seem beneficial to well = specify the network you are claiming applicability to. --- On Fri, 7/29/11, JP Vasseur wrote: > From: JP Vasseur > Subject: Re: [Roll] Need quantitative requirements in = draft-ietf-roll-applicability-ami-01 > To: "Thomas Heide Clausen" > Cc: "roll@ietf.org" , "Wei-Peng Chen" = > Date: Friday, July 29, 2011, 4:03 AM >=20 > On Jul 28, 2011, at 11:22 PM, Thomas Heide > Clausen wrote: >=20 >=20 >=20 > On 28 Jul 2011, at 22:36, JP Vasseur > wrote: >=20 > Dear > Wei-Peng, > On Jul 28, 2011, at 9:23 PM, Wei-Peng Chen > wrote: > Hi Daniel, To judge the applicability of RPL in AMI networks, in > my opinion, we need to specify a few key quantitative > requirements of AMI networks. But I cannot find quantitative > requirements in neither your ID and RFC5548. Do you think > whether we should specify some key requirements such > as:- What is the interval each meter reports its > reading?- The quantitative requirements for the latency, > reliability, packet payload, etc. of UL/DL connections, in > particular DL connections such as demand response, > distribution automation. (You can find those numbers > specified in UCAIAG=E2=80=99s SG > Network System Requirements Specification and > IEEE P2030 specification.)If I miss any previous draft which has = already > covered these quantitative requirements, please let me > know. > Just an important clarification: this is an RPL > applicability statement, thus many of the items list > aboveare out of the scope of such a > document. >=20 > Just to clarify, you are saying that RPL is not > applicable for AMI, and therefore these considerations are > out of scope. I agree with that,. >=20 > Thomas, where do you see that I said this > ?I said that "interval each meter reports > its reading", "packet payload", =E2=80=A6 are not > routing parameters, thus there are of the scope of > this document, which is a RPL AMI applicability statement. > In other words, the objective is to explain how RPL can be > used for AMI purposes. Non routing related issues are thus > out of the scope. I am just stating the obvious > here. > Thanks. > JP. >=20 > I, then, wonder > why draft-ietf-roll-applicability-ami exists as WG > document - as you say that AMI is out of scope for > RPL. > Thomas >=20 > Thanks. > JP. > Regards,Wei-Peng =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 >=20 > -----Inline Attachment Follows----- >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From jpv@cisco.com Fri Jul 29 04:45: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 9325721F85A0 for ; Fri, 29 Jul 2011 04:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.292 X-Spam-Level: X-Spam-Status: No, score=-102.292 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 nZnD6Y3j3-K7 for ; Fri, 29 Jul 2011 04:45:50 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 478CD21F8571 for ; Fri, 29 Jul 2011 04:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=12471; q=dns/txt; s=iport; t=1311939950; x=1313149550; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=jnFB2e3wah0C/XE9C30EeB+VOsUMVnlobho1HYJpzW8=; b=Q+2uiZVCNUQRaWaQkZ4E25/O8HYXV4VRBZif6krgQCUzbhXPWYL6DsYa qWOEEU/NbwfAT42MvzfDYD4FdcRAuAIKnvZoRJVu6BRrU0PJYnvhg4ZJV aa/hvkXxZf+wReaL+ipu4e5Ccfehs3BQT29MDGTZOe1aIS3+q7PtFU9eB k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUBABadMk6rRDoJ/2dsb2JhbAA0AQEBAQIBAQEBEQEIFkcLBQcFDBEDAQEBATMHFBggAw4IBxcZDpdtD49Id4h8BKEqnkWFYl8EknqFBgmEW4cV X-IronPort-AV: E=Sophos;i="4.67,287,1309737600"; d="scan'208,217";a="7746450" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-9.cisco.com with ESMTP; 29 Jul 2011 11:45:35 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6TBjZHZ019524; Fri, 29 Jul 2011 11:45:35 GMT Received: from xfe-sjc-232.amer.cisco.com ([128.107.191.79]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Jul 2011 04:45:35 -0700 Received: from [10.255.254.166] ([10.21.123.236]) by xfe-sjc-232.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jul 2011 04:45:34 -0700 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_CB742F8C-498F-490D-998D-7FD1868ABB81" From: JP Vasseur In-Reply-To: <008e01cc4dad$a9d48560$fd7d9020$@chen@us.fujitsu.com> Date: Fri, 29 Jul 2011 07:45:32 -0400 Message-Id: <8FF2B614-F54B-41FC-B5CA-10266936E610@cisco.com> References: <1311914243.47928.YahooMailClassic@web113913.mail.gq1.yahoo.com> <008e01cc4dad$a9d48560$fd7d9020$@chen@us.fujitsu.com> To: "Wei-Peng Chen" X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 29 Jul 2011 11:45:34.0530 (UTC) FILETIME=[06E32220:01CC4DE5] Cc: roll@ietf.org, Thomas Heide Clausen Subject: Re: [Roll] Need quantitative requirements in 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: Fri, 29 Jul 2011 11:45:51 -0000 --Apple-Mail=_CB742F8C-498F-490D-998D-7FD1868ABB81 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, On Jul 29, 2011, at 1:09 AM, Wei-Peng Chen wrote: > Hi JP, >=20 > As I am a newbie to IETF, what I said may not make sense to the = community. And I appreciate your comment.=20 >=20 Thanks for understanding, and your comments are very much welcome and = appreciated. > However, I agree with Thomas and Ietf that traffic patterns of the = targeted applications and communication environments are important to = understand the applicability of a given routing protocol. We need to = consider any quantitative requirements specified by utilities. In = particular, meters, once installed, would last for 20+ years. It is = important to consider the requirements of the potential applications in = the near future. >=20 You see what I meant, the objective here is to make sure that we limit = the scope to the routing aspects, that's all, this is why I took the example of "packet load", please = continue to comment, this does help. Thanks. JP. >=20 > Regards, > Wei-Peng =20 >=20 > -----Original Message----- > From: Ietf Roll [mailto:ietfroll@yahoo.com] > Sent: Thursday, July 28, 2011 9:37 PM > To: Thomas Heide Clausen; JP Vasseur > Cc: roll@ietf.org; Wei-Peng Chen > Subject: Re: [Roll] Need quantitative requirements in = draft-ietf-roll-applicability-ami-01 >=20 > This is what you are saying now in your revisionist history, but = certainly not what you said. >=20 > It is important to understand the total communications environment = that the routing protocol must work in or do you forget the now = abandoned draft on protocol survey made a big deal about the routing = maintenance overhead (as computed by comparing data vs maintenance = packets.) >=20 > If I'm only sending a packet once in a long while and latency isn't an = issue I could search for path on each packet, could I not. >=20 > In a "good" applicability statement it would seem beneficial to well = specify the network you are claiming applicability to. >=20 >=20 > --- On Fri, 7/29/11, JP Vasseur wrote: >=20 > > From: JP Vasseur > > Subject: Re: [Roll] Need quantitative requirements in = draft-ietf-roll-applicability-ami-01 > > To: "Thomas Heide Clausen" > > Cc: "roll@ietf.org" , "Wei-Peng Chen" = > > Date: Friday, July 29, 2011, 4:03 AM > > > > On Jul 28, 2011, at 11:22 PM, Thomas Heide > > Clausen wrote: > > > > > > > > On 28 Jul 2011, at 22:36, JP Vasseur > > wrote: > > > > Dear > > Wei-Peng, > > On Jul 28, 2011, at 9:23 PM, Wei-Peng Chen > > wrote: > > Hi Daniel, To judge the applicability of RPL in AMI networks, in > > my opinion, we need to specify a few key quantitative > > requirements of AMI networks. But I cannot find quantitative > > requirements in neither your ID and RFC5548. Do you think > > whether we should specify some key requirements such > > as:- What is the interval each meter reports its > > reading?- The quantitative requirements for the latency, > > reliability, packet payload, etc. of UL/DL connections, in > > particular DL connections such as demand response, > > distribution automation. (You can find those numbers > > specified in UCAIAG=92s SG > > Network System Requirements Specification and > > IEEE P2030 specification.)If I miss any previous draft which has = already > > covered these quantitative requirements, please let me > > know. > > Just an important clarification: this is an RPL > > applicability statement, thus many of the items list > > aboveare out of the scope of such a > > document. > > > > Just to clarify, you are saying that RPL is not > > applicable for AMI, and therefore these considerations are > > out of scope. I agree with that,. > > > > Thomas, where do you see that I said this > > ?I said that "interval each meter reports > > its reading", "packet payload", =85 are not > > routing parameters, thus there are of the scope of > > this document, which is a RPL AMI applicability statement. > > In other words, the objective is to explain how RPL can be > > used for AMI purposes. Non routing related issues are thus > > out of the scope. I am just stating the obvious > > here. > > Thanks. > > JP. > > > > I, then, wonder > > why draft-ietf-roll-applicability-ami exists as WG > > document - as you say that AMI is out of scope for > > RPL. > > Thomas > > > > Thanks. > > JP. > > Regards,Wei-Peng=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 > > > > > > -----Inline Attachment Follows----- > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > >=20 >=20 --Apple-Mail=_CB742F8C-498F-490D-998D-7FD1868ABB81 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
RE: [Roll] Need quantitative requirements in = draft-ietf-roll-applicability-ami-01

Hi JP,

As I am a newbie to IETF, what I said may not make sense to the = community. And I appreciate your comment. 

Thanks for understanding, and your = comments are very much welcome and appreciated.

However, I agree with Thomas and = Ietf that traffic patterns of the targeted applications and = communication environments are important to understand the applicability = of a given routing protocol. We need to consider any quantitative = requirements specified by utilities. In particular, meters, once = installed, would last for 20+ years. It is important to consider the = requirements of the potential applications in the near = future.

You see what I meant, the = objective here is to make sure that we limit the scope to the routing = aspects,
that's all, this is why I took the example of "packet = load", please continue to comment, this does = help.

Thanks.

JP.


Regards,
Wei-Peng  

-----Original Message-----
From: Ietf Roll [mailto:ietfroll@yahoo.com]
Sent: Thursday, July 28, 2011 9:37 PM
To: Thomas Heide Clausen; JP Vasseur
Cc: roll@ietf.org; Wei-Peng = Chen
Subject: Re: [Roll] Need quantitative requirements in = draft-ietf-roll-applicability-ami-01

This is what you are saying now in your revisionist history, but = certainly not what you said.

It is important to understand the total communications environment that = the routing protocol must work in or do you forget the now abandoned = draft on protocol survey made a big deal about the routing maintenance = overhead (as computed by comparing data vs maintenance packets.)

If I'm only sending a packet once in a long while and latency isn't an = issue I could search for path on each packet, could I not.

In a "good" applicability statement it would seem beneficial to well = specify the network you are claiming applicability to.


--- On Fri, 7/29/11, JP Vasseur <jpv@cisco.com> wrote:

> From: JP Vasseur <jpv@cisco.com>
> Subject: Re: [Roll] Need quantitative requirements in = draft-ietf-roll-applicability-ami-01
> To: "Thomas Heide Clausen" <Thomas@ThomasClausen.org><= br> > Cc: "roll@ietf.org" <roll@ietf.org>, "Wei-Peng Chen" = <wei-peng.chen@us.fujitsu.com<= /a>>
> Date: Friday, July 29, 2011, 4:03 AM
>
> On Jul 28, 2011, at 11:22 PM, Thomas Heide
> Clausen wrote:
>
>
>
> On 28 Jul 2011, at 22:36, JP Vasseur <
jpv@cisco.com>
> wrote:
>
> Dear
> Wei-Peng,
> On Jul 28, 2011, at 9:23 PM, Wei-Peng Chen
> wrote:
> Hi Daniel,  To judge the applicability of RPL in AMI networks, = in
> my opinion, we need to specify a few key quantitative
> requirements of AMI networks. But I cannot find quantitative
> requirements in neither your ID and RFC5548. Do you think
> whether we should specify some key requirements such
> as:- What is the interval each meter reports its
> reading?- The quantitative requirements for the latency,
> reliability, packet payload, etc. of UL/DL connections, in
> particular DL connections such as demand response,
> distribution automation. (You can find those numbers
> specified in UCAIAG=92s SG
> Network System Requirements Specification and
> IEEE P2030 specification.)If I miss any previous draft which has = already
> covered these quantitative requirements, please let me
> know.
> Just an important clarification: this is an RPL
> applicability statement, thus many of the items list
> aboveare out of the scope of such a
> document.
>
> Just to clarify, you are saying that RPL is not
> applicable for AMI, and therefore these considerations are
> out of scope. I agree with that,.
>
> Thomas, where do you see that I said this
> ?I said that "interval each meter reports
> its reading", "packet payload", =85 are not
> routing parameters, thus there are of the scope of
> this document, which is a RPL AMI applicability statement.
> In other words, the objective is to explain how RPL can be
> used for AMI purposes. Non routing related issues are thus
> out of the scope. I am just stating the obvious
> here.
> Thanks.
> JP.
>
> I, then, wonder
> why draft-ietf-roll-applicability-ami exists as WG
> document - as you say that AMI is out of scope for
> RPL.
> Thomas
>
> Thanks.
> JP.
>   Regards,Wei-Peng 

> _______________________________________________
> 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
>
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/m= ailman/listinfo/roll
>


= --Apple-Mail=_CB742F8C-498F-490D-998D-7FD1868ABB81-- From jpv@cisco.com Fri Jul 29 04:57: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 BDDC921F8B89 for ; Fri, 29 Jul 2011 04:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.353 X-Spam-Level: X-Spam-Status: No, score=-102.353 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 f4YrdCqJkQ+u for ; Fri, 29 Jul 2011 04:57:12 -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 9546021F8B4C for ; Fri, 29 Jul 2011 04:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=13601; q=dns/txt; s=iport; t=1311940632; x=1313150232; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=7KfhY5ZCT7GqwsZNf0+rj9lpetZ8PxnHt8GCHnSVvTw=; b=Q1M90KWfc2f1to5lUoDIkthMZjxcBH/R6LUw/VPnSGj/gaEW8KQF+1VG G31FW5WzuoGriQZDJbsXBobmbeCw7o5MOKSg3Pujgxq4BdqPrFDbYl18u tz120UDaNvtWfaYq+Q/J/u7DLfcfizA/OBKCUooqmdpYlVG8lIdbCRQ9/ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAM2eMk6rRDoJ/2dsb2JhbAA0AQEBAQIBAQEBEQFlCwUMDBg6FBg5BxcngjalDneIfAShQZ5FhWJfBJJ6hQYJi3A X-IronPort-AV: E=Sophos;i="4.67,287,1309737600"; d="scan'208,217";a="7748243" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-2.cisco.com with ESMTP; 29 Jul 2011 11:57:11 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6TBv9Dw028216; Fri, 29 Jul 2011 11:57:09 GMT Received: from xfe-sjc-231.amer.cisco.com ([128.107.191.114]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Jul 2011 04:57:09 -0700 Received: from [10.255.254.166] ([10.21.123.236]) by xfe-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Jul 2011 04:56:48 -0700 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_B3E1654F-E07E-4150-9D7F-4F412E059874" From: JP Vasseur In-Reply-To: <651AEDF5-B195-40B7-B5E6-EDF5F78A12EE@ThomasClausen.org> Date: Fri, 29 Jul 2011 07:46:38 -0400 Message-Id: <4BE3AF83-DDFC-4DCC-A521-9497BB384D37@cisco.com> References: <007201cc4d8e$1c8fe970$55afbc50$@chen@us.fujitsu.com> <86CDEBEF-340A-4152-9D8E-71448EDC99D9@thomasclausen.org> <651AEDF5-B195-40B7-B5E6-EDF5F78A12EE@ThomasClausen.org> To: "Thomas Heide Clausen" X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 29 Jul 2011 11:56:49.0003 (UTC) FILETIME=[98E78BB0:01CC4DE6] Cc: roll@ietf.org, Wei-Peng Chen Subject: Re: [Roll] Need quantitative requirements in 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: Fri, 29 Jul 2011 11:57:13 -0000 --Apple-Mail=_B3E1654F-E07E-4150-9D7F-4F412E059874 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 29, 2011, at 12:27 AM, Thomas Heide Clausen wrote: >=20 > On Jul 29, 2011, at 00:03 , JP Vasseur wrote: >=20 >>=20 >> On Jul 28, 2011, at 11:22 PM, Thomas Heide Clausen wrote: >>=20 >>>=20 >>>=20 >>>=20 >>> On 28 Jul 2011, at 22:36, JP Vasseur wrote: >>>=20 >>>> Dear Wei-Peng, >>>>=20 >>>> On Jul 28, 2011, at 9:23 PM, Wei-Peng Chen wrote: >>>>=20 >>>>> Hi Daniel, >>>>> =20 >>>>> To judge the applicability of RPL in AMI networks, in my opinion, = we need to specify a few key quantitative requirements of AMI networks. = But I cannot find quantitative requirements in neither your ID and = RFC5548. Do you think whether we should specify some key requirements = such as: >>>>> - What is the interval each meter reports its reading? >>>>> - The quantitative requirements for the latency, reliability, = packet payload, etc. of UL/DL connections, in particular DL connections = such as demand response, distribution automation. (You can find those = numbers specified in UCAIAG=92s SG Network System Requirements = Specification and IEEE P2030 specification.) >>>>> If I miss any previous draft which has already covered these = quantitative requirements, please let me know. >>>>=20 >>>> Just an important clarification: this is an RPL applicability = statement, thus many of the items list above >>>> are out of the scope of such a document. >>>>=20 >>>=20 >>> Just to clarify, you are saying that RPL is not applicable for AMI, = and therefore these considerations are out of scope. I agree with that,. >>>=20 >>=20 >> Thomas, where do you see that I said this ? >> I said that "interval each meter reports its reading", "packet = payload", =85 are not routing parameters, thus there are of the scope of = this document, which is a RPL AMI applicability statement. In other = words, the objective is to explain how RPL can be used for AMI purposes. = Non routing related issues are thus out of the scope. I am just stating = the obvious here. >>=20 >=20 > Traffic patterns are important to understand the applicability (if = any) of a given routing protocol. The "interval" is not a traffic pattern. JP. > I am also just stating the obvious here. >=20 > Thomas >=20 >> Thanks. >>=20 >> JP. >>=20 >>=20 >>> I, then, wonder why draft-ietf-roll-applicability-ami exists as WG = document - as you say that AMI is out of scope for RPL. >>>=20 >>> Thomas >>>=20 >>>> Thanks. >>>>=20 >>>> JP. >>>>=20 >>>>> =20 >>>>> Regards, >>>>> Wei-Peng >>>>> =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 >=20 --Apple-Mail=_B3E1654F-E07E-4150-9D7F-4F412E059874 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

On Jul 29, = 2011, at 00:03 , JP Vasseur wrote:


On Jul 28, 2011, = at 11:22 PM, Thomas Heide Clausen wrote:




On 28 Jul = 2011, at 22:36, JP Vasseur <jpv@cisco.com> = wrote:

Dear = Wei-Peng,

On Jul 28, 2011, at 9:23 PM, Wei-Peng Chen = wrote:

Hi = Daniel,
To judge = the applicability of RPL in AMI networks, in my opinion, we need to = specify a few key quantitative requirements of AMI networks. But I = cannot find quantitative requirements in neither your ID and RFC5548. Do = you think whether we should specify some key requirements such = as:
- What is the = interval each meter reports its reading?
- The quantitative requirements for the latency, = reliability, packet payload, etc. of UL/DL connections, in particular DL = connections such as demand response, distribution automation. (You can = find those numbers specified in UCAIAG=92s SG Network System Requirements Specification and IEEE P2030 = specification.)
If I miss = any previous draft which has already covered these quantitative = requirements, please let me know.
routing = parameters, thus there are of the scope of this document, which is a RPL = AMI applicability statement. In other words, the objective is to explain = how RPL can be used for AMI purposes. Non routing related issues are = thus out of the scope. I am just stating the obvious = here.


Traffic = patterns are important to understand the applicability (if any) of a = given routing protocol.

The = "interval" is not a traffic = pattern.

JP.

I am also just = stating the obvious = here.

Thomas

I, then, wonder = why draft-ietf-roll-applicability-ami exists as WG document - as = you say that AMI is out of scope for = RPL.

Thomas



= --Apple-Mail=_B3E1654F-E07E-4150-9D7F-4F412E059874-- From jpv@cisco.com Fri Jul 29 04:59: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 5E90321F8B96 for ; Fri, 29 Jul 2011 04:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 n-9X5ZSKWn6W for ; Fri, 29 Jul 2011 04:59:22 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6C08821F8B93 for ; Fri, 29 Jul 2011 04:59:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=13601; q=dns/txt; s=iport; t=1311940762; x=1313150362; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=4RjvKBiQ8+J9+9X+e8PAKNcOTXTisn6rI503Q7rQPcM=; b=imyrmJYlRm2CxnkUGbRbuuyVYF4YlV21xoq22BY7posBJUiJVa4zeZQx YJTKag5Z+aSYG6M5eb7HjdXBRlAPOOmafIsDr3htB8V1mBmkL0DQ4FEVt nkzmf6GJJ53+5Fm4EcR5LSjmvwYwxUgxdKH8kAaKZcWpPknHpd9J4RCPP 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHGfMk6rRDoG/2dsb2JhbAA0AQEBAQIBAQEBEQFlCwUMDBg6FBg5BxcngjalDneIfAShSZ5FhWJfBJJ6hQYJi3A X-IronPort-AV: E=Sophos;i="4.67,287,1309737600"; d="scan'208,217";a="7753314" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-7.cisco.com with ESMTP; 29 Jul 2011 11:59:21 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6TBxLp9032576; Fri, 29 Jul 2011 11:59:21 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Jul 2011 04:59:20 -0700 Received: from [10.255.254.166] ([10.21.123.236]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Jul 2011 04:59:17 -0700 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_DA524F44-0C21-4A2E-BB29-1E1D6B0BD192" From: JP Vasseur In-Reply-To: <651AEDF5-B195-40B7-B5E6-EDF5F78A12EE@ThomasClausen.org> Date: Fri, 29 Jul 2011 07:56:51 -0400 Message-Id: <477BB90F-A074-4C8E-B602-1472CCC1472C@cisco.com> References: <007201cc4d8e$1c8fe970$55afbc50$@chen@us.fujitsu.com> <86CDEBEF-340A-4152-9D8E-71448EDC99D9@thomasclausen.org> <651AEDF5-B195-40B7-B5E6-EDF5F78A12EE@ThomasClausen.org> To: "Thomas Heide Clausen" X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 29 Jul 2011 11:59:18.0403 (UTC) FILETIME=[F1F42D30:01CC4DE6] Cc: roll@ietf.org, Wei-Peng Chen Subject: Re: [Roll] Need quantitative requirements in 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: Fri, 29 Jul 2011 11:59:23 -0000 --Apple-Mail=_DA524F44-0C21-4A2E-BB29-1E1D6B0BD192 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 29, 2011, at 12:27 AM, Thomas Heide Clausen wrote: >=20 > On Jul 29, 2011, at 00:03 , JP Vasseur wrote: >=20 >>=20 >> On Jul 28, 2011, at 11:22 PM, Thomas Heide Clausen wrote: >>=20 >>>=20 >>>=20 >>>=20 >>> On 28 Jul 2011, at 22:36, JP Vasseur wrote: >>>=20 >>>> Dear Wei-Peng, >>>>=20 >>>> On Jul 28, 2011, at 9:23 PM, Wei-Peng Chen wrote: >>>>=20 >>>>> Hi Daniel, >>>>> =20 >>>>> To judge the applicability of RPL in AMI networks, in my opinion, = we need to specify a few key quantitative requirements of AMI networks. = But I cannot find quantitative requirements in neither your ID and = RFC5548. Do you think whether we should specify some key requirements = such as: >>>>> - What is the interval each meter reports its reading? >>>>> - The quantitative requirements for the latency, reliability, = packet payload, etc. of UL/DL connections, in particular DL connections = such as demand response, distribution automation. (You can find those = numbers specified in UCAIAG=92s SG Network System Requirements = Specification and IEEE P2030 specification.) >>>>> If I miss any previous draft which has already covered these = quantitative requirements, please let me know. >>>>=20 >>>> Just an important clarification: this is an RPL applicability = statement, thus many of the items list above >>>> are out of the scope of such a document. >>>>=20 >>>=20 >>> Just to clarify, you are saying that RPL is not applicable for AMI, = and therefore these considerations are out of scope. I agree with that,. >>>=20 >>=20 >> Thomas, where do you see that I said this ? >> I said that "interval each meter reports its reading", "packet = payload", =85 are not routing parameters, thus there are of the scope of = this document, which is a RPL AMI applicability statement. In other = words, the objective is to explain how RPL can be used for AMI purposes. = Non routing related issues are thus out of the scope. I am just stating = the obvious here. >>=20 >=20 > Traffic patterns are important to understand the applicability (if = any) of a given routing protocol. The "interval" is not a traffic pattern. JP. > I am also just stating the obvious here. >=20 > Thomas >=20 >> Thanks. >>=20 >> JP. >>=20 >>=20 >>> I, then, wonder why draft-ietf-roll-applicability-ami exists as WG = document - as you say that AMI is out of scope for RPL. >>>=20 >>> Thomas >>>=20 >>>> Thanks. >>>>=20 >>>> JP. >>>>=20 >>>>> =20 >>>>> Regards, >>>>> Wei-Peng >>>>> =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 >=20 --Apple-Mail=_DA524F44-0C21-4A2E-BB29-1E1D6B0BD192 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

On Jul 29, = 2011, at 00:03 , JP Vasseur wrote:


On Jul 28, 2011, = at 11:22 PM, Thomas Heide Clausen wrote:




On 28 Jul = 2011, at 22:36, JP Vasseur <jpv@cisco.com> = wrote:

Dear = Wei-Peng,

On Jul 28, 2011, at 9:23 PM, Wei-Peng Chen = wrote:

Hi = Daniel,
To judge = the applicability of RPL in AMI networks, in my opinion, we need to = specify a few key quantitative requirements of AMI networks. But I = cannot find quantitative requirements in neither your ID and RFC5548. Do = you think whether we should specify some key requirements such = as:
- What is the = interval each meter reports its reading?
- The quantitative requirements for the latency, = reliability, packet payload, etc. of UL/DL connections, in particular DL = connections such as demand response, distribution automation. (You can = find those numbers specified in UCAIAG=92s SG Network System Requirements Specification and IEEE P2030 = specification.)
If I miss = any previous draft which has already covered these quantitative = requirements, please let me know.
routing = parameters, thus there are of the scope of this document, which is a RPL = AMI applicability statement. In other words, the objective is to explain = how RPL can be used for AMI purposes. Non routing related issues are = thus out of the scope. I am just stating the obvious = here.


Traffic = patterns are important to understand the applicability (if any) of a = given routing protocol.

The = "interval" is not a traffic = pattern.

JP.

I am also just = stating the obvious = here.

Thomas

I, then, wonder = why draft-ietf-roll-applicability-ami exists as WG document - as = you say that AMI is out of scope for = RPL.

Thomas



= --Apple-Mail=_DA524F44-0C21-4A2E-BB29-1E1D6B0BD192-- From jpv@cisco.com Fri Jul 29 04:59: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 418E421F8B96 for ; Fri, 29 Jul 2011 04:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.353 X-Spam-Level: X-Spam-Status: No, score=-102.353 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 5F1oE706BVNy for ; Fri, 29 Jul 2011 04:59:43 -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 D429F21F8B93 for ; Fri, 29 Jul 2011 04:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=13601; q=dns/txt; s=iport; t=1311940783; x=1313150383; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=7KfhY5ZCT7GqwsZNf0+rj9lpetZ8PxnHt8GCHnSVvTw=; b=ONZmIWCVLFKWyNzVER5RLjfh3gIvgnKdhmwAMbcHPFWVb1oUT8SdP9ZU jVsfQQ2zC4JPbDQJ681YNS0MdZodr3Wi3FLMGTMli4onRTyMxhVe6DOXf 6Csqk5F8FbRz8+EvXlPZ6G13oM7Rz9jBkM7CS4BHZ46I/cU6Tj/7JVrOJ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMCfMk6rRDoI/2dsb2JhbAA0AQEBAQIBAQEBEQFlCwUMDBg6FBg5BxcngjalD3eIfAShSZ5FhWJfBJJ6hQYJi3A X-IronPort-AV: E=Sophos;i="4.67,287,1309737600"; d="scan'208,217";a="7748819" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-2.cisco.com with ESMTP; 29 Jul 2011 11:59:42 +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 p6TBxfqM005740; Fri, 29 Jul 2011 11:59:41 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Jul 2011 04:59:41 -0700 Received: from [10.255.254.166] ([10.21.123.236]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Jul 2011 04:46:41 -0700 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_B3E1654F-E07E-4150-9D7F-4F412E059874" From: JP Vasseur In-Reply-To: <651AEDF5-B195-40B7-B5E6-EDF5F78A12EE@ThomasClausen.org> Date: Fri, 29 Jul 2011 07:46:38 -0400 Message-Id: <4BE3AF83-DDFC-4DCC-A521-9497BB384D37@cisco.com> References: <007201cc4d8e$1c8fe970$55afbc50$@chen@us.fujitsu.com> <86CDEBEF-340A-4152-9D8E-71448EDC99D9@thomasclausen.org> <651AEDF5-B195-40B7-B5E6-EDF5F78A12EE@ThomasClausen.org> To: "Thomas Heide Clausen" X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 29 Jul 2011 11:46:41.0593 (UTC) FILETIME=[2EDC2290:01CC4DE5] Cc: roll@ietf.org, Wei-Peng Chen Subject: Re: [Roll] Need quantitative requirements in 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: Fri, 29 Jul 2011 11:59:43 -0000 --Apple-Mail=_B3E1654F-E07E-4150-9D7F-4F412E059874 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 29, 2011, at 12:27 AM, Thomas Heide Clausen wrote: >=20 > On Jul 29, 2011, at 00:03 , JP Vasseur wrote: >=20 >>=20 >> On Jul 28, 2011, at 11:22 PM, Thomas Heide Clausen wrote: >>=20 >>>=20 >>>=20 >>>=20 >>> On 28 Jul 2011, at 22:36, JP Vasseur wrote: >>>=20 >>>> Dear Wei-Peng, >>>>=20 >>>> On Jul 28, 2011, at 9:23 PM, Wei-Peng Chen wrote: >>>>=20 >>>>> Hi Daniel, >>>>> =20 >>>>> To judge the applicability of RPL in AMI networks, in my opinion, = we need to specify a few key quantitative requirements of AMI networks. = But I cannot find quantitative requirements in neither your ID and = RFC5548. Do you think whether we should specify some key requirements = such as: >>>>> - What is the interval each meter reports its reading? >>>>> - The quantitative requirements for the latency, reliability, = packet payload, etc. of UL/DL connections, in particular DL connections = such as demand response, distribution automation. (You can find those = numbers specified in UCAIAG=92s SG Network System Requirements = Specification and IEEE P2030 specification.) >>>>> If I miss any previous draft which has already covered these = quantitative requirements, please let me know. >>>>=20 >>>> Just an important clarification: this is an RPL applicability = statement, thus many of the items list above >>>> are out of the scope of such a document. >>>>=20 >>>=20 >>> Just to clarify, you are saying that RPL is not applicable for AMI, = and therefore these considerations are out of scope. I agree with that,. >>>=20 >>=20 >> Thomas, where do you see that I said this ? >> I said that "interval each meter reports its reading", "packet = payload", =85 are not routing parameters, thus there are of the scope of = this document, which is a RPL AMI applicability statement. In other = words, the objective is to explain how RPL can be used for AMI purposes. = Non routing related issues are thus out of the scope. I am just stating = the obvious here. >>=20 >=20 > Traffic patterns are important to understand the applicability (if = any) of a given routing protocol. The "interval" is not a traffic pattern. JP. > I am also just stating the obvious here. >=20 > Thomas >=20 >> Thanks. >>=20 >> JP. >>=20 >>=20 >>> I, then, wonder why draft-ietf-roll-applicability-ami exists as WG = document - as you say that AMI is out of scope for RPL. >>>=20 >>> Thomas >>>=20 >>>> Thanks. >>>>=20 >>>> JP. >>>>=20 >>>>> =20 >>>>> Regards, >>>>> Wei-Peng >>>>> =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 >=20 --Apple-Mail=_B3E1654F-E07E-4150-9D7F-4F412E059874 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

On Jul 29, = 2011, at 00:03 , JP Vasseur wrote:


On Jul 28, 2011, = at 11:22 PM, Thomas Heide Clausen wrote:




On 28 Jul = 2011, at 22:36, JP Vasseur <jpv@cisco.com> = wrote:

Dear = Wei-Peng,

On Jul 28, 2011, at 9:23 PM, Wei-Peng Chen = wrote:

Hi = Daniel,
To judge = the applicability of RPL in AMI networks, in my opinion, we need to = specify a few key quantitative requirements of AMI networks. But I = cannot find quantitative requirements in neither your ID and RFC5548. Do = you think whether we should specify some key requirements such = as:
- What is the = interval each meter reports its reading?
- The quantitative requirements for the latency, = reliability, packet payload, etc. of UL/DL connections, in particular DL = connections such as demand response, distribution automation. (You can = find those numbers specified in UCAIAG=92s SG Network System Requirements Specification and IEEE P2030 = specification.)
If I miss = any previous draft which has already covered these quantitative = requirements, please let me know.
routing = parameters, thus there are of the scope of this document, which is a RPL = AMI applicability statement. In other words, the objective is to explain = how RPL can be used for AMI purposes. Non routing related issues are = thus out of the scope. I am just stating the obvious = here.


Traffic = patterns are important to understand the applicability (if any) of a = given routing protocol.

The = "interval" is not a traffic = pattern.

JP.

I am also just = stating the obvious = here.

Thomas

I, then, wonder = why draft-ietf-roll-applicability-ami exists as WG document - as = you say that AMI is out of scope for = RPL.

Thomas



= --Apple-Mail=_B3E1654F-E07E-4150-9D7F-4F412E059874-- From Martin.Heusse@imag.fr Fri Jul 29 05:22: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 13CB021F8B31 for ; Fri, 29 Jul 2011 05:22:01 -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 QiRxSZKZnVJ7 for ; Fri, 29 Jul 2011 05:22:00 -0700 (PDT) Received: from shiva.imag.fr (mx1.imag.fr [IPv6:2001:660:5301:6::5]) by ietfa.amsl.com (Postfix) with ESMTP id 0FEB121F8B2A for ; Fri, 29 Jul 2011 05:21:59 -0700 (PDT) Received: from new-heka.imag.fr ([IPv6:2001:660:5301:18:21c:23ff:fed8:d33e]) by shiva.imag.fr (8.13.8/8.13.8) with ESMTP id p6TCLqMC029617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jul 2011 14:21:54 +0200 Received: from [127.0.0.1] (delos.imag.fr [129.88.48.22]) by new-heka.imag.fr (8.13.8/8.13.8/ImagV2.1.pm) with ESMTP id p6TCLsVj024879; Fri, 29 Jul 2011 14:21:54 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Martin Heusse In-Reply-To: <4BE3AF83-DDFC-4DCC-A521-9497BB384D37@cisco.com> Date: Fri, 29 Jul 2011 14:21:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <28156FD8-F1C6-4976-9147-69AA99829660@imag.fr> References: <007201cc4d8e$1c8fe970$55afbc50$@chen@us.fujitsu.com> <86CDEBEF-340A-4152-9D8E-71448EDC99D9@thomasclausen.org> <651AEDF5-B195-40B7-B5E6-EDF5F78A12EE@ThomasClausen.org> <4BE3AF83-DDFC-4DCC-A521-9497BB384D37@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1084) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (shiva.imag.fr [IPv6:2001:660:5301:6::5]); Fri, 29 Jul 2011 14:21:54 +0200 (CEST) X-IMAG-MailScanner-Information: Please contact MI2S MIM for more information X-MailScanner-ID: p6TCLqMC029617 X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-SpamCheck: X-IMAG-MailScanner-From: martin.heusse@imag.fr MailScanner-NULL-Check: 1312546914.56927@WakFucdvpm+1wKnAKkcx9w Cc: roll@ietf.org Subject: Re: [Roll] Need quantitative requirements in 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: Fri, 29 Jul 2011 12:22:01 -0000 For really long intervals between reports, reactive routing would be = better. So the traffic pattern/frequency/structure/incidence/regularity = is somewhat relevant I think.=20 As a side note, i'd think that being able to establish downward routes = to a subset of nodes could be useful (especially for a metering = application), but it seems (...my understanding is that...) RPL = precludes this (unless P2P is used).=20 >> Traffic patterns are important to understand the applicability (if = any) of a given routing protocol. >=20 > The "interval" is not a traffic pattern. >=20 Martin Heusse From yi.jiazi@gmail.com Fri Jul 29 06:18:02 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 622C721F8879 for ; Fri, 29 Jul 2011 06:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 9GGHLxGl+KRy for ; Fri, 29 Jul 2011 06:18:02 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C940721F875E for ; Fri, 29 Jul 2011 06:18:01 -0700 (PDT) Received: by qyk9 with SMTP id 9so3736050qyk.10 for ; Fri, 29 Jul 2011 06:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=iv6c7ePtKnaDsVPWsPPBCK4/ggbz6AnueIKExOGeuug=; b=iu3zKRxvRkZQq8+EXF3EWqYcLalCNcXUbS60PJvWvkXcCBQDRwxDSZbJ5d6nrFYYID Zq6Krf8i1QuizExDBCFv/yIZ3Us59M+3Pm/JaPxr/9Jcq1wczWWAzOvqA00RjqWwWuPY SMg0HNUti3vU7nybMcv51nj+FtGH0LvMuAG28= Received: by 10.229.2.28 with SMTP id 28mr987328qch.103.1311945479713; Fri, 29 Jul 2011 06:17:59 -0700 (PDT) Received: from [130.129.66.253] (dhcp-42fd.meeting.ietf.org [130.129.66.253]) by mx.google.com with ESMTPS id s14sm1361973qct.30.2011.07.29.06.17.58 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jul 2011 06:17:58 -0700 (PDT) References: <007201cc4d8e$1c8fe970$55afbc50$@chen@us.fujitsu.com> <86CDEBEF-340A-4152-9D8E-71448EDC99D9@thomasclausen.org> <651AEDF5-B195-40B7-B5E6-EDF5F78A12EE@ThomasClausen.org> <4BE3AF83-DDFC-4DCC-A521-9497BB384D37@cisco.com> <28156FD8-F1C6-4976-9147-69AA99829660@imag.fr> In-Reply-To: <28156FD8-F1C6-4976-9147-69AA99829660@imag.fr> Mime-Version: 1.0 (iPad Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (8J2) From: Jiazi Yi Date: Fri, 29 Jul 2011 09:19:51 -0400 To: Martin Heusse Cc: "roll@ietf.org" Subject: Re: [Roll] Need quantitative requirements in 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: Fri, 29 Jul 2011 13:18:02 -0000 Agree with Martin. =46rom the "traffic pattern" point of view, the interval o= f the traffic should be considered. Generating 1 packet per month (with is p= ossible in ami), is certainly different from 1 packet in 10 seconds (which i= s also possible).=20 Even regarding the p2mp, p2p patterns, I can see that it is "proposed" in se= ction 2.2, traffic characteristic, with possibly latency requirements, but I= can't tell how those can be properly addressed By reading this document, wh= ich is surely interesting for some of us. Regards Jiazi YI Sent from my iPad On Jul 29, 2011, at 8:21, Martin Heusse wrote: >=20 > For really long intervals between reports, reactive routing would be bette= r. So the traffic pattern/frequency/structure/incidence/regularity is somewh= at relevant I think.=20 >=20 > As a side note, i'd think that being able to establish downward routes to a= subset of nodes could be useful (especially for a metering application), bu= t it seems (...my understanding is that...) RPL precludes this (unless P2P i= s used).=20 >=20 >=20 >>> Traffic patterns are important to understand the applicability (if any) o= f a given routing protocol. >>=20 >> The "interval" is not a traffic pattern. >>=20 >=20 > Martin Heusse >=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From d.sturek@att.net Fri Jul 29 06:19:11 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 3924421F8AEC for ; Fri, 29 Jul 2011 06:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.517 X-Spam-Level: X-Spam-Status: No, score=-0.517 tagged_above=-999 required=5 tests=[AWL=0.551, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, MIME_QP_LONG_LINE=1.396] 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 1T2VG+BqQUT9 for ; Fri, 29 Jul 2011 06:19:09 -0700 (PDT) Received: from nm28-vm0.access.bullet.mail.mud.yahoo.com (nm28-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.229]) by ietfa.amsl.com (Postfix) with SMTP id C918E21F8AD8 for ; Fri, 29 Jul 2011 06:19:08 -0700 (PDT) Received: from [66.94.237.199] by nm28.access.bullet.mail.mud.yahoo.com with NNFMP; 29 Jul 2011 13:19:06 -0000 Received: from [66.94.237.97] by tm10.access.bullet.mail.mud.yahoo.com with NNFMP; 29 Jul 2011 13:19:06 -0000 Received: from [127.0.0.1] by omp1002.access.mail.mud.yahoo.com with NNFMP; 29 Jul 2011 13:19:05 -0000 X-Yahoo-Newman-Id: 996117.77110.bm@omp1002.access.mail.mud.yahoo.com Received: (qmail 62367 invoked from network); 29 Jul 2011 13:19:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1311945545; bh=DXH3NM4sz+a24gCwprHZTLgLrtu3fOMD4TAlB8ANdeE=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type; b=FpSw79K4B1D1iQlJ3LXetNGlVBN+WmNuJkDvVljPZmqgkdlNQVlO5XkfUgABV2uoH8e5rw9nsktbfAdTka2x42M4pBSwAmUGyXBdITc4jngQPM7zRzC/wdq51e2VzxwtO1KzdhLg0te/6nRcQv08bPF6t0Oe72lzXIz6gRmZfsU= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: OXj93CYVM1k5IxGtIP5_7di4sIuvFZl4CQLJZPA537oonXz d7D8matMV2AB7QqHj.2CJc8xXy1.6ZJvLWp5ApNpoNaoSp1NM_k_9_Z4pqG3 6CJUhrKaR2gS9g45R0S7ZOWgAbS0A.pKnRmmqWhIZMQR3P0hDTidS95cg61U wKM4vzPsBeHWrzsHxY3Tr4_P_AuiAu7iS9KHUbbIJzwR6KoQ0uJR4AICKzQx Vk2wZNhV9LhhLeLlXnMOtewI5U189KieDa2l40c8NMVVbR4vBDhkCiGrsj2q FegFsjH0N4wcWMdFFaVSpEeWsyV5vZwRlkSZivF5567oKYzh_WEDA1Iz4_4A JKRSZxkEhWkasOSBUrvbgrCz9SjVfjd_iB5DYVfQWJcQth.UbrDXnC5_iMHs LDqySMY7T69WYWebI0w8VYlvASIpE7yrKgaE3gimxpT0G7IKERZmfWJ2cowz mmz93Yv0pp0NmLqLFaz8tbsmmYY_vOSRkkuaruFQC99yKJoh2C8NomicYgK0 oMS4LsV.QYuSzcUNleN5utSSG7dsbO0HiBDQE6Zwf0zTIzWjHrpYbm3GYaQR imzQ3vIzzV7Vl7hakaocH0A-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.198] (d.sturek@69.105.137.241 with login) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 29 Jul 2011 06:19:05 -0700 PDT User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Fri, 29 Jul 2011 06:17:47 -0700 From: Don Sturek To: Wei-Peng Chen , 'C Chauvenet' Message-ID: Thread-Topic: [Roll] Need quantitative requirements in draft-ietf-roll-applicability-ami-01 In-Reply-To: <008901cc4dad$a33210b0$e9963210$@chen@us.fujitsu.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3394765145_89324" Cc: roll@ietf.org Subject: Re: [Roll] Need quantitative requirements in 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: Fri, 29 Jul 2011 13:19:11 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3394765145_89324 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Wei-Peng (and Cedric), I actually chair the OpenSG SG-Communications group on behalf of Pacific Ga= s and Electric. In addition, Matt Gillmore (Consumers Energy, a Michigan based electric and gas utility) chairs the SG-NET task group in SG-Communications that produced the requirements. Participation in the OpenSG SG-NET group is mainly from 15 large US electri= c and gas utilities with many vendor companies. I would not say these requirements capture international requirements but are pretty representative of requirements in US smart grid deployments. Please note that the SG-NET requirements capture all smart grid requirements, not just AMI. I think the details of the data payloads in the SG-NET requirements are not really important. I think the throughput and latency requirements should b= e relevant information to applicability for any candidate routing protocol. = I think the ongoing work to define densities of devices to support should als= o be of interest (NIST SGIP PAP 2) to any candidate routing protocol. Don Sturek From: Wei-Peng Chen Date: Thu, 28 Jul 2011 22:09:03 -0700 To: 'C Chauvenet' Cc: Subject: Re: [Roll] Need quantitative requirements in draft-ietf-roll-applicability-ami-01 Hi C=E9dric, =20 I never attended OpenSG before. But according to my colleague who attended OpenSG before, there are many representatives from major utilities in the states.=20 I participated in IEEE P2030 briefly and part of the requirements are contributed by utility experts. BTW, I also agree with Don=B9s comment. =20 Regards, Wei-Peng =20 From: C Chauvenet [mailto:c.chauvenet@watteco.com] Sent: Thursday, July 28, 2011 7:42 PM To: Wei-Peng Chen Cc: Daniel.Popa@itron.com; roll@ietf.org Subject: Re: [Roll] Need quantitative requirements in draft-ietf-roll-applicability-ami-01 =20 Hi Wei-Peng =20 This would be indeed usefull informations. =20 The document you pointed out gives usefull and very precise requirements. =20 But, I'm wondering if this specification could be taken as a global rule fo= r most of AMI applications. =20 As I'm not a SmartGrid expert, is this specification approved by most of th= e AMI actors ? =20 C=E9dric. =20 Le 28 juil. 2011 =E0 21:23, Wei-Peng Chen a =E9crit : Hi Daniel, =20 To judge the applicability of RPL in AMI networks, in my opinion, we need t= o specify a few key quantitative requirements of AMI networks. But I cannot find quantitative requirements in neither your ID and RFC5548. Do you think whether we should specify some key requirements such as: - What is the interval each meter reports its reading? - The quantitative requirements for the latency, reliability, packet payload, etc. of UL/DL connections, in particular DL connections such as demand response, distribution automation. (You can find those numbers specified in UCAIAG=B9sSG Network System Requirements Specification and IEEE P2030 specification.) If I miss any previous draft which has already covered these quantitative requirements, please let me know. =20 Regards, Wei-Peng =20 =20 =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --B_3394765145_89324 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi Wei-Peng (and Cedric),

I actually chair the OpenSG SG-Communications group o= n behalf of Pacific Gas and Electric.  In addition, Matt Gillmore (Cons= umers Energy, a Michigan based electric and gas utility) chairs the SG-NET t= ask group in SG-Communications that produced the requirements.
Participation in the OpenSG SG-NET group is mainly from 15 large= US electric and gas utilities with many vendor companies.  I would not= say these requirements capture international requirements but are pretty re= presentative of requirements in US smart grid deployments.  Please note= that the SG-NET requirements capture all smart grid requirements, not just = AMI.

I think the details of the data payloads in th= e SG-NET requirements are not really important.  I think the throughput= and latency requirements should be relevant information to applicability fo= r any candidate routing protocol.  I think the ongoing work to define d= ensities of devices to support should also be of interest (NIST SGIP PAP 2) = to any candidate routing protocol.

Don Sturek
=


From: Wei-= Peng Chen <wei-peng.chen@us= .fujitsu.com>
Date: Thu, 28= Jul 2011 22:09:03 -0700
To: 'C Ch= auvenet' <c.chauvenet@watteco.co= m>
Cc: <roll@ietf.org>
Subje= ct: Re: [Roll] Need quantitative requirements in draft-ietf-roll-app= licability-ami-01

Hi C=E9dric,

<= o:p> 

I never atten= ded OpenSG before. But according to my colleague who attended OpenSG before,= there are many representatives from major utilities in the states.

I participated in IEEE P20= 30 briefly and part of the requirements are contributed by utility experts.<= o:p>

BTW, I also agree w= ith Don’s comment.

 

Regard= s,

Wei-Peng

 

From: C Chauvenet [mailto:c.chauvenet@watteco.com]
Sent: Thursday, Jul= y 28, 2011 7:42 PM
To: Wei-Peng Chen
Cc: Daniel.Popa@itron.com; roll@ietf.org
Subject: Re: [Roll] Need quantitative requ= irements in draft-ietf-roll-applicability-ami-01

=

 

Hi Wei-= Peng

 

This would be indeed usefull informations.<= /p>

 

The document you pointed out gives usefull and very precise requ= irements.

 

But, I'm wondering if this specification co= uld be taken as a global rule for most of AMI applications.

 

As I'm not a SmartGrid expert, is this specification approved by= most of the AMI actors ?

 

C=E9dric.

 

Le 28 juil. 2011 =E0 21:23, Wei-Peng Chen a =E9crit :



Hi Daniel,

 

To judge the applicab= ility of RPL in AMI networks, in my opinion, we need to specify a few key qu= antitative requirements of AMI networks. But I cannot find quantitative requ= irements in neither your ID and RFC5548. Do you think whether we should spec= ify some key requirements such as:

- What is the interval each meter repo= rts its reading?

- The quantitative requirements for the latency, reliabi= lity, packet payload, etc. of UL/DL connections, in particular DL connection= s such as demand response, distribution automation. (You can find those numb= ers specified in UCAIAG’sSG Network System Requirements Sp= ecification and I= EEE P2030 specification.)

If I miss any previous draft which has already = covered these quantitative requirements, please let me know.<= /p>

 

Re= gards,Wei-Peng

 

 

<ATT00001..txt><= /o:p>

 

=
_______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/m= ailman/listinfo/roll --B_3394765145_89324-- From jari.arkko@piuha.net Fri Jul 29 06:47:02 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 4C4E821F8BE8 for ; Fri, 29 Jul 2011 06:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 PncDSnAeU4UR for ; Fri, 29 Jul 2011 06:47:01 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 608C321F8BEE for ; Fri, 29 Jul 2011 06:47:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9BF0C2CEFF for ; Fri, 29 Jul 2011 16:47:00 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4XI81rX4NV6 for ; Fri, 29 Jul 2011 16:46:59 +0300 (EEST) Received: from [IPv6:::1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 496A52CC4B for ; Fri, 29 Jul 2011 16:46:59 +0300 (EEST) Message-ID: <4E32B9D2.3000509@piuha.net> Date: Fri, 29 Jul 2011 09:46:58 -0400 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [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: Fri, 29 Jul 2011 13:47:02 -0000 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). 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? > 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 From jonhui@cisco.com Fri Jul 29 06:52: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 50CE421F8747 for ; Fri, 29 Jul 2011 06:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 XgKp9CExUxAa for ; Fri, 29 Jul 2011 06:52:49 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id AB9E421F8745 for ; Fri, 29 Jul 2011 06:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=3165; q=dns/txt; s=iport; t=1311947569; x=1313157169; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=u8jvW9Nia5XIQC9CekivAr4Q9GYN5gsfSHrDrk+8sv8=; b=absydhr7StVYsi9pm4pb1x+KZHAXNpXRp9AqubKgPhVM5y6X8ojRR/9C MxyrNGVUP0jZ14ICWx5rv5BlGWZ2HAQ1fqizDJE76+I/HVrjzWicCE4ts L+DEA7H/iN8stgLO5EbFARxZZVioP0bMfpYargjYQxFjmfQicoe99JHQ5 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHO6Mk6rRDoI/2dsb2JhbAA0AQEBAQIBFAErRQUMDFIUUQc+p0V3iHyhFp4+hWJfBIdaiyCRAw X-IronPort-AV: E=Sophos;i="4.67,287,1309737600"; d="scan'208";a="7793196" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-7.cisco.com with ESMTP; 29 Jul 2011 13:52:49 +0000 Received: from sjc-vpn4-893.cisco.com (sjc-vpn4-893.cisco.com [10.21.83.124]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6TDqmXF026277; Fri, 29 Jul 2011 13:52:48 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: <1311914685.70336.YahooMailClassic@web113917.mail.gq1.yahoo.com> Date: Fri, 29 Jul 2011 06:52:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2A7CD49E-B949-4582-9F0A-A52C01FC341B@cisco.com> References: <1311914685.70336.YahooMailClassic@web113917.mail.gq1.yahoo.com> To: Ietf Roll X-Mailer: Apple Mail (2.1084) Cc: roll@ietf.org Subject: Re: [Roll] comments on 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: Fri, 29 Jul 2011 13:52:50 -0000 RAV, (the mysterious person hiding behind an unrecognizable name), Let me respond to the more technical comments: On Jul 28, 2011, at 9:44 PM, Ietf Roll wrote: > It seems to me that an AS should be based on real world experiences = but that is not possible since I have seen no actual deployments of RPL. = There have been some simulations attempting to show that it works and = some laboratory experiments that would indicate it might work - there = are other experiments that also show that it doesn't seem to perform as = expected. There may not yet be a large scale production deployment that conforms = to the RPL specification. However, I guarantee you that there are = large-scale production deployments that utilize the same broad concepts = as RPL (i.e. proactively building routes to a border = router/DAP/egress/etc using a distance vector protocol, proactively = reversing those routes using either source route or hop-by-hop routing). > One academic paper written by some of the authors of the RPL ID (BTW = it is not yet an RFC) clearly states that RPL should be limited to 30 = node networks. This seems far less than requirement listed in the this = document - e.g. 100s to 10000s nodes - for AMI networks. You take those results out of context. The target platform described in = the paper you reference had 10KB of total SRAM. I guarantee you that = existing production deployments with >1000 node networks have devices = with significantly more RAM. > On that topic it seems that the authors of this draft have confused = AMI with AMR. Where AMR networks are primarily MP2P (unidirectional) = which RPL might do well and might scale (if it weren't for the need of = sending back ACKs and the lossy nature of RF networks), AMI networks are = truly bidirectional with as many, if not more, messages flowing to the = meter and home as away. Here RPL is known to be severely lacking. In = fact the whole idea of packets flowing down a DAG (isn't that an = Oxymoron) was an after-thought as evidenced by the fact that multiple = other drafts had to be written to make RPL work in a downward direction. Maybe you missed the following paragraph: Head-end servers generate traffic to configure smart metering devices or initiate queries, and use unicast and multicast to efficiently communicate with a single device (i.e., Point-to-Point (P2P) communication) or groups of devices respectively (i.e., Point-to- Multipoint (P2MP) communication). The head-end server may send a single small packet at a time (e.g., a meter read request, or small configuration change) or many consecutive large packets (e.g., a firmware upgrade across one or even thousands of devices). Sure, proactive mechanisms have their limit - but those *existing* = production deployments that build P2MP routes proactively are properly = provisioned. Reactive mechanisms have their limits as well. In case you are confused, the term DAG was chosen to indicate that = default routes are optimized *towards* a border router. Link reversal = is not an uncommon technique. -- Jonathan Hui From pthubert@cisco.com Fri Jul 29 06:54: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 4D2DB21F8BA8 for ; Fri, 29 Jul 2011 06:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.647 X-Spam-Level: X-Spam-Status: No, score=-10.647 tagged_above=-999 required=5 tests=[AWL=-0.048, 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 mbEummA87N2Z for ; Fri, 29 Jul 2011 06:54:31 -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 6048421F8745 for ; Fri, 29 Jul 2011 06:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2074; q=dns/txt; s=iport; t=1311947671; x=1313157271; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=iYYbyBgeE2Dr038zXbHSda9U3m0G3b8TqeJp425kTbE=; b=UrYS8QmMzIJXEAbEUBiHWHLI9gjtJYRJCF+wH35Lh6JqIpbEq/NKsPAq oOmG/Ia6X6hQDeaHs9oqwVG9kNYrfFClMxrZwkT5LPym8GDjAkwra9Lj3 wzmcz43HGnUe3OJohtEYKtZH0TcpJ1NCgL1TCBokKkdrD8AHYfgVxm9VR s=; X-IronPort-AV: E=Sophos;i="4.67,287,1309737600"; d="scan'208";a="45626512" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 29 Jul 2011 13:54:30 +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 p6TDsU6N023507; Fri, 29 Jul 2011 13:54:30 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); Fri, 29 Jul 2011 15:54:30 +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: Fri, 29 Jul 2011 15:54:26 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D052DF2E9@XMB-AMS-107.cisco.com> In-Reply-To: <28156FD8-F1C6-4976-9147-69AA99829660@imag.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Need quantitative requirements indraft-ietf-roll-applicability-ami-01 Thread-Index: AcxN6iPulM2vfjGTSNKq/RwdYvVOkgAB/wyA References: <007201cc4d8e$1c8fe970$55afbc50$@chen@us.fujitsu.com><86CDEBEF-340A-4152-9D8E-71448EDC99D9@thomasclausen.org><651AEDF5-B195-40B7-B5E6-EDF5F78A12EE@ThomasClausen.org><4BE3AF83-DDFC-4DCC-A521-9497BB384D37@cisco.com> <28156FD8-F1C6-4976-9147-69AA99829660@imag.fr> From: "Pascal Thubert (pthubert)" To: "Martin Heusse" , "JP Vasseur" X-OriginalArrivalTime: 29 Jul 2011 13:54:30.0609 (UTC) FILETIME=[09F31C10:01CC4DF7] Cc: roll@ietf.org Subject: Re: [Roll] Need quantitative requirements indraft-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: Fri, 29 Jul 2011 13:54:32 -0000 Hi Martin: It is very sad you believe so. Let's see =20 > As a side note, i'd think that being able to establish downward routes to a > subset of nodes could be useful (especially for a metering application), but it > seems (...my understanding is that...) RPL precludes this (unless P2P is used). [Pascal] Richard made it clear to us long ago that in some case, nodes need only be reachable for small periods of time and thus we designed RPL so that DAO routes can be short lived, thus reducing the memory requirements on nodes in storing mode. So the question becomes, when and upon which events are those routes populated? Basically, that's the traditional push and pull story, where the push is the application up there or some controller in the network trying to reach to the device, and the pull is the device timely advertising its existence probably because it has a schedule to do so. The push being the case where you indicate that reactive is an interesting model. The RPL spec does NOT PRECLUDE any of those. It does NOT provide all the means to do everything either; the discussion on the ML indicated that we had to limit the number of methods in the main spec in order to contain its apparent complexity. So we defined the pull in the initial core spec and the push in the P2P spec. Both methods are still RPL, based on the same tool set. It is a bit late to change what the main spec defines but there's probably a way to change the packaging of the work in progress to make it more clear that the push can apply to RPL as a whole, not just specific to use cases for which P2P is explicitly more suited. The push is basically composed of a DIO that indicates a (list of) targets and optionally a range for the lookup. P2P adds specific information for source routing and DAG information persistence, which are not needed when the lookup happens on a preexisting DODAG. I'm really open to the packaging discussion but please do not convey the wrong impression that RPL would preclude push. Cheers, Pascal From Daniel.Popa@itron.com Fri Jul 29 07:13: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 33C0E21F8C20 for ; Fri, 29 Jul 2011 07:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, 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 urSgNB7UQ0+2 for ; Fri, 29 Jul 2011 07:13:02 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.115]) by ietfa.amsl.com (Postfix) with ESMTP id 55A3621F8C1F for ; Fri, 29 Jul 2011 07:13:02 -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; Fri, 29 Jul 2011 07:13:01 -0700 From: "Popa, Daniel" To: Wei-Peng Chen Date: Fri, 29 Jul 2011 07:13:02 -0700 Thread-Topic: Need quantitative requirements in draft-ietf-roll-applicability-ami-01 Thread-Index: AcxNjhvUoXAcY9D1Rf+8a0jdmUFGHgAZvd+A Message-ID: <83027ECE5ECDC04E9BA5350B756A88E1599349005E@ITR-EXMBXVS-1.itron.com> References: <007201cc4d8e$1c8fe970$55afbc50$@chen@us.fujitsu.com> In-Reply-To: <007201cc4d8e$1c8fe970$55afbc50$@chen@us.fujitsu.com> 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_83027ECE5ECDC04E9BA5350B756A88E1599349005EITREXMBXVS1it_" MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] Need quantitative requirements in 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: Fri, 29 Jul 2011 14:13:03 -0000 --_000_83027ECE5ECDC04E9BA5350B756A88E1599349005EITREXMBXVS1it_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgV2VpLVBlbmcsDQoNClRoYW5rcyBmb3IgZ29vZCBxdWVzdGlvbnMuDQoNClBsZWFzZSByZW1p bmQgdGhhdCBhIHJvdXRpbmcgcHJvdG9jb2wgd2lsbCBub3QgYmUgYSBzdGFuZGFsb25lIG1lY2hh bmlzbSBmb3IgQU1JIHNvbHV0aW9uLCBhbmQgc28gaXQgd2lsbCBub3QgYmUgVEhFIE1FQ0hBTklT TSB0aGF0IHNoYWxsIG1lZXQgdGhlIHJlcXVpcmVtZW50cyB5b3UgYXJlIHJlZmVycmluZyB0by4N Cg0KTGV0IG1lIHRha2UgYW4gZXhhbXBsZTogbGF0ZW5jeS4gSSBjaGFsbGVuZ2UgeW91IHRvIGV4 cGxhaW4gaG93IHNvbWVvbmUgY2FuIGRlc2lnbiBhIHN5c3RlbSB3aGVyZSB0aGUgcm91dGluZyBw cm90b2NvbCBpbiB0aGUgYWNjZXNzIHNlZ21lbnQg4oCTIGFsb25lIC0gaXMgcmVxdWlyZWQgdG8g YWNoaWV2ZSB0aGUgZGVzaXJlZCBsYXRlbmN5LCB3aXRob3V0IHRha2luZyBpbnRvIGFjY291bnQg dGhlIFBIWSBMYXllciBjaGFyYWN0ZXJpc3RpY3MgKGkuZS4sIGxpbmsgY2FwYWNpdHksIGVycm9y IHJhdGUsIGFuZCBlcnJvciBjb3JyZWN0aW9uIGNhcGFiaWxpdGllcyksIHRoZSBNQUMgcHJvdG9j b2wgY2hhcmFjdGVyaXN0aWNzIChpLmUuLCB0aHJvdWdocHV0KSwgY2hhbm5lbCBjaGFyYWN0ZXJp c3RpY3MgKGludGVyZmVyZW5jZXMpLCBpbnRlcmZlcmVuY2VzIG1pdGlnYXRpb24gbWVjaGFuaXNt cywgY29leGlzdGVuY2Ugd2l0aCBvdGhlciBzeXN0ZW1zIHdoZW4gb3BlcmF0aW5nIGluIHVubGlj ZW5zZWQgYmFuZHMsIHJlZ3VsYXRpb24sIGFuZCBzbyBvbi4NCg0KSU1ITywgdGhlIHJvdXRpbmcg cHJvdG9jb2wgaXMgdGhlIG1lY2hhbmlzbSB0aGF0IHRyaWVzIHRvIHBpY2sgdGhlIHJpZ2h0IHBh dGgg4oCTIGFzIGEgZnVuY3Rpb24gb2YgbWV0cmljcywgbGluayBjaGFyYWN0ZXJpc3RpY3MsIHJv dXRpbmcgb2JqZWN0aXZlcyAtIGFuZCDigJMgaW4gbGF0ZW5jeSBleGFtcGxlIOKAkyB3aWxsIHRy eSB0byBtaW5pbWl6ZSB0aGUgbGF0ZW5jeS4NCg0KTGV0IG1lIHRha2UgYSBmdXJ0aGVyIGV4YW1w bGU6IHJlbGlhYmlsaXR5LiBJIGNoYWxsZW5nZSBhZ2FpbiB0byBleHBsYWluIGhvdyBzb21lb25l IHdpbGwgZGVzaWduIGEgc3lzdGVtIHdoZXJlIHRoZSByb3V0aW5nIHByb3RvY29sIGFsb25lIGhh cyB0byBwcm92aWRlIHRoZSByZXF1aXJlZCByZWxpYWJpbGl0eS4gSU1ITywgdGhlIHJlbGlhYmls aXR5IG9mIGEgc3lzdGVtIGlzIGEgc3VtIG9mIHNldmVyYWwgbWVjaGFuaXNtcyBkZXBsb3llZCBh dCBkaWZmZXJlbnQgT1NJIGxheWVycyAoTUFDLCBUcmFuc3BvcnQgYW5kIEFwcGxpY2F0aW9uIG1v c3Qgb2YgdGhlIHRpbWUsIGV2ZW50dWFsbHkgTmV0IGxheWVyKSB0aGF0IC0gaW50ZWdyYXRlZCBp bnRvIGEgc29sdXRpb24g4oCTIHdpbGwgZXZlbnR1YWxseSBwcm92aWRlIHRoZSBkZXNpcmVkIHJl bGlhYmlsaXR5Lg0KDQpSZW1lbWJlciB0aGF0IGluIHRoaXMgZG9jdW1lbnQgd2Ugb25seSBmb2N1 cyBvbiByb3V0aW5nIGZvciB0aGUgYWNjZXNzIHNlZ21lbnQgb2YgYW4gQU1JIHN5c3RlbS4gSSB0 aGluayB5b3UgZXhwZWN0IHRoaXMgQXBwbGljYWJpbGl0eSBkb2N1bWVudCB0byBkZXNjcmliZSBh IHdob2xlIHN5c3RlbSBkZXNpZ24gYW5kIGhvdyBkaWZmZXJlbnQgbmV0d29yayBjb21wb25lbnRz ICYgZnVuY3Rpb25hbGl0aWVzIGFyZSBpbnRlZ3JhdGVkIGludG8gQU1JIHN5c3RlbXMuIEFtIEkg cmlnaHQ/DQoNCkRhbmllbA0KDQoNCg0KRnJvbTogV2VpLVBlbmcgQ2hlbiBbbWFpbHRvOndlaS1w ZW5nLmNoZW5AdXMuZnVqaXRzdS5jb21dDQpTZW50OiBUaHVyc2RheSwgSnVseSAyOCwgMjAxMSA5 OjIzIFBNDQpUbzogUG9wYSwgRGFuaWVsDQpDYzogcm9sbEBpZXRmLm9yZw0KU3ViamVjdDogTmVl ZCBxdWFudGl0YXRpdmUgcmVxdWlyZW1lbnRzIGluIGRyYWZ0LWlldGYtcm9sbC1hcHBsaWNhYmls aXR5LWFtaS0wMQ0KDQpIaSBEYW5pZWwsDQoNClRvIGp1ZGdlIHRoZSBhcHBsaWNhYmlsaXR5IG9m IFJQTCBpbiBBTUkgbmV0d29ya3MsIGluIG15IG9waW5pb24sIHdlIG5lZWQgdG8gc3BlY2lmeSBh IGZldyBrZXkgcXVhbnRpdGF0aXZlIHJlcXVpcmVtZW50cyBvZiBBTUkgbmV0d29ya3MuIEJ1dCBJ IGNhbm5vdCBmaW5kIHF1YW50aXRhdGl2ZSByZXF1aXJlbWVudHMgaW4gbmVpdGhlciB5b3VyIElE IGFuZCBSRkM1NTQ4LiBEbyB5b3UgdGhpbmsgd2hldGhlciB3ZSBzaG91bGQgc3BlY2lmeSBzb21l IGtleSByZXF1aXJlbWVudHMgc3VjaCBhczoNCi0gV2hhdCBpcyB0aGUgaW50ZXJ2YWwgZWFjaCBt ZXRlciByZXBvcnRzIGl0cyByZWFkaW5nPw0KLSBUaGUgcXVhbnRpdGF0aXZlIHJlcXVpcmVtZW50 cyBmb3IgdGhlIGxhdGVuY3ksIHJlbGlhYmlsaXR5LCBwYWNrZXQgcGF5bG9hZCwgZXRjLiBvZiBV TC9ETCBjb25uZWN0aW9ucywgaW4gcGFydGljdWxhciBETCBjb25uZWN0aW9ucyBzdWNoIGFzIGRl bWFuZCByZXNwb25zZSwgZGlzdHJpYnV0aW9uIGF1dG9tYXRpb24uIChZb3UgY2FuIGZpbmQgdGhv c2UgbnVtYmVycyBzcGVjaWZpZWQgaW4gVUNBSUFH4oCZcyBTRyBOZXR3b3JrIFN5c3RlbSBSZXF1 aXJlbWVudHMgU3BlY2lmaWNhdGlvbjxodHRwOi8vd3d3Lmdvb2dsZS5jb20vdXJsP3NhPXQmc291 cmNlPXdlYiZjZD0yJnZlZD0wQ0JzUUZqQUImdXJsPWh0dHAlM0ElMkYlMkZvc2d1Zy51Y2FpdWcu b3JnJTJGVXRpbGlDb21tJTJGU2hhcmVkJTI1MjBEb2N1bWVudHMlMkZMYXRlc3RfUmVsZWFzZV9E ZWxpdmVyYWJsZXMlMkZTRyUyNTIwTmV0d29yayUyNTIwU3lzdGVtJTI1MjBSZXF1aXJlbWVudHMl MjUyMFNwZWNpZmljYXRpb24lMjUyMHY0LjAueGxzJnJjdD1qJnE9U0clMjBuZXR3b3JrJTIwc3lz dGVtJTIwcmVxdWlyZW1lbnQlMjBmaWxldHlwZSUzQXhscyZlaT1EQWd5VHRqVkpaUEtpQUxyd3ZU RENBJnVzZz1BRlFqQ05IOG9iSU1NSkdFb09ELVB6VzNZTGhpbDhGZXh3PiBhbmQgSUVFRSBQMjAz MCBzcGVjaWZpY2F0aW9uLikNCklmIEkgbWlzcyBhbnkgcHJldmlvdXMgZHJhZnQgd2hpY2ggaGFz IGFscmVhZHkgY292ZXJlZCB0aGVzZSBxdWFudGl0YXRpdmUgcmVxdWlyZW1lbnRzLCBwbGVhc2Ug bGV0IG1lIGtub3cuDQoNClJlZ2FyZHMsDQpXZWktUGVuZw0KDQoNCg== --_000_83027ECE5ECDC04E9BA5350B756A88E1599349005EITREXMBXVS1it_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4N CjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N CiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4 dC1hbGlnbjpqdXN0aWZ5Ow0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7fQ0KaDMNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxl LWxpbms6IkhlYWRpbmcgMyBDaGFyIjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBjbTsNCglmb250LXNpemU6MTMuNXB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5IZWFk aW5nM0NoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgMyBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAzIjsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE5 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3 Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KDQo8Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1w dXJwbGU+DQoNCjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPkhpIFdlaS1QZW5nLCA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNv bG9yOiMxRjQ5N0QnPlRoYW5rcyBmb3IgZ29vZCBxdWVzdGlvbnMuIDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K Y29sb3I6IzFGNDk3RCc+UGxlYXNlIHJlbWluZCB0aGF0IGEgcm91dGluZyBwcm90b2NvbCB3aWxs IG5vdCBiZSBhIHN0YW5kYWxvbmUgbWVjaGFuaXNtDQpmb3IgQU1JIHNvbHV0aW9uLCBhbmQgc28g aXQgd2lsbCBub3QgYmUgVEhFIE1FQ0hBTklTTSB0aGF0IHNoYWxsIG1lZXQgdGhlDQpyZXF1aXJl bWVudHMgeW91IGFyZSByZWZlcnJpbmcgdG8uIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3 RCc+TGV0IG1lIHRha2UgYW4gZXhhbXBsZTogbGF0ZW5jeS4gSSBjaGFsbGVuZ2UgeW91IHRvIGV4 cGxhaW4gaG93DQpzb21lb25lIGNhbiBkZXNpZ24gYSBzeXN0ZW0gd2hlcmUgdGhlIHJvdXRpbmcg cHJvdG9jb2wgaW4gdGhlIGFjY2VzcyBzZWdtZW50IOKAkyBhbG9uZQ0KLSBpcyByZXF1aXJlZCB0 byBhY2hpZXZlIHRoZSBkZXNpcmVkIGxhdGVuY3ksIHdpdGhvdXQgdGFraW5nIGludG8gYWNjb3Vu dCB0aGUNClBIWSBMYXllciBjaGFyYWN0ZXJpc3RpY3MgKGkuZS4sIGxpbmsgY2FwYWNpdHksIGVy cm9yIHJhdGUsIGFuZCBlcnJvcg0KY29ycmVjdGlvbiBjYXBhYmlsaXRpZXMpLCB0aGUgTUFDIHBy b3RvY29sIGNoYXJhY3RlcmlzdGljcyAoaS5lLiwgdGhyb3VnaHB1dCksIGNoYW5uZWwNCmNoYXJh Y3RlcmlzdGljcyAoaW50ZXJmZXJlbmNlcyksIGludGVyZmVyZW5jZXMgbWl0aWdhdGlvbiBtZWNo YW5pc21zLA0KY29leGlzdGVuY2Ugd2l0aCBvdGhlciBzeXN0ZW1zIHdoZW4gb3BlcmF0aW5nIGlu IHVubGljZW5zZWQgYmFuZHMsIHJlZ3VsYXRpb24sIGFuZA0Kc28gb24uIMKgwqA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3 RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCmNvbG9yOiMxRjQ5N0QnPklNSE8sIHRoZSByb3V0aW5nIHByb3RvY29sIGlzIHRoZSBt ZWNoYW5pc20gdGhhdCB0cmllcyB0byBwaWNrDQp0aGUgcmlnaHQgcGF0aCDigJMgYXMgYSBmdW5j dGlvbiBvZiBtZXRyaWNzLCBsaW5rIGNoYXJhY3RlcmlzdGljcywgcm91dGluZyBvYmplY3RpdmVz DQotIGFuZCDigJMgaW4gbGF0ZW5jeSBleGFtcGxlIOKAkyB3aWxsIHRyeSB0byBtaW5pbWl6ZSB0 aGUgbGF0ZW5jeS4gPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5MZXQgbWUgdGFrZSBh IGZ1cnRoZXIgZXhhbXBsZTogcmVsaWFiaWxpdHkuIEkgY2hhbGxlbmdlIGFnYWluIHRvDQpleHBs YWluIGhvdyBzb21lb25lIHdpbGwgZGVzaWduIGEgc3lzdGVtIHdoZXJlIHRoZSByb3V0aW5nIHBy b3RvY29sIGFsb25lIGhhcw0KdG8gcHJvdmlkZSB0aGUgcmVxdWlyZWQgcmVsaWFiaWxpdHkuIElN SE8sIHRoZSByZWxpYWJpbGl0eSBvZiBhIHN5c3RlbSBpcyBhIHN1bQ0Kb2Ygc2V2ZXJhbCBtZWNo YW5pc21zIGRlcGxveWVkIGF0IGRpZmZlcmVudCBPU0kgbGF5ZXJzIChNQUMsIFRyYW5zcG9ydCBh bmQNCkFwcGxpY2F0aW9uIG1vc3Qgb2YgdGhlIHRpbWUsIGV2ZW50dWFsbHkgTmV0IGxheWVyKSB0 aGF0IC0gaW50ZWdyYXRlZCBpbnRvIGEgc29sdXRpb24NCuKAkyB3aWxsIGV2ZW50dWFsbHkgcHJv dmlkZSB0aGUgZGVzaXJlZCByZWxpYWJpbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5 N0QnPlJlbWVtYmVyIHRoYXQgaW4gdGhpcyBkb2N1bWVudCB3ZSBvbmx5IGZvY3VzIG9uIHJvdXRp bmcgZm9yIHRoZQ0KYWNjZXNzIHNlZ21lbnQgb2YgYW4gQU1JIHN5c3RlbS4gSSB0aGluayB5b3Ug ZXhwZWN0IHRoaXMgQXBwbGljYWJpbGl0eSBkb2N1bWVudA0KdG8gZGVzY3JpYmUgYSB3aG9sZSBz eXN0ZW0gZGVzaWduIGFuZCBob3cgZGlmZmVyZW50IG5ldHdvcmsgY29tcG9uZW50cyAmYW1wOw0K ZnVuY3Rpb25hbGl0aWVzIGFyZSBpbnRlZ3JhdGVkIGludG8gQU1JIHN5c3RlbXMuIEFtIEkgcmln aHQ/IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+RGFuaWVsPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPGRpdiBzdHlsZT0nYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0 Jz4NCg0KPGRpdj4NCg0KPGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWwgYWxpZ249bGVmdCBzdHlsZT0ndGV4dC1hbGlnbjpsZWZ0Jz48Yj48c3Bhbg0Kc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIic+IFdlaS1QZW5nIENoZW4gW21haWx0bzp3ZWktcGVuZy5jaGVu QHVzLmZ1aml0c3UuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5IDI4LCAy MDExIDk6MjMgUE08YnI+DQo8Yj5Ubzo8L2I+IFBvcGEsIERhbmllbDxicj4NCjxiPkNjOjwvYj4g cm9sbEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBOZWVkIHF1YW50aXRhdGl2ZSByZXF1 aXJlbWVudHMgaW4NCmRyYWZ0LWlldGYtcm9sbC1hcHBsaWNhYmlsaXR5LWFtaS0wMTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwg YWxpZ249bGVmdCBzdHlsZT0ndGV4dC1hbGlnbjpsZWZ0Jz48bzpwPiZuYnNwOzwvbzpwPjwvcD4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9y OiMxRjQ5N0QnPkhpIERhbmllbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz5UbyBqdWRnZSB0aGUNCmFwcGxpY2Fi aWxpdHkgb2YgUlBMIGluIEFNSSBuZXR3b3JrcywgaW4gbXkgb3Bpbmlvbiwgd2UgbmVlZCB0byBz cGVjaWZ5IGEgZmV3DQprZXkgcXVhbnRpdGF0aXZlIHJlcXVpcmVtZW50cyBvZiBBTUkgbmV0d29y a3MuIEJ1dCBJIGNhbm5vdCBmaW5kIHF1YW50aXRhdGl2ZQ0KcmVxdWlyZW1lbnRzIGluIG5laXRo ZXIgeW91ciBJRCBhbmQgUkZDNTU0OC4gRG8geW91IHRoaW5rIHdoZXRoZXIgd2Ugc2hvdWxkDQpz cGVjaWZ5IHNvbWUga2V5IHJlcXVpcmVtZW50cyBzdWNoIGFzOiA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtj b2xvcjojMUY0OTdEJz4tIFdoYXQgaXMgdGhlDQppbnRlcnZhbCBlYWNoIG1ldGVyIHJlcG9ydHMg aXRzIHJlYWRpbmc/PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+LSBUaGUNCnF1YW50 aXRhdGl2ZSByZXF1aXJlbWVudHMgZm9yIHRoZSBsYXRlbmN5LCByZWxpYWJpbGl0eSwgcGFja2V0 IHBheWxvYWQsIGV0Yy4gb2YNClVML0RMIGNvbm5lY3Rpb25zLCBpbiBwYXJ0aWN1bGFyIERMIGNv bm5lY3Rpb25zIHN1Y2ggYXMgZGVtYW5kIHJlc3BvbnNlLA0KZGlzdHJpYnV0aW9uIGF1dG9tYXRp b24uIChZb3UgY2FuIGZpbmQgdGhvc2UgbnVtYmVycyBzcGVjaWZpZWQgaW4gVUNBSUFH4oCZcyA8 YQ0KaHJlZj0iaHR0cDovL3d3dy5nb29nbGUuY29tL3VybD9zYT10JmFtcDtzb3VyY2U9d2ViJmFt cDtjZD0yJmFtcDt2ZWQ9MENCc1FGakFCJmFtcDt1cmw9aHR0cCUzQSUyRiUyRm9zZ3VnLnVjYWl1 Zy5vcmclMkZVdGlsaUNvbW0lMkZTaGFyZWQlMjUyMERvY3VtZW50cyUyRkxhdGVzdF9SZWxlYXNl X0RlbGl2ZXJhYmxlcyUyRlNHJTI1MjBOZXR3b3JrJTI1MjBTeXN0ZW0lMjUyMFJlcXVpcmVtZW50 cyUyNTIwU3BlY2lmaWNhdGlvbiUyNTIwdjQuMC54bHMmYW1wO3JjdD1qJmFtcDtxPVNHJTIwbmV0 d29yayUyMHN5c3RlbSUyMHJlcXVpcmVtZW50JTIwZmlsZXR5cGUlM0F4bHMmYW1wO2VpPURBZ3lU dGpWSlpQS2lBTHJ3dlREQ0EmYW1wO3VzZz1BRlFqQ05IOG9iSU1NSkdFb09ELVB6VzNZTGhpbDhG ZXh3Ij48aT48c3Bhbg0Kc3R5bGU9J2NvbG9yOiMxRjQ5N0Q7dGV4dC1kZWNvcmF0aW9uOm5vbmUn PlNHIE5ldHdvcmsgU3lzdGVtIFJlcXVpcmVtZW50czwvc3Bhbj48L2k+PHNwYW4NCnN0eWxlPSdj b2xvcjojMUY0OTdEO3RleHQtZGVjb3JhdGlvbjpub25lJz4gU3BlY2lmaWNhdGlvbjwvc3Bhbj48 L2E+IGFuZCBJRUVFDQpQMjAzMCBzcGVjaWZpY2F0aW9uLik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xv cjojMUY0OTdEJz5JZiBJIG1pc3MgYW55DQpwcmV2aW91cyBkcmFmdCB3aGljaCBoYXMgYWxyZWFk eSBjb3ZlcmVkIHRoZXNlIHF1YW50aXRhdGl2ZSByZXF1aXJlbWVudHMsDQpwbGVhc2UgbGV0IG1l IGtub3cuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2NvbG9yOiMxRjQ5N0QnPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFG NDk3RCc+V2VpLVBlbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9ib2R5Pg0KDQo8 L2h0bWw+DQo= --_000_83027ECE5ECDC04E9BA5350B756A88E1599349005EITREXMBXVS1it_-- From Daniel.Popa@itron.com Fri Jul 29 07:20: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 CD18B21F874A for ; Fri, 29 Jul 2011 07:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 ZXhMAf0eo6Ex for ; Fri, 29 Jul 2011 07:20:31 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.115]) by ietfa.amsl.com (Postfix) with ESMTP id 11D3F21F8736 for ; Fri, 29 Jul 2011 07:20:31 -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; Fri, 29 Jul 2011 07:20:30 -0700 From: "Popa, Daniel" To: Wei-Peng Chen , 'Ietf Roll' , 'Thomas Heide Clausen' , 'JP Vasseur' Date: Fri, 29 Jul 2011 07:20:32 -0700 Thread-Topic: [Roll] Need quantitative requirements in draft-ietf-roll-applicability-ami-01 Thread-Index: AcxNqTfthO11lTsSS96W+044e7X8nwAAbQWgABPUyZA= Message-ID: <83027ECE5ECDC04E9BA5350B756A88E15993490085@ITR-EXMBXVS-1.itron.com> References: <1311914243.47928.YahooMailClassic@web113913.mail.gq1.yahoo.com> <008e01cc4dad$a9d48560$fd7d9020$@chen@us.fujitsu.com> In-Reply-To: <008e01cc4dad$a9d48560$fd7d9020$@chen@us.fujitsu.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] Need quantitative requirements in 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: Fri, 29 Jul 2011 14:20:31 -0000 SGkgV2VpLVBlbmcsIA0KIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IHJvbGwtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mDQo+IFdlaS1QZW5nIENoZW4NCj4gU2VudDogRnJpZGF5LCBKdWx5IDI5LCAyMDEx IDE6MDkgQU0NCj4gVG86ICdJZXRmIFJvbGwnOyAnVGhvbWFzIEhlaWRlIENsYXVzZW4nOyAnSlAg VmFzc2V1cicNCj4gQ2M6IHJvbGxAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtSb2xsXSBOZWVk IHF1YW50aXRhdGl2ZSByZXF1aXJlbWVudHMgaW4gZHJhZnQtaWV0Zi1yb2xsLQ0KPiBhcHBsaWNh YmlsaXR5LWFtaS0wMQ0KPiANCj4gSGkgSlAsDQo+IA0KPiBBcyBJIGFtIGEgbmV3YmllIHRvIElF VEYsIHdoYXQgSSBzYWlkIG1heSBub3QgbWFrZSBzZW5zZSB0byB0aGUNCj4gY29tbXVuaXR5LiBB bmQgSSBhcHByZWNpYXRlIHlvdXIgY29tbWVudC4NCj4gSG93ZXZlciwgSSBhZ3JlZSB3aXRoIFRo b21hcyBhbmQgSWV0ZiB0aGF0IHRyYWZmaWMgcGF0dGVybnMgb2YgdGhlDQo+IHRhcmdldGVkIGFw cGxpY2F0aW9ucyBhbmQgY29tbXVuaWNhdGlvbiBlbnZpcm9ubWVudHMgYXJlIGltcG9ydGFudCB0 bw0KPiB1bmRlcnN0YW5kIHRoZSBhcHBsaWNhYmlsaXR5IG9mIGEgZ2l2ZW4gcm91dGluZyBwcm90 b2NvbC4gV2UgbmVlZCB0bw0KPiBjb25zaWRlciBhbnkgcXVhbnRpdGF0aXZlIHJlcXVpcmVtZW50 cyBzcGVjaWZpZWQgYnkgdXRpbGl0aWVzLiBJbg0KPiBwYXJ0aWN1bGFyLCBtZXRlcnMsIG9uY2Ug aW5zdGFsbGVkLCB3b3VsZCBsYXN0IGZvciAyMCsgeWVhcnMuIA0KDQpEUD4gVGhlIGhhcmR3YXJl IHllcywgaXQgd291bGQgbGFzdCBmb3IgMjAgeWVhcnMuIEJ1dCBub3QgdGhlIHNvZnR3YXJlIChp biBwYXJ0aWN1bGFyIHRoZSBlbWJlZGRlZCBuZXR3b3JraW5nIHNvZnR3YXJlKSwgYmVjYXVzZSBh biBBTUkgc3lzdGVtIGhhcyB0aGUgY2FwYWJpbGl0eSBvZiBkb2luZyBmaXJtd2FyZSB1cGdyYWRl IGFuZCBzbyB1cGdyYWRlL2luc3RhbGwgbmV3IGZlYXR1cmVzLiBXaGF0IHlvdSBtZW50aW9uIGlz IGEgdHJhZGUtb2ZmIGJldHdlZW4gY29zdCBhbmQgZmxleGliaWxpdHkuICAgDQoNCkl0IGlzDQo+ IGltcG9ydGFudCB0byBjb25zaWRlciB0aGUgcmVxdWlyZW1lbnRzIG9mIHRoZSBwb3RlbnRpYWwg YXBwbGljYXRpb25zIGluDQo+IHRoZSBuZWFyIGZ1dHVyZS4NCj4gDQo+IFJlZ2FyZHMsDQo+IFdl aS1QZW5nDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBJZXRmIFJv bGwgW21haWx0bzppZXRmcm9sbEB5YWhvby5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDI4 LCAyMDExIDk6MzcgUE0NCj4gVG86IFRob21hcyBIZWlkZSBDbGF1c2VuOyBKUCBWYXNzZXVyDQo+ IENjOiByb2xsQGlldGYub3JnOyBXZWktUGVuZyBDaGVuDQo+IFN1YmplY3Q6IFJlOiBbUm9sbF0g TmVlZCBxdWFudGl0YXRpdmUgcmVxdWlyZW1lbnRzIGluIGRyYWZ0LWlldGYtcm9sbC0NCj4gYXBw bGljYWJpbGl0eS1hbWktMDENCj4gDQo+IFRoaXMgaXMgd2hhdCB5b3UgYXJlIHNheWluZyBub3cg aW4geW91ciByZXZpc2lvbmlzdCBoaXN0b3J5LCBidXQNCj4gY2VydGFpbmx5IG5vdCB3aGF0IHlv dSBzYWlkLg0KPiANCj4gSXQgaXMgaW1wb3J0YW50IHRvIHVuZGVyc3RhbmQgdGhlIHRvdGFsIGNv bW11bmljYXRpb25zIGVudmlyb25tZW50IHRoYXQNCj4gdGhlIHJvdXRpbmcgcHJvdG9jb2wgbXVz dCB3b3JrIGluIG9yIGRvIHlvdSBmb3JnZXQgdGhlIG5vdyBhYmFuZG9uZWQNCj4gZHJhZnQgb24g cHJvdG9jb2wgc3VydmV5IG1hZGUgYSBiaWcgZGVhbCBhYm91dCB0aGUgcm91dGluZyBtYWludGVu YW5jZQ0KPiBvdmVyaGVhZCAoYXMgY29tcHV0ZWQgYnkgY29tcGFyaW5nIGRhdGEgdnMgbWFpbnRl bmFuY2UgcGFja2V0cy4pDQo+IA0KPiBJZiBJJ20gb25seSBzZW5kaW5nIGEgcGFja2V0IG9uY2Ug aW4gYSBsb25nIHdoaWxlIGFuZCBsYXRlbmN5IGlzbid0IGFuDQo+IGlzc3VlIEkgY291bGQgc2Vh cmNoIGZvciBwYXRoIG9uIGVhY2ggcGFja2V0LCBjb3VsZCBJIG5vdC4NCj4gDQo+IEluIGEgImdv b2QiIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IGl0IHdvdWxkIHNlZW0gYmVuZWZpY2lhbCB0byB3 ZWxsDQo+IHNwZWNpZnkgdGhlIG5ldHdvcmsgeW91IGFyZSBjbGFpbWluZyBhcHBsaWNhYmlsaXR5 IHRvLg0KPiANCj4gDQo+IC0tLSBPbiBGcmksIDcvMjkvMTEsIEpQIFZhc3NldXIgPGpwdkBjaXNj by5jb20+IHdyb3RlOg0KPiANCj4gPiBGcm9tOiBKUCBWYXNzZXVyIDxqcHZAY2lzY28uY29tPg0K PiA+IFN1YmplY3Q6IFJlOiBbUm9sbF0gTmVlZCBxdWFudGl0YXRpdmUgcmVxdWlyZW1lbnRzIGlu IGRyYWZ0LWlldGYtDQo+IHJvbGwtYXBwbGljYWJpbGl0eS1hbWktMDENCj4gPiBUbzogIlRob21h cyBIZWlkZSBDbGF1c2VuIiA8VGhvbWFzQFRob21hc0NsYXVzZW4ub3JnPg0KPiA+IENjOiAicm9s bEBpZXRmLm9yZyIgPHJvbGxAaWV0Zi5vcmc+LCAiV2VpLVBlbmcgQ2hlbiIgPHdlaS0NCj4gcGVu Zy5jaGVuQHVzLmZ1aml0c3UuY29tPg0KPiA+IERhdGU6IEZyaWRheSwgSnVseSAyOSwgMjAxMSwg NDowMyBBTQ0KPiA+DQo+ID4gT24gSnVsIDI4LCAyMDExLCBhdCAxMToyMiBQTSwgVGhvbWFzIEhl aWRlDQo+ID4gQ2xhdXNlbiB3cm90ZToNCj4gPg0KPiA+DQo+ID4NCj4gPiBPbiAyOCBKdWwgMjAx MSwgYXQgMjI6MzYsIEpQIFZhc3NldXIgPGpwdkBjaXNjby5jb20+DQo+ID4gd3JvdGU6DQo+ID4N Cj4gPiBEZWFyDQo+ID4gV2VpLVBlbmcsDQo+ID4gT24gSnVsIDI4LCAyMDExLCBhdCA5OjIzIFBN LCBXZWktUGVuZyBDaGVuDQo+ID4gd3JvdGU6DQo+ID4gSGkgRGFuaWVsLCAgVG8ganVkZ2UgdGhl IGFwcGxpY2FiaWxpdHkgb2YgUlBMIGluIEFNSSBuZXR3b3JrcywgaW4NCj4gPiBteSBvcGluaW9u LCB3ZSBuZWVkIHRvIHNwZWNpZnkgYSBmZXcga2V5IHF1YW50aXRhdGl2ZQ0KPiA+IHJlcXVpcmVt ZW50cyBvZiBBTUkgbmV0d29ya3MuIEJ1dCBJIGNhbm5vdCBmaW5kIHF1YW50aXRhdGl2ZQ0KPiA+ IHJlcXVpcmVtZW50cyBpbiBuZWl0aGVyIHlvdXIgSUQgYW5kIFJGQzU1NDguIERvIHlvdSB0aGlu aw0KPiA+IHdoZXRoZXIgd2Ugc2hvdWxkIHNwZWNpZnkgc29tZSBrZXkgcmVxdWlyZW1lbnRzIHN1 Y2gNCj4gPiBhczotIFdoYXQgaXMgdGhlIGludGVydmFsIGVhY2ggbWV0ZXIgcmVwb3J0cyBpdHMN Cj4gPiByZWFkaW5nPy0gVGhlIHF1YW50aXRhdGl2ZSByZXF1aXJlbWVudHMgZm9yIHRoZSBsYXRl bmN5LA0KPiA+IHJlbGlhYmlsaXR5LCBwYWNrZXQgcGF5bG9hZCwgZXRjLiBvZiBVTC9ETCBjb25u ZWN0aW9ucywgaW4NCj4gPiBwYXJ0aWN1bGFyIERMIGNvbm5lY3Rpb25zIHN1Y2ggYXMgZGVtYW5k IHJlc3BvbnNlLA0KPiA+IGRpc3RyaWJ1dGlvbiBhdXRvbWF0aW9uLiAoWW91IGNhbiBmaW5kIHRo b3NlIG51bWJlcnMNCj4gPiBzcGVjaWZpZWQgaW4gVUNBSUFH4oCZcyBTRw0KPiA+IE5ldHdvcmsg U3lzdGVtIFJlcXVpcmVtZW50cyBTcGVjaWZpY2F0aW9uIGFuZA0KPiA+IElFRUUgUDIwMzAgc3Bl Y2lmaWNhdGlvbi4pSWYgSSBtaXNzIGFueSBwcmV2aW91cyBkcmFmdCB3aGljaCBoYXMNCj4gYWxy ZWFkeQ0KPiA+IGNvdmVyZWQgdGhlc2UgcXVhbnRpdGF0aXZlIHJlcXVpcmVtZW50cywgcGxlYXNl IGxldCBtZQ0KPiA+IGtub3cuDQo+ID4gSnVzdCBhbiBpbXBvcnRhbnQgY2xhcmlmaWNhdGlvbjog dGhpcyBpcyBhbiBSUEwNCj4gPiBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCwgdGh1cyBtYW55IG9m IHRoZSBpdGVtcyBsaXN0DQo+ID4gYWJvdmVhcmUgb3V0IG9mIHRoZSBzY29wZSBvZiBzdWNoIGEN Cj4gPiBkb2N1bWVudC4NCj4gPg0KPiA+IEp1c3QgdG8gY2xhcmlmeSwgeW91IGFyZSBzYXlpbmcg dGhhdCBSUEwgaXMgbm90DQo+ID4gYXBwbGljYWJsZSBmb3IgQU1JLCBhbmQgdGhlcmVmb3JlIHRo ZXNlIGNvbnNpZGVyYXRpb25zIGFyZQ0KPiA+IG91dCBvZiBzY29wZS4gSSBhZ3JlZSB3aXRoIHRo YXQsLg0KPiA+DQo+ID4gVGhvbWFzLCB3aGVyZSBkbyB5b3Ugc2VlIHRoYXQgSSBzYWlkIHRoaXMN Cj4gPiA/SSBzYWlkIHRoYXQgImludGVydmFsIGVhY2ggbWV0ZXIgcmVwb3J0cw0KPiA+IGl0cyBy ZWFkaW5nIiwgInBhY2tldCBwYXlsb2FkIiwg4oCmIGFyZSBub3QNCj4gPiByb3V0aW5nIHBhcmFt ZXRlcnMsIHRodXMgdGhlcmUgYXJlIG9mIHRoZSBzY29wZSBvZg0KPiA+IHRoaXMgZG9jdW1lbnQs IHdoaWNoIGlzIGEgUlBMIEFNSSBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudC4NCj4gPiBJbiBvdGhl ciB3b3JkcywgdGhlIG9iamVjdGl2ZSBpcyB0byBleHBsYWluIGhvdyBSUEwgY2FuIGJlDQo+ID4g dXNlZCBmb3IgQU1JIHB1cnBvc2VzLiBOb24gcm91dGluZyByZWxhdGVkIGlzc3VlcyBhcmUgdGh1 cw0KPiA+IG91dCBvZiB0aGUgc2NvcGUuIEkgYW0ganVzdCBzdGF0aW5nIHRoZSBvYnZpb3VzDQo+ ID4gaGVyZS4NCj4gPiBUaGFua3MuDQo+ID4gSlAuDQo+ID4NCj4gPiBJLCB0aGVuLCB3b25kZXIN Cj4gPiB3aHkgZHJhZnQtaWV0Zi1yb2xsLWFwcGxpY2FiaWxpdHktYW1pIGV4aXN0cyBhcyBXRw0K PiA+IGRvY3VtZW50IC0gYXMgeW91IHNheSB0aGF0IEFNSSBpcyBvdXQgb2Ygc2NvcGUgZm9yDQo+ ID4gUlBMLg0KPiA+IFRob21hcw0KPiA+DQo+ID4gVGhhbmtzLg0KPiA+IEpQLg0KPiA+ICAgUmVn YXJkcyxXZWktUGVuZw0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPiBSb2xsIG1haWxpbmcgbGlzdA0KPiA+IFJvbGxAaWV0Zi5vcmcN Cj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCj4gPg0KPiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gUm9s bCBtYWlsaW5nIGxpc3QNCj4gPiBSb2xsQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo+ID4NCj4gPg0KPiA+IC0tLS0tSW5saW5lIEF0dGFj aG1lbnQgRm9sbG93cy0tLS0tDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+IFJvbGwgbWFpbGluZyBsaXN0DQo+ID4gUm9sbEBpZXRm Lm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0KPiA+ DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBSb2xsIG1haWxpbmcgbGlzdA0KPiBSb2xsQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K From jpv@cisco.com Fri Jul 29 07:22: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 D6B0E21F8A6C for ; Fri, 29 Jul 2011 07:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.394 X-Spam-Level: X-Spam-Status: No, score=-102.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 QS+STwHK9SfR for ; Fri, 29 Jul 2011 07:22:22 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1C59921F886E for ; Fri, 29 Jul 2011 07:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=3974; q=dns/txt; s=iport; t=1311949342; x=1313158942; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=j6m2oi9vbARpNKBaNiwUGdlj7zEtIzCP9uQ9ek6g0Kk=; b=GC3WB/3GV3/04FwFW3npndmbXPa8vDaq3IjsfhGF313JZm0pZINb5fZ/ WzyQEiX8Qnjs80+PUfqVQyXNt/bLWMrCDgR4dX7Rt1n51CHnZuqnLjAEv yTYS4osL9Gp0YC6bxaJAuyOmcS94W7KpFWb1iogJCgtA9+ItUqat/0N1M E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAInBMk6tJXG8/2dsb2JhbAA0AQEBAQIBAQEBDQQBDR4xCQsFDAxSFBg5BxcgB6dFd4h8BKEDnjKFYl8EknqFBgmLcA X-IronPort-AV: E=Sophos;i="4.67,287,1309737600"; d="scan'208";a="7803740" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 29 Jul 2011 14:22:21 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6TEMKr2031684; Fri, 29 Jul 2011 14:22:21 GMT Received: from xfe-sjc-221.amer.cisco.com ([128.107.191.32]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Jul 2011 07:22:19 -0700 Received: from [10.255.254.166] ([10.21.79.74]) by xfe-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Jul 2011 07:22:18 -0700 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <4E32B9D2.3000509@piuha.net> Date: Fri, 29 Jul 2011 10:22:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <58646682-CCF2-4352-BB96-E0A22FB551C3@cisco.com> References: <4E32B9D2.3000509@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 29 Jul 2011 14:22:19.0243 (UTC) FILETIME=[EC8873B0:01CC4DFA] 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: Fri, 29 Jul 2011 14:22:23 -0000 Thanks Jari, See in line. On Jul 29, 2011, at 9:46 AM, Jari Arkko wrote: > I have reviewed this document, and had some comments: >=20 > 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! Thanks for your support, and yes we're not there yet, still lots of work = to be done. Good to see discussion, suggestions and comments. > 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. >=20 =46rom what I heard there is some data coming from deployed networks, = not yet at a large scale, but you are right that those are useful. > Some additional more detailed comments: >=20 > 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). >=20 Interesting, thanks. I'll leave it the authors who worked on this = section. > 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? This is an excellent point and should be addressed in the next revision.=20= Authors, could you look at this ? >=20 >> 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. >> =20 >=20 > 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? Yes it must be. Thanks for the constructive comments. JP. >=20 > Jari >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From c.chauvenet@watteco.com Fri Jul 29 07:52: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 7B0DB21F8C31 for ; Fri, 29 Jul 2011 07:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=-1.499, 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 hsPWsW1rYg5F for ; Fri, 29 Jul 2011 07:52:16 -0700 (PDT) Received: from VA3EHSOBE005.bigfish.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 9503A21F86AE for ; Fri, 29 Jul 2011 07:52:16 -0700 (PDT) Received: from mail100-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.22; Fri, 29 Jul 2011 14:52:16 +0000 Received: from mail100-va3 (localhost.localdomain [127.0.0.1]) by mail100-va3-R.bigfish.com (Postfix) with ESMTP id EC1DC128806C; Fri, 29 Jul 2011 14:52: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:IE2RD2HUB017.red002.local; RD:none; EFVD:NLI Received: from mail100-va3 (localhost.localdomain [127.0.0.1]) by mail100-va3 (MessageSwitch) id 1311951135715883_30238; Fri, 29 Jul 2011 14:52:15 +0000 (UTC) Received: from VA3EHSMHS014.bigfish.com (unknown [10.7.14.243]) by mail100-va3.bigfish.com (Postfix) with ESMTP id AAB45F8004C; Fri, 29 Jul 2011 14:52:15 +0000 (UTC) Received: from IE2RD2HUB017.red002.local (213.199.187.153) by VA3EHSMHS014.bigfish.com (10.7.99.24) with Microsoft SMTP Server (TLS) id 14.1.225.22; Fri, 29 Jul 2011 14:52:14 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.55]) by IE2RD2HUB017.red002.local ([10.43.198.95]) with mapi; Fri, 29 Jul 2011 07:51:52 -0700 From: C Chauvenet To: Ietf Roll Date: Fri, 29 Jul 2011 07:51:50 -0700 Thread-Topic: [Roll] comments on draft-ietf-roll-applicability-ami-01 Thread-Index: AcxN/w0mWj+bgAZ+TeK/cfaQtnC2Og== Message-ID: <1066CDED-F7E4-4F5A-ACA4-2ED0A4C9F5CA@watteco.com> References: <1311914685.70336.YahooMailClassic@web113917.mail.gq1.yahoo.com> In-Reply-To: <1311914685.70336.YahooMailClassic@web113917.mail.gq1.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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "roll@ietf.org" Subject: Re: [Roll] comments on 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: Fri, 29 Jul 2011 14:52:18 -0000 Hi Dark Knight ;-), See Inline. Le 29 juil. 2011 =E0 06:44, Ietf Roll a =E9crit : > I can be silent no more... Since no one else has really spoken up about t= he state of this draft I feel that I must... >=20 > This is the most amazing marketing fluff piece trying to pass itself off = as a serious document that I have read in quite a while. With all the hot a= ir I'm surprised that it hasn't risen to RFC status of it's own accord - It= shouldn't have needed the WG Chairs to skip standard accepted procedures f= or promoting WG documents. [Perhaps there is some unseen agenda in their ru= sh to move the document forward without due process.] >=20 > We have been told that "the IESG" requested it. Really, the entire IESG a= sked for this doc to jump normal protocol and move forward. I suspect that = this an unsubstantiated assertion like much of draft-ietf-roll-applicabilit= y-ami-01. >=20 > It seems to me that an AS should be based on real world experiences but t= hat is not possible since I have seen no actual deployments of RPL. There h= ave been some simulations attempting to show that it works and some laborat= ory experiments that would indicate it might work - there are other experim= ents that also show that it doesn't seem to perform as expected. >=20 > One academic paper written by some of the authors of the RPL ID (BTW it i= s not yet an RFC) clearly states that RPL should be limited to 30 node netw= orks. This seems far less than requirement listed in the this document - e.= g. 100s to 10000s nodes - for AMI networks. I can clearly state, that RPL runs over many more that 30 nodes, based on r= eal deployments. You may know that most of companie's experimentations are not publicly rele= ased. >=20 > On that topic it seems that the authors of this draft have confused AMI w= ith AMR. Where AMR networks are primarily MP2P (unidirectional) which RPL m= ight do well and might scale (if it weren't for the need of sending back AC= Ks and the lossy nature of RF networks), AMI networks are truly bidirection= al with as many, if not more, messages flowing to the meter and home as awa= y. Here RPL is known to be severely lacking. In fact the whole idea of pac= kets flowing down a DAG (isn't that an Oxymoron) was an after-thought as ev= idenced by the fact that multiple other drafts had to be written to make RP= L work in a downward direction. >=20 See pascal's comment on that. > Before this WG moves this draft forward I would request that we see more = than assertions and claims that RPL can perform as "designed" (I use that t= erm loosely). The draft "says" RPL was designed to meet all the requirement= s in the various routing requirement use cases. This is a claim that is sim= ple to make but where has it been shown to be true or proved. >=20 > Where is there an urban, home, industrial or commercial building implemen= tation - any real product, running code - to show that any of these claims = are in fact true or just baseless wishful thinking. >=20 > This would seem a critical piece for any AS and part of a proper procedur= e but, as we all know, when have the Chairs ever acted on proper procedure = in the Working Group. Certainly not all the way back on the issues of IPR d= isclosures, nor the rush to push out the ID to the IETF, the abandonment of= the only draft that tried to justify the work in the first place, ... So w= ould I or why should we expect it now. >=20 > I have gone on too long in this message. I will get to the factual proble= ms (like mixing up AMI and AMR) in my next message. >=20 > Thoroughly fed up, Coffee seems to be a little strong in IETF... > RAV C=E9dric. >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From Daniel.Popa@itron.com Fri Jul 29 07:55: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 6E32F21F8C52 for ; Fri, 29 Jul 2011 07:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 2M6e7N+7YTZJ for ; Fri, 29 Jul 2011 07:55:25 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.115]) by ietfa.amsl.com (Postfix) with ESMTP id C0AB821F8C51 for ; Fri, 29 Jul 2011 07:55:25 -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; Fri, 29 Jul 2011 07:55:24 -0700 From: "Popa, Daniel" To: Jari Arkko , "roll@ietf.org" Date: Fri, 29 Jul 2011 07:55:26 -0700 Thread-Topic: [Roll] review of draft-ietf-roll-applicability-ami Thread-Index: AcxN9gjGOhv2GxMPQlaW58Tk+aqxcgAB8QhA Message-ID: <83027ECE5ECDC04E9BA5350B756A88E159934900F4@ITR-EXMBXVS-1.itron.com> References: <4E32B9D2.3000509@piuha.net> In-Reply-To: <4E32B9D2.3000509@piuha.net> 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 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: Fri, 29 Jul 2011 14:55:26 -0000 Hi Jari,=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Jari Arkko > Sent: Friday, July 29, 2011 9:47 AM > To: roll@ietf.org > Subject: [Roll] review of draft-ietf-roll-applicability-ami >=20 >=20 > I have reviewed this document, and had some comments: >=20 > 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. >=20 > Some additional more detailed comments: >=20 > 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). >=20 > 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? DP> Definitely, there is no single communication link-layer technology that= will be able to satisfy the Smart Grid/Metering requirements. There are us= e cases where one technology shows its limits and so you have to use anothe= r one, generally more expensive, that can help you achieve the requirements= . =20 > > 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. > > >=20 > 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? DP> Based on our experience, the traffic generated by the Metering Applicat= ion is highly asymmetric (much more up than down). However, new application= s (other than metering) can eventually change this ratio, but please keep i= n mind that AMI networks are mainly deployed for Metering Applications! So = we expect traffic to remain asymmetric.=20 DP> Lot of noise is in the air about potential new applications - other tha= n metering apps - that can use the AMI networks, but nothing really concret= e or useful about those applications.=20 DP> Do you think that ISPs will provide their traffic matrix? :)=20 >=20 > Jari >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From wei-peng.chen@us.fujitsu.com Fri Jul 29 07:57: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 90FA521F8C59 for ; Fri, 29 Jul 2011 07:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.127 X-Spam-Level: X-Spam-Status: No, score=-105.127 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 fB5kdZJMO7L6 for ; Fri, 29 Jul 2011 07:57:04 -0700 (PDT) Received: from fujitsu24.fnanic.fujitsu.com (fujitsu24.fnanic.fujitsu.com [192.240.6.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC5021F8C50 for ; Fri, 29 Jul 2011 07:57:04 -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 p6TEtv1x020495; Fri, 29 Jul 2011 07:57:04 -0700 Received: from fujitsuii.fna.fujitsu.com ([133.164.253.2]) by fujitsu24.fnanic.fujitsu.com with ESMTP id xteu6sjp5-1; Fri, 29 Jul 2011 07:57:04 -0700 Received: from toyama.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsuii.fna.fujitsu.com (8.13.8/8.13.8) with ESMTP id p6TEv3qW000668; Fri, 29 Jul 2011 07:57:03 -0700 (PDT) Received: from chenvista (localhost [127.0.0.1]) by toyama.fla.fujitsu.com (8.11.6+Sun/8.11.6) with ESMTP id p6TEuvJ10115; Fri, 29 Jul 2011 07:56:58 -0700 (PDT) From: "Wei-Peng Chen" To: "'Popa, Daniel'" References: <007201cc4d8e$1c8fe970$55afbc50$@chen@us.fujitsu.com> <83027ECE5ECDC04E9BA5350B756A88E1599349005E@ITR-EXMBXVS-1.itron.com> In-Reply-To: <83027ECE5ECDC04E9BA5350B756A88E1599349005E@ITR-EXMBXVS-1.itron.com> Date: Fri, 29 Jul 2011 07:58:03 -0700 Message-ID: <00d501cc4dff$eb8198c0$c284ca40$@chen@us.fujitsu.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D6_01CC4DC5.3F22C0C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxNjhvUoXAcY9D1Rf+8a0jdmUFGHgAZvd+AAAFfJXA= Content-Language: en-us X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-07-29_04:2011-07-29, 2011-07-29, 1970-01-01 signatures=0 Cc: roll@ietf.org Subject: Re: [Roll] Need quantitative requirements in 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: Fri, 29 Jul 2011 14:57:05 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00D6_01CC4DC5.3F22C0C0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Daniel, =20 From: Popa, Daniel [mailto:Daniel.Popa@itron.com]=20 Sent: Friday, July 29, 2011 7:13 AM To: Wei-Peng Chen Cc: roll@ietf.org Subject: RE: Need quantitative requirements in = draft-ietf-roll-applicability-ami-01 =20 Hi Wei-Peng,=20 =20 Thanks for good questions.=20 =20 Please remind that a routing protocol will not be a standalone mechanism = for AMI solution, and so it will not be THE MECHANISM that shall meet = the requirements you are referring to.=20 =20 Let me take an example: latency. I challenge you to explain how someone = can design a system where the routing protocol in the access segment = =E2=80=93 alone - is required to achieve the desired latency, without = taking into account the PHY Layer characteristics (i.e., link capacity, = error rate, and error correction capabilities), the MAC protocol = characteristics (i.e., throughput), channel characteristics = (interferences), interferences mitigation mechanisms, coexistence with = other systems when operating in unlicensed bands, regulation, and so on. = =20 =20 IMHO, the routing protocol is the mechanism that tries to pick the right = path =E2=80=93 as a function of metrics, link characteristics, routing = objectives - and =E2=80=93 in latency example =E2=80=93 will try to = minimize the latency.=20 =20 Let me take a further example: reliability. I challenge again to explain = how someone will design a system where the routing protocol alone has to = provide the required reliability. IMHO, the reliability of a system is a = sum of several mechanisms deployed at different OSI layers (MAC, = Transport and Application most of the time, eventually Net layer) that - = integrated into a solution =E2=80=93 will eventually provide the desired = reliability. =20 Remember that in this document we only focus on routing for the access = segment of an AMI system. I think you expect this Applicability document = to describe a whole system design and how different network components & = functionalities are integrated into AMI systems. Am I right?=20 =20 WC> I fully agree with you that routing is NOT the only mechanism to be = considered to meet the application requirements. All layers and = communication environments are also important factors. But do you agree = that routing will be the key component to decide whether the whole = solution can meet the requirements? (We could lose job if you say no J) = In analogy to solving an optimization problem, the design of a given = routing protocol could be considered as one of the constraints to = maximize users=E2=80=99 satisfaction. IMHO, the purpose of AMI = applicability document should consider whether the constraint of a given = routing protocol is too tight, in particular, from the aspects of = latency and overheads. In other word, given these constraints of = quantitative requirements, our job is to evaluate whether the constraint = of the given routing is active or inactive constraint function.=20 =20 I know it is challenging to evaluate the applicability with = consideration of all network components. But still these quantitative = requirements are important to consider. I am happy to work with you or = other colleagues to make contribution.=20 =20 Wei-Peng =20 Daniel =20 =20 =20 From: Wei-Peng Chen [mailto:wei-peng.chen@us.fujitsu.com]=20 Sent: Thursday, July 28, 2011 9:23 PM To: Popa, Daniel Cc: roll@ietf.org Subject: Need quantitative requirements in = draft-ietf-roll-applicability-ami-01 =20 Hi Daniel, =20 To judge the applicability of RPL in AMI networks, in my opinion, we = need to specify a few key quantitative requirements of AMI networks. But = I cannot find quantitative requirements in neither your ID and RFC5548. = Do you think whether we should specify some key requirements such as:=20 - What is the interval each meter reports its reading? - The quantitative requirements for the latency, reliability, packet = payload, etc. of UL/DL connections, in particular DL connections such as = demand response, distribution automation. (You can find those numbers = specified in UCAIAG=E2=80=99s = SG Network System Requirements Specification and IEEE = P2030 specification.) If I miss any previous draft which has already covered these = quantitative requirements, please let me know.=20 =20 Regards, Wei-Peng =20 =20 ------=_NextPart_000_00D6_01CC4DC5.3F22C0C0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Daniel,

 

From:= = Popa, Daniel [mailto:Daniel.Popa@itron.com]
Sent: Friday, = July 29, 2011 7:13 AM
To: Wei-Peng Chen
Cc: = roll@ietf.org
Subject: RE: Need quantitative requirements in = draft-ietf-roll-applicability-ami-01

 

Hi Wei-Peng,

 

Thanks for good questions.

 

Please remind that a routing protocol will not be a standalone = mechanism for AMI solution, and so it will not be THE MECHANISM that = shall meet the requirements you are referring to. =

 

Let me take an example: latency. I challenge you to explain how = someone can design a system where the routing protocol in the access = segment =E2=80=93 alone - is required to achieve the desired latency, = without taking into account the PHY Layer characteristics (i.e., link = capacity, error rate, and error correction capabilities), the MAC = protocol characteristics (i.e., throughput), channel characteristics = (interferences), interferences mitigation mechanisms, coexistence with = other systems when operating in unlicensed bands, regulation, and so on. =   

 

IMHO, the routing protocol is the mechanism that tries to pick the = right path =E2=80=93 as a function of metrics, link characteristics, = routing objectives - and =E2=80=93 in latency example =E2=80=93 will try = to minimize the latency.

 

Let me take a further example: reliability. I challenge again to = explain how someone will design a system where the routing protocol = alone has to provide the required reliability. IMHO, the reliability of = a system is a sum of several mechanisms deployed at different OSI layers = (MAC, Transport and Application most of the time, eventually Net layer) = that - integrated into a solution =E2=80=93 will eventually provide the = desired reliability.

 

Remember that in this document we only focus on routing for the = access segment of an AMI system. I think you expect this Applicability = document to describe a whole system design and how different network = components & functionalities are integrated into AMI systems. Am I = right?

 

W= C> I fully agree with you that routing is NOT the only mechanism to = be considered to meet the application requirements. All layers and = communication environments are also important factors. But do you agree = that routing will be the key component to decide whether the whole = solution can meet the requirements? (We could lose job if you say no = J)= In analogy to solving an optimization problem, the design of a given = routing protocol could be considered as one of the constraints to = maximize users=E2=80=99 satisfaction. IMHO, the purpose of AMI = applicability document should consider whether the constraint of a given = routing protocol is too tight, in particular, from the aspects of = latency and overheads. In other word, given these constraints of = quantitative requirements, our job is to evaluate whether the constraint = of the given routing is active or inactive constraint function. =

<= o:p> 

I= know it is challenging to evaluate the applicability with consideration = of all network components. But still these quantitative requirements are = important to consider. I am happy to work with you or other colleagues = to make contribution.

<= o:p> 

W= ei-Peng

 

Daniel

 

 

 

From:= = Wei-Peng Chen [mailto:wei-peng.chen@us.fujitsu.com]
Sent: = Thursday, July 28, 2011 9:23 PM
To: Popa, Daniel
Cc: = roll@ietf.org
Subject: Need quantitative requirements in = draft-ietf-roll-applicability-ami-01

 

Hi = Daniel,

 

To = judge the applicability of RPL in AMI networks, in my opinion, we need = to specify a few key quantitative requirements of AMI networks. But I = cannot find quantitative requirements in neither your ID and RFC5548. Do = you think whether we should specify some key requirements such as: =

- What is the interval each = meter reports its reading?

- The = quantitative requirements for the latency, reliability, packet payload, = etc. of UL/DL connections, in particular DL connections such as demand = response, distribution automation. (You can find those numbers specified = in UCAIAG=E2=80=99s SG Network System = Requirements Specification = and IEEE P2030 specification.)

If I = miss any previous draft which has already covered these quantitative = requirements, please let me know.

 

Regards,

Wei-Peng

 

 =

------=_NextPart_000_00D6_01CC4DC5.3F22C0C0-- From wei-peng.chen@us.fujitsu.com Fri Jul 29 08:00: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 CC3E921F8BA5 for ; Fri, 29 Jul 2011 08:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.133 X-Spam-Level: X-Spam-Status: No, score=-105.133 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 pRvY-Rbyb6iX for ; Fri, 29 Jul 2011 08:00:54 -0700 (PDT) Received: from fujitsu24.fnanic.fujitsu.com (fujitsu24.fnanic.fujitsu.com [192.240.6.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1B36121F8B21 for ; Fri, 29 Jul 2011 08:00:54 -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 p6TEkuc1012484; Fri, 29 Jul 2011 08:00:53 -0700 Received: from fujitsuii.fna.fujitsu.com ([133.164.253.2]) by fujitsu24.fnanic.fujitsu.com with ESMTP id xteu6sjsj-1; Fri, 29 Jul 2011 08:00:53 -0700 Received: from toyama.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsuii.fna.fujitsu.com (8.13.8/8.13.8) with ESMTP id p6TF0qix000990; Fri, 29 Jul 2011 08:00:53 -0700 (PDT) Received: from chenvista (localhost [127.0.0.1]) by toyama.fla.fujitsu.com (8.11.6+Sun/8.11.6) with ESMTP id p6TF0oJ10204; Fri, 29 Jul 2011 08:00:51 -0700 (PDT) From: "Wei-Peng Chen" To: "'Popa, Daniel'" , "'Ietf Roll'" , "'Thomas Heide Clausen'" , "'JP Vasseur'" References: <1311914243.47928.YahooMailClassic@web113913.mail.gq1.yahoo.com> <008e01cc4dad$a9d48560$fd7d9020$@chen@us.fujitsu.com> <83027ECE5ECDC04E9BA5350B756A88E15993490085@ITR-EXMBXVS-1.itron.com> In-Reply-To: <83027ECE5ECDC04E9BA5350B756A88E15993490085@ITR-EXMBXVS-1.itron.com> Date: Fri, 29 Jul 2011 08:01:56 -0700 Message-ID: <00dd01cc4e00$76735c20$635a1460$@chen@us.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxNqTfthO11lTsSS96W+044e7X8nwAAbQWgABPUyZAAARd8sA== Content-Language: en-us X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-07-29_04:2011-07-29, 2011-07-29, 1970-01-01 signatures=0 Cc: roll@ietf.org Subject: Re: [Roll] Need quantitative requirements in 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: Fri, 29 Jul 2011 15:00:54 -0000 Hi Daniel, -----Original Message----- From: Popa, Daniel [mailto:Daniel.Popa@itron.com]=20 Sent: Friday, July 29, 2011 7:21 AM To: Wei-Peng Chen; 'Ietf Roll'; 'Thomas Heide Clausen'; 'JP Vasseur' Cc: roll@ietf.org Subject: RE: [Roll] Need quantitative requirements in = draft-ietf-roll-applicability-ami-01 Hi Wei-Peng,=20 =20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of > Wei-Peng Chen > Sent: Friday, July 29, 2011 1:09 AM > To: 'Ietf Roll'; 'Thomas Heide Clausen'; 'JP Vasseur' > Cc: roll@ietf.org > Subject: Re: [Roll] Need quantitative requirements in draft-ietf-roll- > applicability-ami-01 >=20 > Hi JP, >=20 > As I am a newbie to IETF, what I said may not make sense to the > community. And I appreciate your comment. > However, I agree with Thomas and Ietf that traffic patterns of the > targeted applications and communication environments are important to > understand the applicability of a given routing protocol. We need to > consider any quantitative requirements specified by utilities. In > particular, meters, once installed, would last for 20+ years.=20 DP> The hardware yes, it would last for 20 years. But not the software = (in particular the embedded networking software), because an AMI system = has the capability of doing firmware upgrade and so upgrade/install new = features. What you mention is a trade-off between cost and flexibility. = =20 WC> Thanks. I fully agree with you. Therefore the hardware requirement = of a routing protocol is very important to consider. My main point is: = the design of AMI routing should meet the requirements of the future = applications (of course with consideration of reasonable cost) and then = prepare the hardware platform for 20+ years. Wei-Peng=20 It is > important to consider the requirements of the potential applications = in > the near future. >=20 > Regards, > Wei-Peng >=20 > -----Original Message----- > From: Ietf Roll [mailto:ietfroll@yahoo.com] > Sent: Thursday, July 28, 2011 9:37 PM > To: Thomas Heide Clausen; JP Vasseur > Cc: roll@ietf.org; Wei-Peng Chen > Subject: Re: [Roll] Need quantitative requirements in draft-ietf-roll- > applicability-ami-01 >=20 > This is what you are saying now in your revisionist history, but > certainly not what you said. >=20 > It is important to understand the total communications environment = that > the routing protocol must work in or do you forget the now abandoned > draft on protocol survey made a big deal about the routing maintenance > overhead (as computed by comparing data vs maintenance packets.) >=20 > If I'm only sending a packet once in a long while and latency isn't an > issue I could search for path on each packet, could I not. >=20 > In a "good" applicability statement it would seem beneficial to well > specify the network you are claiming applicability to. >=20 >=20 > --- On Fri, 7/29/11, JP Vasseur wrote: >=20 > > From: JP Vasseur > > Subject: Re: [Roll] Need quantitative requirements in draft-ietf- > roll-applicability-ami-01 > > To: "Thomas Heide Clausen" > > Cc: "roll@ietf.org" , "Wei-Peng Chen" peng.chen@us.fujitsu.com> > > Date: Friday, July 29, 2011, 4:03 AM > > > > On Jul 28, 2011, at 11:22 PM, Thomas Heide > > Clausen wrote: > > > > > > > > On 28 Jul 2011, at 22:36, JP Vasseur > > wrote: > > > > Dear > > Wei-Peng, > > On Jul 28, 2011, at 9:23 PM, Wei-Peng Chen > > wrote: > > Hi Daniel, To judge the applicability of RPL in AMI networks, in > > my opinion, we need to specify a few key quantitative > > requirements of AMI networks. But I cannot find quantitative > > requirements in neither your ID and RFC5548. Do you think > > whether we should specify some key requirements such > > as:- What is the interval each meter reports its > > reading?- The quantitative requirements for the latency, > > reliability, packet payload, etc. of UL/DL connections, in > > particular DL connections such as demand response, > > distribution automation. (You can find those numbers > > specified in UCAIAG=E2=80=99s SG > > Network System Requirements Specification and > > IEEE P2030 specification.)If I miss any previous draft which has > already > > covered these quantitative requirements, please let me > > know. > > Just an important clarification: this is an RPL > > applicability statement, thus many of the items list > > aboveare out of the scope of such a > > document. > > > > Just to clarify, you are saying that RPL is not > > applicable for AMI, and therefore these considerations are > > out of scope. I agree with that,. > > > > Thomas, where do you see that I said this > > ?I said that "interval each meter reports > > its reading", "packet payload", =E2=80=A6 are not > > routing parameters, thus there are of the scope of > > this document, which is a RPL AMI applicability statement. > > In other words, the objective is to explain how RPL can be > > used for AMI purposes. Non routing related issues are thus > > out of the scope. I am just stating the obvious > > here. > > Thanks. > > JP. > > > > I, then, wonder > > why draft-ietf-roll-applicability-ami exists as WG > > document - as you say that AMI is out of scope for > > RPL. > > Thomas > > > > Thanks. > > JP. > > Regards,Wei-Peng > > > > _______________________________________________ > > 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 > > > > > > -----Inline Attachment Follows----- > > > > _______________________________________________ > > 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 prvs=1841d2f10=bora@pnnl.gov Fri Jul 29 08:33: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 D5B5F21F87C9 for ; Fri, 29 Jul 2011 08:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, 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 uzBOC7Kt7Bd8 for ; Fri, 29 Jul 2011 08:33:50 -0700 (PDT) Received: from emailgw03.pnl.gov (emailgw03.pnl.gov [192.101.109.31]) by ietfa.amsl.com (Postfix) with ESMTP id 3606B21F87C2 for ; Fri, 29 Jul 2011 08:33:50 -0700 (PDT) Received: from emailhub02.pnl.gov ([130.20.251.62]) by emailgw03.pnl.gov with ESMTP/TLS/AES128-SHA; 29 Jul 2011 08:33:49 -0700 Received: from Email05.pnl.gov ([130.20.251.69]) by emailhub02.pnl.gov ([130.20.251.62]) with mapi; Fri, 29 Jul 2011 08:33:39 -0700 From: "Akyol, Bora A" To: "roll@ietf.org" Date: Fri, 29 Jul 2011 08:33:49 -0700 Thread-Topic: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Thread-Index: AcxNe/O/pKDoq/GeRgaP315mYcm0lAAiOvFA Message-ID: References: <20110725182837.19651.12235.idtracker@ietfa.amsl.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 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: Fri, 29 Jul 2011 15:33:50 -0000 I think the statement about AMI networks being used as an almost general pu= rpose 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 shi= ed away from this vision. Secondly, there are a lot more AMI deployments no= t using wireless mesh networks, e.g. using cellular modem, powerline carrie= r, etc. Is it possible to tone this "marketing" text Section 1.1. down and also pot= entially remove Gas & Water meters from the scope of this document. Regards -- Bora Akyol, Pacific Northwest National Laboratory +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov From angelo.castellani@gmail.com Fri Jul 29 12:08: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 7D2B521F87C7 for ; Fri, 29 Jul 2011 12:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 JvXlgytOOi+g for ; Fri, 29 Jul 2011 12:08:54 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C733A21F87A4 for ; Fri, 29 Jul 2011 12:08:54 -0700 (PDT) Received: by qyk9 with SMTP id 9so20034qyk.10 for ; Fri, 29 Jul 2011 12:08:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=wMLkjeQHZ6bX3F0GWGnPzlI5sr15nUcQjxRCP5WjIzg=; b=Y+Co8S6QT0DCtOJeS8vcOHlFF2DkOWHGm+otGdAUc1Z1pZL2skvBwGiQZZVW4gpNy7 Vo3NqY4m3c6Co0h3rGt6gND2lszoQ46xBGcVUh5DfYnd0X7Q4M02zclxm2m5FOHRjoih str9fwsT8wrVxB0wT+/wJ+9zz/kJdXd+adrmQ= Received: by 10.229.62.103 with SMTP id w39mr1366476qch.59.1311966534132; Fri, 29 Jul 2011 12:08:54 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.229.233.209 with HTTP; Fri, 29 Jul 2011 12:08:34 -0700 (PDT) From: "Angelo P. Castellani" Date: Fri, 29 Jul 2011 15:08:34 -0400 X-Google-Sender-Auth: Toj2OEr8eNGflFB1qeZW37gdGVs Message-ID: To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Roll] Routing Tables 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, 29 Jul 2011 19:08:55 -0000 All, as suggested by JP, I bring to the list this question. Given that some deployments (AMI) will target thousands of nodes, I have the following questions: - is storing mode applicable in that scenario? if yes: - roughly which requirements will be posed on the RAM required to handle that routing table? - will be provided some insight on how to handle RPL storing mode in that environments, such the use of some advanced routing table management technique (i.e. aggregation)? Best, Angelo From prvs=183b7bb22=bora@pnnl.gov Thu Jul 28 16:13: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 DFB1321F8AB8 for ; Thu, 28 Jul 2011 16:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, 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 exZ15ttZTLJz for ; Thu, 28 Jul 2011 16:13:26 -0700 (PDT) Received: from emailgw03.pnl.gov (emailgw03.pnl.gov [192.101.109.31]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9F521F89B8 for ; Thu, 28 Jul 2011 16:13:26 -0700 (PDT) Received: from emailhub02.pnl.gov ([130.20.251.62]) by emailgw03.pnl.gov with ESMTP/TLS/AES128-SHA; 28 Jul 2011 16:13:25 -0700 Received: from Email05.pnl.gov ([130.20.251.69]) by emailhub02.pnl.gov ([130.20.251.62]) with mapi; Thu, 28 Jul 2011 16:13:18 -0700 From: "Akyol, Bora A" To: "roll@ietf.org" Date: Thu, 28 Jul 2011 16:13:23 -0700 Thread-Topic: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Thread-Index: AcxNe/O/pKDoq/GeRgaP315mYcm0lA== Message-ID: In-Reply-To: <20110725182837.19651.12235.idtracker@ietfa.amsl.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 X-Mailman-Approved-At: Fri, 29 Jul 2011 12:17:58 -0700 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: Thu, 28 Jul 2011 23:13:27 -0000 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. 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. Regards --=20 Bora Akyol, Pacific Northwest National Laboratory +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov From cedric-2.lavenu@edf.fr Fri Jul 29 13:43: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 EEF6711E80A8 for ; Fri, 29 Jul 2011 13:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.817 X-Spam-Level: X-Spam-Status: No, score=-3.817 tagged_above=-999 required=5 tests=[AWL=-1.565, BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 PffzWEhZG9yo for ; Fri, 29 Jul 2011 13:43:08 -0700 (PDT) Received: from mtagate1.edf.fr (mtagate1.edf.fr [192.54.193.60]) by ietfa.amsl.com (Postfix) with ESMTP id C1C0211E80A7 for ; Fri, 29 Jul 2011 13:43:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.67,288,1309730400"; d="scan'208,147";a="323862092" Received: from unknown (HELO xhub003au.notes.edfgdf.fr) ([10.122.19.74]) by CLAF1MTA1.edf.fr with ESMTP; 29 Jul 2011 21:51:46 +0200 To: roll@ietf.org MIME-Version: 1.0 X-KeepSent: 17B59B34:07C7DA5D-C12578DC:006D1D17; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 HF1234 August 14, 2008 From: Cedric-2 LAVENU Message-ID: Date: Fri, 29 Jul 2011 22:43:00 +0200 Content-Type: multipart/related; boundary="=_related 0071CC4EC12578DC_=" Subject: [Roll] Some additional thoughts... 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, 29 Jul 2011 20:43:16 -0000 Message en plusieurs parties au format MIME --=_related 0071CC4EC12578DC_= Content-Type: multipart/alternative; boundary="=_alternative 0071CC4EC12578DC_=" --=_alternative 0071CC4EC12578DC_= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" All, Regarding the concerns I have been sharing with you during this=20 afternoon's ROLL meeting, I'd just like to precise a bit more my thoughts. As a utility, we cannot just choose a routing protocol because some people=20 within a working group are just stating that it works. I think that=20 everybody's aware of the important investment an AMI is representing for a=20 utility... Just to say that mistakes are not allowed. The use of validated=20 and mature technologies is a key requirement for a successful massive=20 roll-out of a 20-year lifespan AMI.=20 I'm actually not pretending to be a routing expert, but I think that we=20 cannot make the right decision on the basis of the recently released AMI=20 applicability statement.=20 We really need some more accurate results based on simulations and=20 experimentation (field, lab...) to get an idea on how RPL (either in=20 storing or non-storing mode) performs for different traffic patterns. It's=20 a must to get figures for certain key indicators (amount of generated=20 control traffic, routing table entries and associated RAM,...). In the=20 perspective of an end-user or even an AMI vendor, the limits have to be=20 known to be able to judge whether the protocol is suitable or not for a=20 given PHY/MAC medium (wireless, narrowband PLC, broadband PLC,...) and=20 with respect to the used application protocol (which is defining the=20 traffic pattern). It would also be great to get more accurate information=20 on how to tune all the appropriate parameters in different environments.=20 Kind regards, C=E9dric =20 =20 C=E9dric LAVENU Ing=E9nieur - Syst=E8mes de comptage EDF - R&D D=E9partement MIRE 1 avenue du g=E9n=E9ral de Gaulle 92141 Clamart =20 cedric-2.lavenu@edf.fr T=E9l. : +33(0)1 47 65 27 29 =20 Un geste simple pour l'environnement, n'imprimez ce message que si vous en=20 avez l'utilit=E9. Ce message et toutes les pi=E8ces jointes (ci-apr=E8s le 'Message') sont = =E9tablis =E0 l'intention exclusive des destinataires et les informations q= ui y figurent sont strictement confidentielles. Toute utilisation de ce Mes= sage non conforme =E0 sa destination, toute diffusion ou toute publication = totale ou partielle, est interdite sauf autorisation expresse. Si vous n'=EAtes pas le destinataire de ce Message, il vous est interdit de= le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou pa= rtie. Si vous avez re=E7u ce Message par erreur, merci de le supprimer de v= otre syst=E8me, ainsi que toutes ses copies, et de n'en garder aucune trace= sur quelque support que ce soit. Nous vous remercions =E9galement d'en ave= rtir imm=E9diatement l'exp=E9diteur par retour du message. Il est impossible de garantir que les communications par messagerie =E9lect= ronique arrivent en temps utile, sont s=E9curis=E9es ou d=E9nu=E9es de tout= e erreur ou virus. ____________________________________________________ This message and any attachments (the 'Message') are intended solely for th= e addressees. The information contained in this Message is confidential. An= y use of information contained in this Message not in accord with its purpo= se, any dissemination or disclosure, either whole or partial, is prohibited= except formal approval. If you are not the addressee, you may not copy, forward, disclose or use an= y part of it. If you have received this message in error, please delete it = and all copies from your system and notify the sender immediately by return= message. E-mail communication cannot be guaranteed to be timely secure, error or vir= us-free. --=_alternative 0071CC4EC12578DC_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1"
All,

Regarding the concerns I have been s= haring with you during this afternoon's ROLL meeting, I'd just like to precise a bit more my thoughts.
As a utility, we cannot just choose a routing protocol because some people within a working group are just stating that it works. I think that everybody's aware of the important investment an AMI is representing for a utility... Just to say that mistakes are not allowed. The use of validated and mature technologies is a key requirement for a successful massive roll-out of a 20-year lifespan AMI.

I'm actually not pretending to be a routing expert, but I think that we cannot make the right decision on the basis of the recently released AMI applicability statement.
We really need some more accurate results based on simulations and experime= ntation (field, lab...) to get an idea on how RPL (either in storing or non-storing mode) performs for different traffic patterns. It's a must to get figures for certain key indicators (amount of generated control traffic, routing table entries and associated RAM,...). In the perspective of an end-user or even an AMI vendor, the limits have to be known to be able to judge whether the protocol is suitable or not for a given PHY/MAC medium (wireles= s, narrowband PLC, broadband PLC,...) and with respect to the used application protocol (which is defining the traffic pattern). It would also be great to get more accurate information on how to tune all the appropriate paramet= ers in different environments.

Kind regards,

C=E9dric
   
C=E9dric LAVENU
Ing=E9nieur - Syst=E8mes de comptage

EDF - R&D
D=E9partement MIRE
1 avenue du g=E9n=E9ral de Gaulle
92141 Clamart


cedric-2.lavenu@edf.fr=
T=E9l. : +33(0)1 47 65 27= 29
  Un geste simple pour l'en= vironnement, n'imprimez ce message que si vous en avez l'utilit=E9.




Ce message et toutes les pi=E8ces jointes (ci-apr=E8s le 'Message') sont = =E9tablis =E0 l'intention exclusive des destinataires et les informations q= ui y figurent sont strictement confidentielles. Toute utilisation de ce Mes= sage non conforme =E0 sa destination, toute diffusion ou toute publication = totale ou partielle, est interdite sauf autorisation expresse.

Si vous n'=EAtes pas le destinataire de ce Message, il vous est interdit de= le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou pa= rtie. Si vous avez re=E7u ce Message par erreur, merci de le supprimer de v= otre syst=E8me, ainsi que toutes ses copies, et de n'en garder aucune trace= sur quelque support que ce soit. Nous vous remercions =E9galement d'en ave= rtir imm=E9diatement l'exp=E9diteur par retour du message.

Il est impossible de garantir que les communications par messagerie =E9lect= ronique arrivent en temps utile, sont s=E9curis=E9es ou d=E9nu=E9es de tout= e erreur ou virus.
____________________________________________________

This message and any attachments (the 'Message') are intended solely for th= e addressees. The information contained in this Message is confidential. An= y use of information contained in this Message not in accord with its purpo= se, any dissemination or disclosure, either whole or partial, is prohibited= except formal approval.

If you are not the addressee, you may not copy, forward, disclose or use an= y part of it. If you have received this message in error, please delete it = and all copies from your system and notify the sender immediately by return= message.

E-mail communication cannot be guaranteed to be timely secure, error or vir= us-free.
--=_alternative 0071CC4EC12578DC_=-- --=_related 0071CC4EC12578DC_= Content-Type: image/gif Content-ID: <_1_0B4F068C0B4F02A40071CC4EC12578DC> Content-Transfer-Encoding: base64 R0lGODlhbgA8APcAAP7///3+/z9Xh7/H13+Pr//Pxv7+///z8P9xVv9NLP+gjv/n4v/b1P+4qv+s nF9zm/+Icv9ZOg8taf+UgP99ZP/DuP9lSN/j6y9Jfc/V4e/x9Y+duW+BpZ+rw09lkR87c/39/6+5 zfz9/wAgYP9CHv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAABuADwA AAj/AEsIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEkS44EGExyUXJnxwAQE ExRYIEEigkqWOCcySECzZ80DOYNCXMDTJ80KQpM2nGmUptKnCRs07Qm1akEEU0kkAGrVKtasCLpa pZCVRFixUMlmvYlWaYGyBdqSVKBQQVa5JEk0UMjUpwW8It9GUHigL829gEEyZXuwcM+zBSsoQPA1 AQIIDbgi1NCBgAABHDZcMDigtGnTGg6eXl064gEFarUyWMggbkGXRbMmYEyQgIQRwIOPeJB6oPDj IzCEKCgAufCIdo0mmA2xQe6yNCEYfOA8OIbiJboL/39AsLn4iBGmJpiwYEEBBwqoH3yLvSnSgRvE BydgXD9wDgOZ1x1E9NXX0wIIRWfgYwT9FtwDF1xAgHAS9AccfyWEICBwAwgkIAasDbVgT7wNVOCI JAwUgnACEOSBcB2Gt5+L43kYXIsWKWggXQgV4KN7Pk6m20AcCLdBb8JhmCRBGlBoI3A4WgTBiLZB xIBhNFEQoHAYfPbZB0vKeCFzwo0moAReftbBRA4YiJhEDPgUQQWabagfjmEOxF1wHdqZZ0QLTDnV nBY5AJ8DCJbn340C/VlCkXyW4OeMFZ300mUOVPnRhg8Q4Omnn64p5ggYbhlcBpIGh2aaoiZGZnBH Lv/kKJjBPTlClEpVQNkEmUE0oXcHoWohqQQNwKKtuI60gAIKaFZCnD4lAEGiDGVwnAejCZQBd8s1 SmkJAzgInKgCJhtSgdoN5FhTEzibkJ9dCvfBsAIQ8AAGx2Fg6q0lHZAeTYMR5NKg8iWUgbjixbqo BMKmCmVJsTllkI49JXCfQgfrB6G34nkAnsMjzCvSAl/55K5AEfuk6WYc0HojB9l6mKaXHoi2XZob kXzfARUI2lTBA0HbVALUVhszYP8amFDJRkHm6kM+Y5dAQlEbBfTTC0llYLoHpezTBFg/dKJuJw90 XdNhO7RA0lmtXNAC1k2lZdoNLVCWBW435vXFdDP11ICQWeZdF00JvNk3S7UdrvjijDfu+OOQRy75 5JRXjjUAAHCEuVABiJB5CSIEAIAIpItQQucGnG5656SLXroIqQPAeuinBwB66bYLNLvtpGcegO2z Y/666qaXYEDvo5cufO7Jk75Q55kfL7wBm7OuuuqYL3+87SCEjnnqv4MOwuYDQb9567XfDkDs3vtO OvjIw7796My3/7znxrNPvfuwd4595vSbH+2ylz4RjO9zuvPc55QXvvcJhH7VQ58BFdg/2NHvgfZT CPQI0jzg/S50q8Nd80x3wdIVUHnlwx3oOvc72x0vfuhjIexmKDzlXbAEI1RIQAAAOw== --=_related 0071CC4EC12578DC_= Content-Type: image/gif Content-ID: <_1_0B4F15CC0B4F11E40071CC4EC12578DC> Content-Transfer-Encoding: base64 R0lGODlhbgAeAPcRAD+J6O/1/d/r+5/E8y9/5g9r4s/h+R915I+68W+m7q/N9V+c7E+T6r/X93+w 8ABi4f///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAABEALAAAAABuAB4A AAj/ACMIHEiwoMGDCBMqXMiwocOHECNKnEixosWLEyFoDEDggcePIEOGTKCxpEmMKFOWdCCypcsH BkyeTEmz4sqXLgksYPmggcySNYNKvInz44EBATQK8OjzJwShUB3eJAChwQKXDmQ2YOr0adSvCYkm hTBA5ICfPJv+BMvWINGzGnl6ROD0AFenbfMKJFogJoQAHwE43Xp3rd62RB8UaAqgsMmOjmceBpvY I4EEHQ84TQBSrczJbCuPRBvSs2TQUEWDVGBSQOPSXVF/Vf3RZwAFV1uaBio7ddyXBOzi3K2xt28I cou6JO7VeM2Sr5Vjje38OQQEihM42M69u3fuuf1+XK5OE4KBAg/gdl0PgcEDAmNPk78IAbL0oiTH z8eYvGUB7pwVZdp+KN1noGDyETiRfQbilFWCCkYUgAMAVGjhhRhmiKF6vEVIEXsghlichx+KaCJe JKao4oos9hYQADs= --=_related 0071CC4EC12578DC_=-- From ulrich@herberg.name Fri Jul 29 14:54: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 A673411E80B7 for ; Fri, 29 Jul 2011 14:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 oF+hZymT2D0Z for ; Fri, 29 Jul 2011 14:54:16 -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 B870A11E8096 for ; Fri, 29 Jul 2011 14:54:16 -0700 (PDT) Received: by vxi40 with SMTP id 40so3811306vxi.31 for ; Fri, 29 Jul 2011 14:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:content-type; bh=qSjgLImIr72na3TMwo+P8dxrDQL/MmTKYMVMbYAPsRM=; b=w6Mq+DBaXnzw3V92RD4Lfz4yCTcdW8rhQuvpOaVjeW0pFzgK9kR/OETXHqkGlCztyI FsifTNfGoZtKa8Mzl0YVqvcmGFHb6MPNDBJTFwCjl7t2PRIHKCEibJgBjIZ4snpdS3bT P0haaWE4pjpX9mSPq/TsywqLejrHB/pES52pE= MIME-Version: 1.0 Received: by 10.220.160.208 with SMTP id o16mr488980vcx.205.1311976456035; Fri, 29 Jul 2011 14:54:16 -0700 (PDT) Received: by 10.220.2.15 with HTTP; Fri, 29 Jul 2011 14:54:16 -0700 (PDT) Date: Fri, 29 Jul 2011 17:54:16 -0400 Message-ID: From: Ulrich Herberg To: roll WG Content-Type: multipart/alternative; boundary=0016e68ac4de9d9d0304a93c52ee Subject: [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: Fri, 29 Jul 2011 21:54:17 -0000 --0016e68ac4de9d9d0304a93c52ee Content-Type: text/plain; charset=ISO-8859-1 Hi, is the intended status of draft-ietf-roll-applicability-ami-01 really Standards Track? Or should it be informational? Regards Ulrich --0016e68ac4de9d9d0304a93c52ee Content-Type: text/html; charset=ISO-8859-1 Hi,

is the intended status of draft-ietf-roll-applicability-ami-01 really Standards Track? Or should it be informational?

Regards
Ulrich
--0016e68ac4de9d9d0304a93c52ee-- From jpv@cisco.com Sat Jul 30 08:17: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 7D96B21F84F2 for ; Sat, 30 Jul 2011 08:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.423 X-Spam-Level: X-Spam-Status: No, score=-102.423 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 JyukvS9kNNsO for ; Sat, 30 Jul 2011 08:17:48 -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 43A3021F880C for ; Sat, 30 Jul 2011 08:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=14381; q=dns/txt; s=iport; t=1312039069; x=1313248669; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=ZdkNgjD2FVvy4L+FR2kVfMem2ObUJd3awJ6WyBgwDXA=; b=m3SP1GzM5mO1xNXF5M2DhVPznXIT81LtEfzwrXw8TMngxxEgnXpjJLqP HK3IfgaEWt+59jJ16+rpHWky72gQyho6Arnlkbz8uSsvJJGrOfXArtewt wucZDiqj1SqlVgpz5b3r6H1yDmua0VGFSm+OHpFtbzJnzYMdO4CNiCQ5E g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGQfNE6rRDoG/2dsb2JhbABBp2J3gTkHAQEBAQIBAQEBCQYBWAMCCRALRicwBhMih0oEoiEBnXyFY18EknuFBwmLcA X-IronPort-AV: E=Sophos;i="4.67,292,1309737600"; d="scan'208,217";a="8075238" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-8.cisco.com with ESMTP; 30 Jul 2011 15:17:48 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6UFHmLs018592; Sat, 30 Jul 2011 15:17:48 GMT Received: from xfe-sjc-232.amer.cisco.com ([128.107.191.79]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 30 Jul 2011 08:17:48 -0700 Received: from [10.2.206.166] ([10.21.92.23]) by xfe-sjc-232.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 30 Jul 2011 08:17:47 -0700 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_900DA887-51F5-4234-B635-1A8BB6350A19" From: JP Vasseur In-Reply-To: Date: Sat, 30 Jul 2011 11:17:46 -0400 Message-Id: <4184C26A-7BC4-444E-9018-1D1456DBDD5A@cisco.com> References: To: Cedric-2 LAVENU X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 30 Jul 2011 15:17:47.0679 (UTC) FILETIME=[D6D93AF0:01CC4ECB] Cc: roll@ietf.org Subject: Re: [Roll] Some additional thoughts... 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, 30 Jul 2011 15:17:51 -0000 --Apple-Mail=_900DA887-51F5-4234-B635-1A8BB6350A19 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Cedric, On Jul 29, 2011, at 4:43 PM, Cedric-2 LAVENU wrote: >=20 > All,=20 >=20 > Regarding the concerns I have been sharing with you during this = afternoon's ROLL meeting, I'd just like to precise a bit more my = thoughts.=20 > As a utility, we cannot just choose a routing protocol because some = people within a working group are just stating that it works. I think = that everybody's aware of the important investment an AMI is = representing for a utility... Just to say that mistakes are not allowed. = The use of validated and mature technologies is a key requirement for a = successful massive roll-out of a 20-year lifespan AMI.=20 >=20 > I'm actually not pretending to be a routing expert, but I think that = we cannot make the right decision on the basis of the recently released = AMI applicability statement.=20 > We really need some more accurate results based on simulations and = experimentation (field, lab...) to get an idea on how RPL (either in = storing or non-storing mode) performs for different traffic patterns. = It's a must to get figures for certain key indicators (amount of = generated control traffic, routing table entries and associated = RAM,...). In the perspective of an end-user or even an AMI vendor, the = limits have to be known to be able to judge whether the protocol is = suitable or not for a given PHY/MAC medium (wireless, narrowband PLC, = broadband PLC,...) and with respect to the used application protocol = (which is defining the traffic pattern). It would also be great to get = more accurate information on how to tune all the appropriate parameters = in different environments.=20 Many Thanks for sharing your thoughts Cedric, your input is critically = important. I think that we had a very fruitful discussion on the subject matter = during our ROLL WG meeting yesterday. What we now need to do is to compile the set of comments that were made = at the mic yesterday and have a consensus on what needs to be described = in the AMI applicability document. That will be done soon. As a reminder, as clearly spelled out yesterday, the aim of this = document is not to prove that a protocol work in an AS (applicability = statement). As a reminder: " * An Applicability Statement specifies how, and under what = circumstances, one or more TSs may be applied to support a particular = Internet capability. * An AS identifies the relevant TSs and the specific way in which they = are to be combined, and may also specify particular values or ranges of = TS parameters or subfunctions of a TS protocol that must be = implemented." On the other hand, as discussed, we should provide guidance, explain = which building blocks of the protocol should be used in light of the = requirements, the implications on the protocol behavior when tuning a = specific timer, etc =85 As pointed out by Jari, one could provide = pointers on past experience, simulations papers, etc =85 too. More soon, and thanks to all of you for the fruitful discussion. We will = summarize it in the minutes, and authors please come back to the list to = propose next steps, have all of us providing feed-back and reach a = consensus. Thanks. JP. >=20 > Kind regards,=20 > C=E9dric=20 > =20 > C=E9dric LAVENU > Ing=E9nieur - Syst=E8mes de comptage > EDF - R&D > D=E9partement MIRE > 1 avenue du g=E9n=E9ral de Gaulle > 92141 Clamart >=20 > cedric-2.lavenu@edf.fr=20 > T=E9l. : +33(0)1 47 65 27 29 > Un geste simple pour l'environnement, n'imprimez = ce message que si vous en avez l'utilit=E9. >=20 >=20 >=20 >=20 > Ce message et toutes les pi=E8ces jointes (ci-apr=E8s le 'Message') = sont =E9tablis =E0 l'intention exclusive des destinataires et les = informations qui y figurent sont strictement confidentielles. Toute = utilisation de ce Message non conforme =E0 sa destination, toute = diffusion ou toute publication totale ou partielle, est interdite sauf = autorisation expresse. >=20 > Si vous n'=EAtes pas le destinataire de ce Message, il vous est = interdit de le copier, de le faire suivre, de le divulguer ou d'en = utiliser tout ou partie. Si vous avez re=E7u ce Message par erreur, = merci de le supprimer de votre syst=E8me, ainsi que toutes ses copies, = et de n'en garder aucune trace sur quelque support que ce soit. Nous = vous remercions =E9galement d'en avertir imm=E9diatement l'exp=E9diteur = par retour du message. >=20 > Il est impossible de garantir que les communications par messagerie = =E9lectronique arrivent en temps utile, sont s=E9curis=E9es ou d=E9nu=E9es= de toute erreur ou virus. > ____________________________________________________ >=20 > This message and any attachments (the 'Message') are intended solely = for the addressees. The information contained in this Message is = confidential. Any use of information contained in this Message not in = accord with its purpose, any dissemination or disclosure, either whole = or partial, is prohibited except formal approval. >=20 > If you are not the addressee, you may not copy, forward, disclose or = use any part of it. If you have received this message in error, please = delete it and all copies from your system and notify the sender = immediately by return message. >=20 > E-mail communication cannot be guaranteed to be timely secure, error = or virus-free._______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail=_900DA887-51F5-4234-B635-1A8BB6350A19 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Cedric,


On Jul 29, 2011, at 4:43 PM, = Cedric-2 LAVENU wrote:


All,

Regarding the concerns I have = been sharing with you during this afternoon's ROLL meeting, I'd just like to precise a bit more my thoughts.
As a utility, we cannot just = choose a routing protocol because some people within a working group are just stating that it works. I think that everybody's aware of the important investment an AMI is representing for a utility... Just to say that = mistakes are not allowed. The use of validated and mature technologies is a key requirement for a successful massive roll-out of a 20-year lifespan AMI.

I'm actually not pretending to = be a routing expert, but I think that we cannot make the right decision on = the basis of the recently released AMI applicability statement.
We really need some more accurate results based on simulations and = experimentation (field, lab...) to get an idea on how RPL (either in storing or = non-storing mode) performs for different traffic patterns. It's a must to get = figures for certain key indicators (amount of generated control traffic, routing table entries and associated RAM,...). In the perspective of an end-user or even an AMI vendor, the limits have to be known to be able to judge whether the protocol is suitable or not for a given PHY/MAC medium = (wireless, narrowband PLC, broadband PLC,...) and with respect to the used = application protocol (which is defining the traffic pattern). It would also be great to get more accurate information on how to tune all the appropriate = parameters in different environments. =

Many Thanks for sharing your = thoughts Cedric, your input is critically important.
I think = that we had a very fruitful discussion on the subject matter during our = ROLL WG meeting yesterday.

What we now need to = do is to compile the set of comments that were made at the mic yesterday = and have a consensus on what needs to be described in the AMI = applicability document. That will be done = soon.

As a reminder, as clearly spelled out = yesterday, the aim of this document is not to prove that a protocol = work in an AS (applicability statement). As a = reminder:

"An Applicability Statement specifies how, and under what   = circumstances, one or more TSs may be applied to support a = particular Internet capability.
* An AS identifies the relevant and the specific way in = which they are to be combined, and may also specify particular values or = ranges of TS parameters or of a TS protocol = that must be = implemented."

On the other hand, as discussed, we should provide guidance, explain = which building blocks of the protocol should be used in light of the = requirements, the implications on the protocol behavior when tuning a = specific timer, etc =85 As pointed out by Jari, one could provide = pointers on past experience, simulations papers, etc =85 = too.

More soon, and thanks to all of you for = the fruitful discussion. We will summarize it in the minutes, and = authors please come back to the list to propose next steps, have all of = us providing feed-back and reach a = consensus.

Thanks.

JP.


Kind regards,

C=E9dric
 <ATT36402332.gif>  
C=E9dric = LAVENU
= Ing=E9nieur - Syst=E8mes de comptage

EDF - R&D
D=E9partement MIRE
1 avenue du g=E9n=E9ral de Gaulle
92141 Clamart


cedric-2.lavenu@edf.fr
T=E9l. : +33(0)1 = 47 65 27 29
 <ATT36402333.gif> Un geste = simple pour l'environnement, n'imprimez ce message que si vous en avez = l'utilit=E9.




Ce message et toutes les pi=E8ces jointes (ci-apr=E8s le 'Message') sont = =E9tablis =E0 l'intention exclusive des destinataires et les = informations qui y figurent sont strictement confidentielles. Toute = utilisation de ce Message non conforme =E0 sa destination, toute = diffusion ou toute publication totale ou partielle, est interdite sauf = autorisation expresse.

Si vous n'=EAtes pas le destinataire de ce Message, il vous est interdit = de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout = ou partie. Si vous avez re=E7u ce Message par erreur, merci de le = supprimer de votre syst=E8me, ainsi que toutes ses copies, et de n'en = garder aucune trace sur quelque support que ce soit. Nous vous = remercions =E9galement d'en avertir imm=E9diatement l'exp=E9diteur par = retour du message.

Il est impossible de garantir que les communications par messagerie = =E9lectronique arrivent en temps utile, sont s=E9curis=E9es ou d=E9nu=E9es= de toute erreur ou virus.
____________________________________________________

This message and any attachments (the 'Message') are intended solely for = the addressees. The information contained in this Message is = confidential. Any use of information contained in this Message not in = accord with its purpose, any dissemination or disclosure, either whole = or partial, is prohibited except formal approval.

If you are not the addressee, you may not copy, forward, disclose or use = any part of it. If you have received this message in error, please = delete it and all copies from your system and notify the sender = immediately by return message.

E-mail communication cannot be guaranteed to be timely secure, error or = virus-free.
_______________________________________________
Roll = mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail=_900DA887-51F5-4234-B635-1A8BB6350A19--